I've just ordered an AVR Dragon (I need to some HV programming), but I am intrigued with some of the the other possibilities of this device re hardware debugging, etc. Anyone else here using an AVR Dragon and doing interesting things with it? Surprised I don't see them mentioned much in these forums...
I think you will find a lot more information about the Dragon and many expert users of it over on the AVRfreaks site, it's been a favourite programmer over there for a long time:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=index
Lefty
Be prepared for it not to work with the Arduino IDE using the stock IDE and stock avrdude.
Here is the bug about it:
http://code.google.com/p/arduino/issues/detail?id=650
Its a complex interaction of multiple components that creates the problem
but ultimately it is an avrdude issue.
(See the issue above and the link to the Savannah bug report for the gory details
and how to fix it or work around it)
Fixing it in avrdude is the ideal solution, but the problem can also be avoided
by changing the way the IDE uses avrdude to burn images.
Here is a project I did to put the dragon in a case:
--- bill
Thanks Bill, I suspect you may have saved me mucho hair pulling and aggravation.
I thought the deal with lock bits once they were programmed was that the only way to unprogram them is via a chip erase?
Also, I seem to remember reading in either the AVR or avrdude documentation that changed fuse settings didn't operate until the next reset of the chip. So if you are interactive mode with avrude, for example, you can write various values to the fuse bytes (and I would assume lock bits???) but none of it will prevent or enable you doing anything different until the Atmel part is reset. Or am I misremembering?
Anyway, thanks for the heads-up with all of this, at least I know where to start when things don't work out of the box.
Speaking of box, your case looks cool! Probably help prolong the life of the Dragon, too -- I've read they are not very robust and can fail if certain chips are touched while operating. 
I can't remember on the fuse settings, but it may have more to do with avrdude
than the actual AVR. avrdude tries to be smart when dealing with the fuses
at least from the commandline.
Something else about interactive mode on the dragon.
The way they fetch data on the dragon when you do a flash or eeprom dump is really dumb.
Its been a while since I looked at and I can't remember if was both flash and eeprom or just
eeprom, it but I think they ended up fetching a large block like 256 bytes
and then only use 1 byte of it. So it ends up reading the data many more times than is necessary
since it only uses 1 byte a time from the data fetched. They cause the memory dump to be really slow.
I looked at changing/fixing it but the issue was the needed byte count was not available way down
deep in code and to fix it had massive ripple effects and required changing many functions
to support passing the byte counts around so I gave up.
On the case, if I were to do it again, I'd flip the board around and create a daughter board
with a 10 pin and 6 pin header coming out the flat panel and the USB going into the curved side.
I'm probably going to mod my to do this.
The draw back to my case is that you really can't do HV programming with it as it
requires using the socket.
Here is some other information about dragon robustness:
http://www.aplomb.nl/TechStuff/Dragon/Dragon.html
The more recent dragons, (the ones with mounting holes, which have been shipping
for quite some time now) aren't as sensitive as the original ones.
--- bill
All very good information -- thanks again.
Have you used the Dragon for more than programming? I was interested in seeing what might be doable with debugWire and gdb, for example.
Kind of like this....
(see photo below)
This is ddd which is a really nice gui on top of gdb running on linux.
The Arduino IDE is painful to have to deal with.
Assuming you are on linux, here
are some links to get you started:
http://www.larsen-b.com/Article/315.html
You will need to install avarice, avr-gdb, and ddd
If using an Arduino board, you will also have to modify it to remove the auto-reset
capacitor to allow debug wire to work. I think some of the Arduino boards have a solder
pad that can be unsoldered.
I use 3rd party boards which makes this easier.
You see one of the boards I modified to allow enabling/disabling the auto-reset
cap. I used a machine socket and the cap can be installed for auto-reset or removed
or installed in only one of the pins for debug wire.
The IDE cannot be used to re-burn a bootloader using the Dragon unless you use
a modified avrdude. (its only about 6 lines of changes).
If you don't have a modified avrdude, you will have to use a different ISP programmer
or use avrdude from the commandline to re-burn a bootloader.
--- bill
I thought the deal with lock bits once they were programmed was that the only way to unprogram them is via a chip erase?
There are two sets of "lock bits", one for access via programming (SPI, Parallel), and one for access by the bootloader code. Only the first set need a chip-erase to be changed. (The Bootloader lock bits, which can be changed without a chip reset, are further divided into sets for access to the "application memory" and the "bootloader memory.")
Note that ANY SPI-based programming essentially requires a chip-erase, because "programming" can only change one bits to zero bits, and SPI programming does not have the "page erase" command that the bootloader uses to program the flash "one page at a time."
That looks great! There's lots of fun to be had here, I think.
The Dragon arrived today, and to get things started, I installed Atmel Studio (Windows only, of course) and soldered up some headers and a 28-pin socket to do some HV programming. Success! With my new god-like powers, I can set and reset lockbits, SPI_EN, or any other damn thing I feel like. ]
Bwahahhahhha! Mere mortals, tremble and fear!
I did find that the Dragon is indeed finicky about its power supply. First I tried just plugged into the laptop via a USB cable. No go. The laptop didn't recognise a device had been plugged in. Then I got out the powered hub. Still no go. Uh oh.
Then I replaced my USB cable between the Dragon and hub with a shorter, better quality one. Success! But a near-run thing. I was just about thinking of sending it back as a dud.
So even a less than first-rate USB cable can make a difference with these guys. Picky, picky, picky.
But once I got it working, it was all sweetness and light. I might experiment a bit more with Atmel Studio, just to get a bit more familiar with it, and then I will look at getting it debugging on an Uno. I've got a specially prepared one that has had its "reset-en" trace cut today, just for the occasion. (It was a bit of a cripple anyway, with a no-op 8u2, so it wasn't communicating on the USB in an case. Now, it has a new career! Actually, now that I think of it, I may have another go trying to resuscitate that 8u2 with the Dragon.)
I'm looking forward to debugging some code on this set-up with peripherals attached to the Uno. Once I get this set-up, I can see some real time-saving here.
What are the 6 lines of code needed to get avrdude able to work under the Arduino IDE with the Dragon? It's just for SPI programming mode, I'd guess, or can it be configured by avrdude options to do HV programming as well?
Anyway, thanks for your help. How come lots of people aren't doing this???
I haven't had any problems with USB power.
I've run it directly off my desktop and my dell d620 laptop and an acer netbook,
but I never use the dragon to power the target circuit and I've not done any
HV programming.
I also use a 3 foot cable. I'd use shorter if I could find a shorter one.
Maybe the cable was the real issue?
pico:
What are the 6 lines of code needed to get avrdude able to work under the Arduino IDE with the Dragon? It's just for SPI programming mode, I'd guess, or can it be configured by avrdude options to do HV programming as well?
Its an interaction with USB enumeration and how the IDE uses ide.
The IDE does 2 avrdude commands instead of one and avrdude resets the USB when it exits.
Have a read of the bug report for the details.
Anyway, thanks for your help. How come lots of people aren't doing this???
Ignorance and Laziness.....
I presume mostly it is from a lack of understanding of available development tools
from years of using Windows.
It is also a total pain to use with the Arduino IDE - But then the Arduino is a pain to use
anyway for anything but simple sketch builds because of the build methodology they used.
It tends to force you into their way of doing things which has many limitations.
If the IDE had done things a bit differently not only would it have been simpler to implement
but it would have been able to easily interface with external tools like debuggers
all without making the novice user experience any different from what it is today.
At least with the 1.5 version of the IDE and its configuration capabilities,
it looks like it will be possible and won't be that difficult to create an uploader script
that can upload the code as well as bring up all the debugger tools from the Arduino IDE.
(Well, at least on non Windows environments).
I just had a discussion with some folks on another thread about
using source level debugging vs "print" and "led" debugging.
To me, for any serious development work,
part of getting your environment set up is to get the
debugging environment up and working and that means
getting gdb working.
using LEDs and debug prints does have its place but those needs
are quite rare.
I still see many people including in their professional work careers
using "printf" style debugging on their projects.
The same types of things could be said for not using a
source control system.
--- bill