Techniques for debugging Cortex-M MCU

Debugging embedded software is my least liked activity, unfortunately though it's a necessary evil. Thankfully, advances in technology and tool chain innovation have resulted in a plethora of techniques to drastically speed up the debugging process. Let's examine a few of them, starting from traditional debugging by break-point through the more advanced instrument trace techniques.

Technique #1 – Traditional break-point debugging
Every developer is familiar with the traditional debugging technique of setting breakpoints, executing code, and then stepping through the code while monitoring registers and variable values. Break-point debugging is a technique that I see used more than any other technique. This is disheartening, however, because break-point debugging is inefficient and generally yields sub-optimal results.

So, then, why are breakpoints used so often? The main reason seems to be because breakpoints are easy to use, are readily accessible, and developers are optimistic that breakpoints are the right tool for the job. That optimism needs tempering. Breakpoints have the potential to disrupt the systems real-time performance and can suck a developer into a black hole of endlessly single stepping through code blindly looking for a solution to their problem.

Technique #2 – IDE Value Graphing
Nearly all modern debuggers and IDEs now allow a developer to monitor the value stored inside a memory location such as a variable. A developer selects the memory location and the value refresh rate, and then starts the debug session. Some IDEs have the ability to monitor the value built into the IDE while others rely on using an external software.

Value monitoring can be very useful, but it is far more valuable if the data being monitored is tied to a graphical representation. Graphing the data values in real-time can be extremely useful for discovering unexpected changes or to verify that a particular waveform is generated. Take, for example, a three phase BLDC motor. A developer may want to monitor the current and voltage on each motor leg, which need very specific waveforms to be generated in order to drive the motor. Plotting the voltage and current on each motor leg can allow a developer to visualise what is happening in real-time.

Technique #3 – Reroute printf to SWO
On higher-end ARM Cortex-M parts, such as the M3/M4, developers are provided with additional debugging capability known as the Serial Wire Viewer (SWV). The SWV comprises the standard serial wire debugger in addition to a Serial Wire Output (SWO). The SWO can be used to do really cool things such as retrieving the program counter, event counter, and trace data, to name a few. Developers can customise the information that they would like to have transmitted over the SWO.