# Tag: gdb

The featured image of this post is by WikiImages on Pixabay

You want to make a single step in your program, but the debugger takes you to some unknown area of the program. This was, in fact, my first experience when I tried out Microchip’s MPLAB X IDE debugger on the innocent blinking sketch. Is this a bug or a feature?

As mentioned in an earlier blog post this year, hardware debuggers are the premier class of embedded debugging tools. However, until today, there were only very few relatively expensive tools around supporting the debugWIRE interface that is used by the classic ATtinys and a few ATmega MCUs.

The good news is that now you can turn an Arduino Uno, Nano, or Pro Mini into a debugWIRE hardware debugger that communicates with avr-gdb, the AVR version of the GNU project debugger.

The featured image of this post is by Albert Guillaume – Gils Blas, 24 décembre 1895, Public Domain, Link

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. And 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 still plenty of surprising situations: Split personality MCUs, stuck-at-one bits in program counters, secret I/O addresses, half-legal opcodes, and more.

The featured image of this post is is a comic from xkcd.com.

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.