Fuse bit reading problem using AVR Dragon with Eclipse installed in Ubuntu

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
#1
Posted by TheCryptoman: Thu. Jun 9, 2016 - 08:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I am experiencing a strange behavior on the Arduino UNO hardware that I am natively programming.

 

I have an Ubuntu + Eclipse set up here which I use to interface to an Arduino UNO which is connected to a Dragon via the ISP port.

 

I invoke the following command from terminal and I can read the fuse bits successfully.

avr-dude -p m328p -P usb -c dragon_isp -F -U lfuse:r:-:r -U hfuse:r:-:r -U efuse:r:-:r

When I try to read the fuse bytes from within Eclipse (under Project Properties -> AVR -> AVRDude -> Fuses -> Load from MCU), I get the following error:

 

"Could not open the USB device with the port name "usb" "

 

which makes no sense since I know the port works when the read command is invoked from the terminal.

 

I have also confirmed the connection presence by reading the MCU type from within the same Eclipse set up ((under Project Properties -> AVR -> Target Hardware -> Load From MCU)

 

Does anybody have an idea on what's going on here?

 

Thanks...

 

 

 

 

This topic has a solution.

Tags:

Tools, In-System Debuggers and Programmers, fuse bits ubuntu eclipse Dragon, solved, ATmega328P
Last Edited: Thu. Jun 9, 2016 - 11:11 AM
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97516 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Jun 9, 2016 - 08:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In Linux avrdude usually requires a udev rule to give 0666 permission to the programmer that is being used. Most examples are for USBAsp rather than Dragon but if you google "avrdude linux udev usbasp" and read one of the many articles that explains this the same solution should work for Dragon.

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Thu. Jun 9, 2016 - 10:36 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

Thanks for your prompt help clawson.

 

I did check the udev rule you mentioned but I doubt that is what the problem is due to 3 reasons:

 

1 - When I type in the lusb command in Ubuntu, following is the output I get. You can clearly see that the AVR Dragon device has been recognized and identified as connected.

 

Bus 002 Device 004: ID 8087:07dc Intel Corp.
Bus 002 Device 048: ID 03eb:2107 Atmel Corp. AVR Dragon
Bus 002 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

2 - As I mentioned in my original post, when I attempt to get the model of the MCU, I can successfully read it using the Dragon that is connected to the target in exactly the same way.

 

3 - Furthermore, I can read the fusebits using exactly the same hardware set up but via the terminal this time. This tells me that there is no issues related to the usb, Dragon or the target device and the interconnectivity between them.

 

 

To me the source of the error is the way Eclipse is trying to read the fuses. However, I don't know what the specific issue is. I am trying to get to the bottom of it.

 

Any other suggestions in light of the above?

 

 

 

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
This reply has been marked as the solution. 
Posted by TheCryptoman: Thu. Jun 9, 2016 - 11:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just tried another thing.

 

Under Project Properties -> AVR -> AVRDude -> Programmer Configuration I edited the active configuration. In the menu therein, there is an option called "Delay between avrdude invocations" which I had set to 250 milliseconds to be safe. However, it appears that it is not safe enough! I changed it to an uber safe value of 1000 milliseconds and I was able to read the fuse bits successfully!

 

Phew!

 

Hope my efforts and time help others as well.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97516 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Jun 9, 2016 - 11:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TheCryptoman wrote:
1 - When I type in the lusb command in Ubuntu, following is the output I get. You can clearly see that the AVR Dragon device has been recognized and identified as connected.

That surely depends on how the app code access the device doesn't it. If it is going via /dev/something then that /dev/something is going to have some kind of user access permissions and unless it defaults to 0666 (rw for everyone) then it could be that some users have more restricted access than others.

 

As for "-P usb" you don't need that - there isn't a choice - Dragon is USB and I'll think you'll find that avrdude knows that and makes a default device choice to access. Your actually specifying -P may be over-riding what would otherwise have worked.

 

If it were me I'd be tempted to pull the source of avrdude and see exactly what mechanism it does use to access a Dragon.

Top
david.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 29299 View posts
Location: Wormshill, England
Posted by david.prentice: Thu. Jun 9, 2016 - 11:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you should never use -F with avrdude.

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Thu. Jun 9, 2016 - 11:15 AM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the info on the redundancy of -P option. I didn't know that. In all the references I have seen so far, this was listed so I did not challenge it. Thankfully, the solution I discovered saved me from digging deep into the avrdude source!

 

Cheers...

Top