The AVR Dragon is a little development board that can program and debug AVRs. I bought it because I needed high voltage serial programming (HVSP) for the ATTiny13A device I’d selected for a project. HVSP isn’t just the standard ISP with 12V on the reset line; it’s a significantly different protocol and I figured I’d just buy the $60 Dragon instead of screwing around building something.
The Dragon seems to have its own set of issues. Sigh.
HVSP needs an additional jumper¶
This solution came from sterna.crf.nu, which appears to be on its last legs. I can’t contact the author or leave a comment, and I can’t link directly to the specific article because the site throws 404s. Search for dragon and you should jump to the correct article, if the site is still around.
When using HVSP, you need to make sure that the Dragon sees 5V on its VTG pin on the ISP header. If you don’t do this, avrdude reports that the Dragon refuses to do anything because it thinks the target device does not have power. This is easily achieved by taking a small jumper between any of the +5V header pins on the dragon and connecting it to pin 2 (VTG) on the ISP header on the Dragon. This gets around the problem of the Dragon not seeing target power, but leads me right into the next issue.
update I see it also mentioned on support.atmel.no which comes up often in google searches for AVRs.
Note that the target voltage, i.e. the 5V from the VCC header must be applied to either pin 2 on the ISP header or pin 4 on the JTAG header. This because the AVR Dragon must read the target voltage.
Dragon and OSX don’t seem to get along¶
Maybe it’s something with VirtualBox’s USB drivers, but avrdude 5.11 running natively on OSX reports various forms of
avrdude: usb_fill_buf(): usb_bulk_read() error Broken pipe avrdude: jtagmkII_recv(): Timeout receiving packet avrdude: stk500v2_jtagmkII_recv(): error in jtagmkII_recv()
usbdev_send(): wrote -32 out of 15 bytes, err = Broken pipe when it does see target power. I thought this was maybe something to do with the firmware version on Dragon so I booted up my virtual XP instance and ran AVR Studio 4 to update the Dragon’s firmware. The update worked (at firmware version 6.16 now) but it still doesn’t work natively on OSX (same issues) and it also doesn’t seem to work in AVR Studio. AVR Studio 4 is old so I downloaded the 6.1 beta and installed it. It is worse off; it sees that the firmware is older than what AVR Studio 6 knows about, but the dialogue box that comes up shows “device firmware version <blank>, on-disk firmware version <blank>” – if I try to update it puts the Dragon into bootloader mode but gets no further.
Solution: The issue was due to the fact that I had capacitance across the target’s supply. Removing the bypass caps, I seem to be able to program the AVR in-circuit. The dragon needs to be able to have good control over the target’s power supply.
(early?) Dragons have ESD sensitivities¶
Found Plons’ Dragon page, which details a lot of the issues with (early?) Dragons. Basically it involves using buffers between the headers on the Dragon and the target. It also goes into detail about the 12V supply between the Dragon and target and that they tend to blow. They are 8-pin (maybe 8+gnd pad) devices and their marking is “AHT”. He identifies them as OnSemi NLAS2066USG and identifies another replacement as TI’s TS5A23166. They are dual SPST analog switches.
He also mentions that the TPS61020DRCRG4 boost converter section is designed poorly and that you can get around it by connecting the +5 from the USB port to the output net of the (now removed) converter:
From his site:
Kasper Pedersen emailed me the explanation. Here it is (in my own words):
Lots of parts on the Dragon are specified for operating on 4.5-5.5V.
The USB-spec however says:
Minimum DC voltage at host connector 4.65V
Minimum DC voltage at peripheral 4.40V
Minimum DC voltage at peripheral connected to BusPowered hub 4.150V
Using a boost regulator allowed the designer to meet the usb “must email@example.comV” requirement.
BUT: he forgot to implement an undervoltage lockout. Which results in an increased current consumption when the USB-voltage is low, which results in more current to get that boosted output @5V, the increased current lets the incoming voltage even drop further ...... do I need to iterate more ?? So in the end the boost-regulator will blow itself when the USB-power is not powerfull enough. Funny huh ? With a powerfull USB-power the Dragon doesn’t fail, but using a not-so-powerfull one, it kills itself. Dragon suicide
If you are such an unlucky person, do the modification described above. But make sure that you give the board a decent 5V supply. A powered hub is a good source. I use one with uses a wall-wart that can supply 1.5A. Never short on currentsupply.
Basically the converter is used to ensure a minimum 5V supply voltage, and a weak USB supply causes the device to draw more current and fail. Be aware that the converter has a pad underneath, it won’t be nice to remove.
Target VCC must not be filtered¶
I found a message saying that HVSP requires the target VCC to be able to be dropped quickly:
The Dragon switches it’s Vcc off for ~25ms before before putting 12V on the reset line. I had to remove capacitors across the supply to the micro. In fact, 2.2uF made the HVSP not work, but 470nF it works fine. Looking at the Vcc waveforms during entering programming mode, the switching looks clean and sharp.
I have a large filter cap in the project right now. Removing the cap allows the Dragon to do its thing in HVSP. Maybe I’ll have to add a steering diode or small FET so that the cap doesn’t get charged when powered from the programer but works normally when powered from its own internal supply.