Null Space Labs was tired of fighting the Dragon Atmel AVR debugger, so they make made their own programmer called the Kraken:
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…
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.
Via the contact form.
I’m also guessing this doesn’t help when you do want to debug a program.
No, not as far as I can tell. I looked for open source AVR debuggers, but have never found much. That is probably the only real reason I use PIC and ARM over AVR.
Can’t say I’ve used PIC before (Ever), and I haven’t debugged a ARM chip yet, but I have debugged a HC12 chip!
I believe Atmel is very protective of debug wire.
nope it doesn’t (as noted in the blog) debugwire is a proprietary protocol and atmel refuse to release it, though rumour has it someone at nsl is thinking about reversing it..
thanks for the post ian btw.
The main reason I use microchip mcu’s 50x more then atmel mcu’s is ’cause I have pk2 and pk3 hence ability to do in circuit debugging. Ones who never tried that have no clue what they are missing. Recently I got me a dragon (I do own number of usbasb versions but that’s not it) and it works flawlessly (if you follow the manual) and now atmel chips are as useful as microchip or ti ones. Debugging works great.
Wrt “dragon blowing chips” – the problem is low voltage vs 5V, you need to follow up connection guidelines, it is not as simple as with pickit but what the hack you are supposed to know this things :D
How exactly does the AVR Dragon blow up chips?
it doesn’t, the dragon itself is what blows up the power regulator circuitry has a fault in it that causes it to generate way too much voltage and it kills the chip, i can upload some pics to the blog of the dragon with holes burned in the chip. The link in the blog entry shows how you can help to protect it. Or help to stop it happening by using a usb hub with a decent power source.
frank just follow up 2 main things when using dragon
1. connect it to a self powered usb hub (so that 5V coming from usb are really 5V and not 4.3V like on some laptops)
2. do not power your target from dragon
and you do not need to worry about blowing up anything :)
(atmel probably should designed the power section of the dragon bit better but following these 2 guidelines is really not that difficult)
Thanks guys, I’ve actually modified my Dragon such that VTG is connected to the 5V pin through a slide switch, it doesn’t work right (caused the Dragon to freak out software wise) so I never use it
the links in the article show an adapter board that plugs into the dragon to buffer it too, helps even more. using a hub is easy, but you can still cause the power to drop on a hub, especially if you’re doing hardware prototyping and teaching beginners how to build stuff, ask me how i know ;)
I can’t swear I’ve actually used it with debugwire, but AVaRICE does support it, so you should indeed be able to debug using GDB on Linux.
Also, I believe there was already a hardware revision to the Dragon that improved the robustness of the power supply section.
Just re-read my comment above and perhaps wasn’t very clear – I probably should have replied to a specific post.
The point I was trying to make is that you can debug AVRs with open source software tools, not with this board…
liiks like avarice uses the avr jtag ii ice or the dragon to do debugwire.
Like I said on Charlies page, I think it´s also important to not leave the original peace of black foam under the Dragon, since it is conductive.
Have always used my Dragon from a powered HUB, and it has never let me down.
that is an important tip Jan..
We build lots of introduction to soldering kits at NSL, and people invariably end up doing something crazy with the usb and it’ll cause the hub to shut down. Of course having better supervision and knowledge about it helps, but it still happens from time to time. we have usb isolators too, but frequently forget to use them :)
so a cheap programmer that is also tougher is great ( and it can recover chips the dragon doesn’t seem to be able too )
What a strange coincidence! On the 25th, I was over at Metrix Create:Space to get started on my first laser-cutting project when I overheard someone asking about their Kraken. They picked it up at a recent con, and it was already this. This guy was a programmer, not a hardware guy (no offense intended), so I helped him try to debug what was working and what wasn’t. I almost thought this article was saying that the Kraken had a design flaw, which might have saved me some time if I had read this article before, but I guess the known problem is with the Dragon. Anyway, this particular Kraken had some soldering issues, but it was getting power just fine. My final diagnosis was that the AVR was blown or maybe it had lost its firmware. I think this fellow got the Kraken for free, so I suppose he shouldn’t be too disappointed that it’s not working any more.
The moral for me is that I should probably check the Dangerous Prototypes blog not just every day but every time I have an issue with newly-released hardware!
hmm, lost the first draft of this..
sounds like a misunderstanding, the krakens and some other nsl kits were being used a the defcon 19 HHV for people to build themselves as an introduction to surface mount soldering, we supplied lots of metcal soldering irons and microscopes and hands on help, though obviously we weren’t able to help everyone. a few people didn’t get their chips programmed, either lack of time or knowing that it needed it. since we volunteering the HHV and only got notification two weeks before defcon, we didn’t have a lot of people helping out.
we left lots of info that people were free to send them along to me at NSL and we’d either repair any faults they made during their build, or program it, or both, they just need to send it along with an SAE or pop into the hackerspace and they can learn how to fix it themselves. people soldered things on backwards, sideways, in the wrong places etc etc.
not sure if the moral fits the story though ;)
I forgot to explain why the moral fits: I knew nothing about the Kraken, so I kept suggesting that he needed a programmer/debugger. At least if I had read this blog I would have had an introduction. Then again, he pulled up the schematic and layout very quickly after I suggested that they would be helpful, so there’s certainly plenty of support at the URL on the PCB.
By the way, this particular Kraken was programmed and tested at the con, but somehow stopped working subsequent to that. I couldn’t come up with any theory how that might have happened, but I do know that the owner used the hot air rework station, loupe/magnifying lens, and soldering iron at Metrix to try and repair his Kraken.
I think it worked out well in the end, since a software guy was introduced to hardware and found it interesting enough to dive in. Failure didn’t scare him away, and he learned about several things: AVR vs. PIC, programmer vs. USB bootloader, hardware vs. pure software, charlieplexing (another toy he had at the same time) vs. row+column matrix (and PWM brightness issues), hard-wired vs. firmware-controlled I/O driven LEDs, etc.
That is exactly what i (re)designed it, wrote the wiki entries for, as well as the HHV, and our hackerspace NSL to teach people.
Who knows why it failed, as i said have him send it back and we’ll find out, repair and return it. Could be the bad soldering, could be something else. I’m always interested to see what goes wrong with them so we can improve and adapt them.
Crystals are very heat sensitive so once they’ve been reworked, they’re prone to failure, and the USB is very timing sensitive, that has been the typical fault, and usually people use way too much heat, that’s why we use metcals, but out hot plates are variable temperature.
If you’re having trouble with USB timing sensitivity, then perhaps you should consider matched impedance traces on your PCB layout. That can be expensive, but at least you can try to make the length of the D+ and D- traces match each other and take parallel paths. Avoid vias completely, especially a via in one half of the differential pair that doesn’t occur in the other. Oriented the processor so that the USB data pins line up directly with the USB jack for a direct path. In your schematic, you have series resistors on the data lines, so you cannot have uninterrupted traces from jack to CPU (as is possible with some PIC models), but at least you could place them in parallel so they maintain the balanced signal. Any abrupt change in the trace creates an opportunity for the full-speed signals to bounce back down the cable and cause interference. Maintaining matched impedance allows the PCB traces to “look” just like the USB cable.
We’re not, it is a software USB stack that relies on the XTAL to provide timing. The XTAL gets damaged with too much heat, so the USB stops working. It is a low device, so the timing isn’t as critical as say our logic analyser.
Ah, very interesting. I know of some PIC and AVR devices which can operate from an internal oscillator for low-speed USB operations. Maybe that would save you from damaged crystals? All full-speed USB devices rely upon a crystal for timing, although now there are even some PIC/AVR chips with internal oscillators that have enough accuracy to meet the USB specifications.
Then again, I guess the easiest fix is to avoid destroying the crystal by overheating rather than redesigning around an entirely different chip.
yeah rewriting all of the software and a full redesign would be a bit overkill when its really just being careful with the heat, i usually suggest people leave the xtal til last, but if its being reworked its difficult to keep that up. luckily xtals are cheap too.
Seems like a good test (where possible) would be to hook a ‘scope to the crystal pins on the AVR to see whether the crystal is working? I guess the problem there is that the ‘scope probe could actually screw up a perfectly fine crystal circuit due to the impedance change, thus providing a false negative. I’ve never actually tried testing an external crystal in-circuit to see whether it was the cause for an unresponsive processor.
Sorry to go on about this, but it was an interesting challenge. I did not intend to imply that there was anything wrong with the Kraken – just that the timing of everything seemed so coincidental to me.
yep thats the usual approach..
its fine, i didn’t read it like that. but i do want to make sure we reach out to anyone with a failed built at defocn and fix it , no krakens left behind!!
rsdio, I am the developer who was at Metrix the other night. CharlieX, I’ve got the contact information on where to send the chip. I’m out to get new crystals and diodes after reading the thread. It’s very likely I burned the crystal Saturday night.
Hi there, electricEmu. Head on over to the Dangerous Prototypes Forum and send me a private message there (I have the same ‘rsdio’ handle there as here). I’d like to stay in touch via regular old email.
no worries, either send it to me or send me your address and we’ll either fix it here, or send you parts.
cheers.