When you develop a tool for a protocol that is undocumented, it is not surprising that you will encounter situations you will not have be anticipated. This was exactly what I experienced developing the hardware debugger dw-link, which connects debugWIRE MCUs to the GDB debugger. Although a substantial part of the debugWIRE protocol has been reverse-engineered, I encountered plenty of surprising situations: Split personality MCUs, stuck-at-one bits in program counters, secret I/O addresses, half-legal opcodes, and more.
Continue readingCategory: Debugging
Everything about debugging
Debugging a Debugger With Itself
The above xkcd comic, which is titled Debugger, alludes to the concern that when you try to apply a particular method to itself, you might not get what you asked for. Turing’s Halting problem is a very famous example of this, i.e., you cannot algorithmically decide whether an algorithm terminates on an input. So, does that issue apply to debuggers as well? In particular, I asked myself whether it makes sense to debug the hardware debugger I am developing with itself.
Continue reading
Link-Time Optimization and Debugging of Object-Oriented Programs on AVR MCUs
Link-time optimization (LTO) is a very powerful compiler-optimization technique. As I noticed, it does not go very well together with debugging object-oriented programs under GCC, at least for AVR MCUs. I noticed that in the context of debugging an Arduino program, and it took me quite a while to figure out that LTO is the culprit.
Continue readingLubarsky’s Law of Cybernetic Entomology: There’s always one more bug
(Who the hell is Lubarsky?)
Doing it the Logical Way
When things go wrong, although your program logic appears to be correct, it is time to look at the signals going into the MCU and coming out of the MCU. The best tool for that is a logic analyzer.
Continue readingTesting is not responsible for the bugs inserted into software any more than the sun is responsible for creating dust in the air.
(Dorothy Graham)
While I have talked a lot about bugs and debugging in my tutorial, I still have to tell you when to start debugging in the first place and why testing is an important task in the development process.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
This quote is very much to the point, in particular, when one starts to create overly complex implementations. Keep it simple, stupid!
Premature optimization is the root of all evil
This quote, which is attributed to Knuth, Hoare, or Disjkstra, and which appeared first in print in a paper by Knuth 1974, does apply not only to code optimizations, as I learned it the hard way. It also applies to functional optimizations when you deal with a communication protocol, such as debugWIRE, of which there does not exist any official specification. Adding too many great new features before the basic framework works is a stupid idea.
Debugging(4): Stub it out!
How can you use a stub in order to squash your software bugs? This blog post shows how to arrive in 7 easy steps at a working debugging solution using a gdb-stub for some 8-bit AVR MCUs. The only additional hardware you need is an ISP programmer in order to burn a new bootloader (well, if you are satisfied with a very slow-running program, you do not even need this).
Debugging(3): Debugging is Like Being the Detective in a Crime Movie Where You are Also the Murderer
One has to add to the title (quoted from a tweet by Filipe Fortes) that the detective suffers from memory loss. Otherwise, the case could be solved easily. Similarly, with debugging: If I only knew what nasty things I have hidden in the source code, I could just remove them – but I simply do not know. In this blog post, we will have a look at what kind of tools one could use to find the skeletons hidden in the closet.