How to debug embedded software faster, try these five tips!

Debugging embedded software is my least favorite process, however, it is very necessary. Fortunately, advances in technology and tool chain innovation have spawned a large number of new technologies, which greatly accelerated the debugging process.

In embedded system development, debugging and testing are very important.

Debugging embedded software is my least favorite process, however, it is very necessary. Fortunately, advances in technology and tool chain innovation have spawned a large number of new technologies, which greatly accelerated the debugging process.

Let’s take a look at some of these methods

Use instruction tracking technology (ETM/ETB/ETM)

Sometimes the debugging problems faced by developers are only the lowest level problems imaginable in the processor. The existence of tracking technology can monitor a single instruction executed by the processor. This low-level tracking is very useful for monitoring branch coverage when testing and verifying software. The debugging tools used for instruction tracking are different from those used by developers to view the serial line, and the cost is slightly higher.

RTOS tracking

Trying to see the essence of a real-time operating system (RTOS) through its appearance can be quite challenging. Developers do not want to disrupt the performance of the real-time system, but still need some methods to understand the behavior of the system. This is also a trick often used by Blinky LED, but recently more amazing tracking tools have been added to the developer’s toolbox. For example, free commercial RTOS tools, such as TraceX, SystemView, and tracealyzer, etc.

When the RTOS is idle, or there are tasks entering and exiting, the tracking tool allows developers to track and analyze. Developers can monitor system exceptions, response time, execution time, and many other key details required to properly develop an embedded system. The coolest feature of RTOS tracking tools is that they can show what is happening inside the system. Review and sequence diagram monitoring in real time or in log files can allow developers to determine a confidence level to estimate whether the system can operate normally as expected, or to help them find some small problems, otherwise it will take a lot of time to go Look for.

IDE value graph

Nowadays, almost all modern debuggers and IDEs allow developers to monitor the values ​​of variables stored in memory. Developers can select the memory location and value refresh rate, and then start a debugging session. Some IDEs have the ability to monitor the values ​​built into the IDE, while others rely on external software.

Value monitoring is very useful. If the monitored data is associated with a graphical representation, the value it brings is even greater. Plotting values ​​on real-time data is extremely useful for discovering unexpected changes and verifying the generation of specific waveforms. For example, a three-phase brushless DC motor (BLDC motor). If developers want to monitor the current and voltage of each motor support, they need very specific waveforms formed by the drive motor. Plotting the current and voltage of each motor bracket allows developers to see what is happening in real time.

Traditional breakpoint debugging

Every developer is familiar with traditional debugging techniques, setting breakpoints, executing code, and then stepping through the code to monitor, while monitoring registers and variable values. Breakpoint debugging is the most used technique I have seen. However, the results are not very optimistic, because breakpoint debugging is less efficient and usually produces sub-optimal results.

That being the case, why do people still use breakpoint debugging so frequently? The main reason seems to be that breakpoint debugging is easy to use and understand, and developers are optimistic that breakpoints are the right tool for work. This optimism needs to be verified. Breakpoints may destroy the real-time performance of the system, and at the same time draw developers into a black hole, causing them to step through the code endlessly, blindly looking for a solution to the problem.

From printf to SWOIDE value graph

In the high-end ARM Cortex-M series accessories, such as M3/M4, it provides developers 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 tracking. Developers can also customize them and set the information they want to transmit in SWO.

Many developers usually set printf in order to obtain debugging information from their embedded systems. In fact, the serial port pins are not used in the microcontroller, but developers can use SWO to reroute printf information through the debugger. Using the debugger in this way can save the need for a dedicated serial interface, while eliminating the time to develop UART and USB devices, and is more efficient. Now through SWO and debugging hardware, the overhead used by the application program is removed, and the precious clock cycles that may be used by the application program code are reduced.

Concluding remarks

Debugging tools and technologies have developed rapidly in the past few years, especially for high-end microcontrollers. Generally speaking, engineers are visual creatures, and tool suppliers are looking for ways to stimulate vision to reveal what is happening in a real-time system. Configuring debugging tools may require some preliminary work, but spending a little more time on the design can exchange less debugging time, which is indeed a very worthwhile investment in time. Developers should at least be familiar with different debugging tools and available functions, so that when a problem occurs and the system needs to be debugged, they can choose the appropriate tool to complete the task.

The Links:   LQ9D152 NL2432HC22-45A