problem with AVR micro controller programmer

136 views
Skip to first unread message

Anant Devi

unread,
Sep 10, 2010, 10:10:38 AM9/10/10
to cof...@googlegroups.com
Hi,
I am using usbasp for burning atmel AVR uC.
http://www.fischl.de/usbasp/
I am using AVRdude to burn controller.

While using it in ubuntu if you are super user it works nicely, but if not it gives error like-
avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc
Site below has some fix, but I'm unable to understand it.
https://bbs.archlinux.org/viewtopic.php?pid=818035

Please tell me how to apply it.

sanjeev mk

unread,
Sep 10, 2010, 12:00:46 PM9/10/10
to cof...@googlegroups.com
The link you posted has suggested the fix. You just need to add the recommended lines to the appropriate .rules file

The rules file for AVR controllers is 50-avrdragon.rules (googled this up :) )

1.Go to the /etc/udev/rules.d directory :-

cd /etc/udev/rules.d/

2.Create a new rules file for AVRdude:

vim 50-avrdragon.rules   //The rules file for AVR controllers

3.Add the following lines to it:

SUBSYSTEM=="usb" , SYSFS{idVendor}==0x16x0, SYSFS{idProduct}==0x5dc, GROUP="users", MODE="0666"
SUBSYSTEM=="usb_device" , MODE="0666"

4.Restart udev :

cd /etc/init.d
./udev restart

--
You received this message because you are subscribed to the Google Groups "CoFSUG" group.
To post to this group, send an email to cof...@googlegroups.com.
To unsubscribe from this group, send email to cofsug+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cofsug?hl=en-GB.

sanjeev mk

unread,
Sep 10, 2010, 12:15:30 PM9/10/10
to cof...@googlegroups.com
@Anant; If you want to know why .rules files are needed...

In linux, the /dev directory is used to store file-like device nodes which refer to certain devices in the system. Each node points to a part of the system (a device), which might or might not exist. Userspace applications can use these device nodes to interface with the systems hardware.

/dev contains files for all the possible devices that might be connected to the system (You may or may not have those devices), thus making /dev very big and difficult to manage. udev is a way of managing or rather customizing the /dev directories

You customize device usage by writing udev rules in the /etc/udev/rules.d/ directory. The user can thus customize how he/she wants the OS to handle a particular device.

In your case, you wanted the OS to let normal users ( i mean NON super-user) interact with your AVR controller over the USB port.
So, you notify the kernel of a particular device, by giving it the "Vendor ID" and the "Product ID" of that device.
You tell the kernel which part of the system you are going to connect your device to, using the SUBSYSTEM keyword.
And then you tell the kernel the 'mode' in which you want to use the device, with the MODE keyword.

sanjeev mk

unread,
Sep 10, 2010, 12:18:29 PM9/10/10
to cof...@googlegroups.com
Sorry made a typing mistake with the idVendor variable. It is your vid, 0x16c0

Anant Devi

unread,
Sep 11, 2010, 8:28:14 AM9/11/10
to cof...@googlegroups.com
Thanks for help,
but it is not working..I even tried lines given on that web page since they were for usbasp (since it is different firmware from dragon or stk500)
...still no luck.

sanjeev mk

unread,
Sep 11, 2010, 8:41:40 AM9/11/10
to cof...@googlegroups.com
@Anant: Plug in the device and run the command "lsusb" and post the result here. This will tell you if the OS is atleast detecting the board.

Apoorv Parle

unread,
Sep 11, 2010, 8:45:39 AM9/11/10
to cof...@googlegroups.com
With sudo it is working, means the device is detected.
@Anant: ping me when you are online, we'll try to solve the issue online
Absence of proof is not proof of absence.
----
apparle

sanjeev mk

unread,
Sep 11, 2010, 8:59:46 AM9/11/10
to cof...@googlegroups.com
@Anant: Try this:
In rules.d, create 45-USBasp.rules

Add these lines:
SUBSYSTEM=="usb", SYSFS{idVendor}=="0x16c0", SYSFS{idProduct}=="0x05dc", MODE="0666"

Apoorv Parle

unread,
Sep 11, 2010, 9:03:01 AM9/11/10
to cof...@googlegroups.com
rather than using that vendor and product id, do "lsusb" and use the listed ids for USBasp

sanjeev mk

unread,
Sep 11, 2010, 9:05:39 AM9/11/10
to cof...@googlegroups.com
@Apoorv: That is the vendor and product id that Anant suggested at the beginning of the thread.

Apoorv Parle

unread,
Sep 11, 2010, 9:07:46 AM9/11/10
to cof...@googlegroups.com
Ok... then its fine.

Anant Devi

unread,
Sep 12, 2010, 1:39:56 AM9/12/10
to cof...@googlegroups.com
lsusb detecting usbasp...made file 45-usbasp.rules with that line...still no use.
Bus 006 Device 003: ID 16c0:05dc VOTI USBasp AVR Programmer

While restarting udev i should use sudo right? I'm giving commands-
service udev restart and
restart udev its outputs are- udev start/running, process 1926  udev start/running, process 1923

As suggested by sanjeev i used
cd /etc/init.d
./udev restart
but it is giving output
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service udev restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart udev

so i did both...i.e. service udev restart and restart udev

Thanks.

sanjeev mk

unread,
Sep 12, 2010, 6:48:47 AM9/12/10
to cof...@googlegroups.com
service udev restart will also do the same...no problems.

Ok, instead of changing permissions through udev rules, try changing the permission of device file of the controller, that is, change the permissions of the appropriate file in /dev. For that , you need to know the device file name of your AVR. That can be obtained as follows:

After connecting your programmer , run the command dmesg. dmesg will output recent kernel activities. Among all other info, you can find the device file name of the controller. For example, when I connect my pendrive to my system and it get's detected, I run dmesg and get the following output:


[  720.369917] scsi 6:0:0:0: Direct-Access     Kingston DT 101 G2        PMAP PQ: 0 ANSI: 0 CCS
[  720.375200] sd 6:0:0:0: Attached scsi generic sg3 type 0
[  720.963854] sd 6:0:0:0: [sdc] 7774208 512-byte logical blocks: (3.98 GB/3.70 GiB)
[  720.966880] sd 6:0:0:0: [sdc] Write Protect is off
[  720.966888] sd 6:0:0:0: [sdc] Mode Sense: 03 41 00 00
[  720.966892] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  720.983843] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  720.983856]  sdc: sdc1                        // sdc1 is the device file name of my pendrive. It is in the /dev directory. 


Do the same for your controller. After getting the file name, change it's permission in the /dev directory. You need to be root to do this. :---

cd /dev
chgrp <the group or user who wants to use the file> <your device filename>

Eg.
If your device filename is sdb1 and your username  anant, then the command will look like this:

chgrp anant sdb1
or
chgrp anant /dev/sdb1 , /*if you are in some other directory */


But the problem is, this change has to be made on every reboot. A more permanent solution would be to write udev rules, but as it is not working for some reason in your case, you can try this.

Hope this works.... :)     
Reply all
Reply to author
Forward
0 new messages