Atmel AVR Dragon vs the Kraken

 

Yesterday I was rewriting code for Null Space Labs ‘Cylon III’, a blinky toy thing we make and use for people to have soldering practice, it spawned from the EMSL Cylon and then through a few iterations from a simple 9 LED thing to a charlieplexed circle.

Cylon I

 

Cylon II (with an IR LED to mimic a tv-b-gone)

 

Cylon III

 

We use the ATTiny2313 which a lot of people complain has no legs ( the MU package ), I think its great but it can be  a challenge especially with the milled versions of the PCB to fix and replace the chip.

Anyway I was playing around with different clock speeds in AVR Studio with the Atmel Dragon. The dragon is a terrible piece of hardware when it doesn’t work right, which is  often. It has a design flaw that causes a couple of chips to blow up regularly, so regularly in fact we keep a stock of the chips at Null Space Labs. My dragon has been repaired three times so far.

Then there is the software itself, the way it interacts with the USB has it disconnect and reconnecting after using the AVR Studio programming interface, sometimes it’ll hang and you’ll hear the USB connect/disconnect cycle until you unplug it ( which increases the chance of the chip blowing up issue  ) and exit AVR Studio 4, which is really annoying especially during debugging.

So I select the <4Mhz option and AVR Studio warns me that I won’t be able to program the chip if i set it this low, I say no and put it back on the internal 4Mhz. However I fail to take into account that CKDIV8 is set ( clock divide by  8). At this speed the Dragon is having problems reading and flashing the chip, even at 51khz which is the lowest speed. It’ll read the chip id once, or read fuses once, then require me to exit the programming software, and reload it.

So i think, ok reset the fuses since it’ll let me do one operation. But in AVR Studio you have to read the fuses then set them, you can’t set them by hand then program, this uses my one attempt before the Dragon fails to communicate.  It reads the fuses, but then fails to set them.. I try every variant, unplug the dragon, nope, this fails since it looses the USB setup or whatever AVR studio is doing, reset the target board, disconnect the target board. Nope, the only thing that works is exit the programming interface in AVR studio, let it reset the Dragon and back in again, at which point it reads the fuses again and then I can’t do anything with it, since it no longer communicates with the chip.

Anyway at this point I’m thinking its time just to replace the chip, but then I remember about our AVR programmer which is a smaller , simplified version of the USBAsp, we call it the Kraken.

Prototype

 

Final version

 

We only use the ICSP mode and have our own SIL 6 pin programming header. The pogo pin version is much nicer than my hack.

 

Prototype version.

 

Krs pulls one out of the back and builds it in less than 20 minutes, it’s programmed and ready to go. I  setup AVRDUDE and read the chip id, that works, read it again, still works.. So i try just to set the LFUSE so that the clock is set back to 8Mhz, and bingo it works straight away.

 

USBASP/Kraken 1, Atmel AVR Dragon 0

 

 

Atmel sells the Dragon for $49 http://store.atmel.com/PartDetail.aspx?q=p:10500053 it comes with no case (which doesn’t help the chip destroying problem either ). I personally think they should rev it, or sell it with a box,or at least a warning. Using it with a USB Hub will help alleviate the chip killing problem.

Here is the web page that lead us to keeping a stock of chips, we’ve fixed about 6 of them in the last few months, so far its always the same issue. http://www.aplomb.nl/TechStuff/Dragon/Dragon.html

But why it can’t flash the ATTiny2313 when the USBAsp/Kraken can just seems like a software problem. Now if only we had access to DebugWire I could do without the Dragon altogether.

Still after you’ve seen a few of them with holes burnt through the chip and sometimes even into the PCB, you’ll know why Atmel calls it the Dragon. It’s funny how the people who make the chips can’t get their programmer to work well, when one guy in germany can.

I’d like to say no Dragons were harmed during this process, but one of our members ( who coincidentally named the Kraken project) blew his up while I was working on this problem ).

Since this blog was written around 8/22.. We’ve blown up another three dragons..

Links

http://www.fischl.de/usbasp/ USBAsp home page
http://wiki.032.la/nsl/AVR_Programmer Null Space Labs Version of the USBAsp
http://www.aplomb.nl/TechStuff/Dragon/Dragon.html How to fix the Dragon (and add some improvements)

About these ads