In Chapter 6, Testing OS-Based Applications, we looked at debugging applications using Valgrind and similar tools, as well as GDB and kin. With the OS-based integration tests for MCU-based projects, such as those demonstrated in the Example – ESP8266 integration test section, we can use the exact same techniques, profiling and debugging the code without concerning ourselves just yet with the fact that the same code will be running on a much slower and more limited platform during final integration testing on real hardware.

The real challenge comes during that final integration stage, when the firmware—which we have been debugging on our fast desktop system using Valgrind and other highly capable tools—is now running on a paltry 16 MHz ATmega MCU without the ability to quickly launch the code with a Valgrind tool or within a GDB session.

As one will inevitably encounter bugs and issues during this stage, we need to be prepared to deal with this situation. Often, one has to resort to on-chip debugging (OCD), which can be performed over whichever debugging interface the MCU provides. This can be JTAG, DebugWire or SWD, PDI, or some other type. In Chapter 4, Resource-Restricted Embedded Systems, we looked at some of those interfaces in the context of programming these MCUs.

Embedded IDEs will provide the ability to perform OCD right out of the box, connecting with the target hardware, allowing one to set breakpoints, much like one would be used to setting for a local process. Of course, it's also possible to use GDB from the command line to do the same thing, using a program such as OpenOCD (http://openocd.org/), which provides a gdbserver interface for GDB while interfacing with a wide variety of debug interfaces.