Has this ever happened to you? You start out on a reverse-engineering project, start digging in, and then get stumped. Then you go looking on the Internet for help, and stumble across someone who’s already done exactly what you’re trying to do?
[Geekabit] wrote us with a version of this tale of woe. In his case, the protocol to be reversed was Atmel’s debugWire protocol for debugging on low-pin-count parts. There are a number of websites claiming it’s “secret” or whatever, but it actually looks like it’s just poorly documented. Anyway, [RikusW] seems to have captured all of the signals way back in 2011. Good job!
The best part of [geekabit]’s story is that he had created the Wikipedia page on debugWire himself to inspire collaboration on reverse-engineering the protocol, and someone linked in [RiskusW]’s work. When [geekabit] picked up the problem again a bit later, he did a bit of web research and found it solved — on the page that he started.
Maybe it’s not a tale of woe after all, but a tale of unintentional collaboration. Anyway, it serves as a reminder that if you’re interested in the destination more than the voyage of discovery, it never hurts to do your research beforehand. And now we all know about the low-level details of the debugWire protocol. Anyone written up a driver yet?
Thanks [geekabit] for the tip and the story! Image from ATmega32-AVR, which explains nicely how to use the Dragon in debugWire mode.
12 thoughts on “Reverse-Engineering DebugWire”
The Wikipedia article is nearly empty, and there’s no Talk page. So basically, one reference was added to a Wikipedia article, and HackADay found a way to write a 246 word article (longer than the entirety of the Wikipedia page!) about it.
Seems like a bit of a stretch to me.
“…HackADay found a way to write a 246 word article…”
Hah! $ wc -w target
Are you interested in debugWire? Then click the first link in the article, which is the reason for having written the story — the complete reverse engineering and documentation of a “secret” protocol. Very good stuff to know — and could help anyone who is interested in writing an open-source debugWire tool.
Is that a stretch?
I’m not sure this story is about the Wikipedia page directly, but how someone found the short page on debugWire useful and how this protocol is generally useful for people developing with these devices. Wikipedia people have a very different view on the value of these types of pages.
The Wikipedia article is more of an afterthought. Let me clarify:
I was wondering what kind of simple hacks I had done the last couple of years. While writing the article, I realized that Hackaday never covered the reverse engineering of debugwire. So I sent a tip, including a bit of my story, to Hackaday.
By now my story is (more or less) finished. You can read it at: https://www.geekabit.nl/projects/some-smaller-projects/#debugwire
I used RikusW’s to create a standalone programmer/debugger for debug wire using just an FT232 and a diode: https://github.com/dcwbrown/dwire-debug.
Wow! Thanks for posting your link.
Seems you finally did what I knew had to be done, write a custom debugger for direct interfacing to debugWire.
Another option would be to write a virtual Jtagice mkii via serial loopback to interface to Atmelstudio.
Its great to know someone found my work helpful! (Steffanx also helped decoding commands.)
well aren’t you glad someone went to the effort?
“The topic of this article may not meet Wikipedia’s general notability guideline. Please help to establish notability by citing reliable secondary sources that are independent of the topic and provide significant coverage of it beyond its mere trivial mention. If notability cannot be established, the article is likely to be merged, redirected, or deleted.”
Don’t get me wrong. I’m glad somebody else succeeded where I did not. The important thing is that debugWire is documented now and we could start supporting it in the open source programmers. The Wikipedia article might need a bit of a clean-up though.
Nice! I hope to see at least the flash programming implemented in AVRDude
I am particularly hoping that Microchip publishes what Atmel knows internally about the AVR debugging protocols, when the acquisition is complete.
It would be relative easy for them to do, produce a significant amount of good will, and is consistent with Microchip’s own debug protocol “openness” (ie PICKit 2 having published source, etc.) (and perhaps raise the possibility of some “interesting” hacks…)
Please be kind and respectful to help make the comments section excellent. (Comment Policy)