Debugging embedded software is one of my least favorite activities, but unfortunately, it is necessary. Fortunately, advancements in technology and toolchains have generated a wealth of new techniques that significantly accelerate the debugging process. Let’s take a look at some of these methods, from traditional breakpoint debugging to more advanced instrumentation tracing techniques.
Tip 1# – Traditional Breakpoint Debugging
Every developer is familiar with traditional debugging techniques: setting breakpoints, executing code, and then stepping through the code while monitoring registers and variable values. Breakpoint debugging is the most commonly used technique I’ve seen. However, the results are often not very promising, as breakpoint debugging tends to be inefficient and usually yields suboptimal results.
So, why do people still use breakpoint debugging so frequently? The main reason seems to be that breakpoint debugging is easy to use, easy to understand, and developers optimistically believe that breakpoints are the right tool for the job. This optimism needs to be validated. Breakpoints can disrupt the real-time performance of the system and can trap developers in a black hole, endlessly stepping through code while blindly searching for a solution to the problem.
Tip 2# – IDE Value Graphs
Nowadays, almost all modern debuggers and IDEs allow developers to monitor the values of variables stored in memory. Developers can choose memory locations and value refresh rates, then start a debugging session. Some IDEs have the capability to monitor values built into the IDE, while others require external software.
Value monitoring is very useful, and when the monitored data is associated with graphical representations, the value increases even more. Plotting real-time data value graphs is extremely useful for discovering unexpected changes and validating the generation of specific waveforms. For example, for a three-phase brushless DC motor (BLDC motor), if developers want to monitor the current and voltage of each motor phase, they need to drive the motor to create very specific waveforms. Plotting the current and voltage of each motor phase allows developers to see in real-time what is happening.
Tip 3# – From printf to SWO
In high-end ARM Cortex-M series peripherals, such as M3/M4, developers are provided with additional debugging capabilities, namely the Serial Wire Viewer (SWV). SWV also includes standard serial wire debugging in addition to Serial Wire Output (SWO). SWO can be used to do cool things, such as program retrieval counters, event counters, and data tracing. Developers can also customize what information they want to send through SWO.
Many developers set up printf to retrieve debugging information from their embedded systems. In reality, they are not using the serial pins in the microcontroller; instead, developers can use SWO to reroute printf information through the debugger. Using the debugger this way eliminates the need for dedicated serial interfaces and saves time developing UART and USB devices, making it more efficient. Now, through SWO and debugging hardware, the overhead initially used by the application can be offloaded, reducing the precious clock cycles that could be used by application code.
Tip 4# – RTOS Tracing
Trying to see through the surface to understand the essence of a real-time operating system (RTOS) can be quite challenging. Developers do not want to disrupt the performance of the real-time system but still need some way to understand the system’s behavior. This is also the trick often used by the Blinky LED, but recently developers have more amazing tracing tools in their toolbox. For example, free commercial RTOS tools like TraceX, SystemView, and Tracealyzer, etc.
When the RTOS is idle, or when tasks enter and exit, tracing tools allow developers to conduct tracing analysis. Developers can monitor system anomalies, response times, execution times, and many other critical details required for properly developing an embedded system. The coolest feature of RTOS tracing tools is that they can show what is happening inside the system. Reviewing in real-time or in log files and monitoring timing diagrams allows developers to establish a level of confidence to estimate whether the system can operate as expected or help them discover minor issues that would otherwise take a lot of time to find.
Tip 5# – Using Instruction Tracing Techniques (ETM / ETB / ETM)
Sometimes the debugging issues developers face are at the lowest imaginable level in the processor. Tracing techniques exist to monitor individual instructions executed by the processor. Such low-level tracing is very useful for monitoring branch coverage during software testing and validation. Debugging tools for instruction tracing differ from those used by developers for Serial Wire Viewer and are slightly more expensive.
Conclusion
Debugging tools and techniques have rapidly evolved over the past few years, especially for high-end microcontrollers. Generally speaking, engineers are visual beings, and tool suppliers are looking for ways to visually stimulate the revelation of what is happening in a real-time system. Configuring debugging tools may require some upfront work, but spending a little more time on design can lead to less debugging time, which is indeed a worthwhile investment. Developers should at least be familiar with different debugging tools and available features so that when issues arise and the system needs debugging, they can choose the right tools for the job. Have you used any other technologies that can help engineers debug their systems faster and more efficiently?
Disclaimer: This article is a reprint from the internet, and the copyright belongs to the original author. If there are copyright issues, please contact us, and we will confirm copyright based on the materials you provide and pay for the manuscript or delete the content.