Perhaps the greatest challenge facing embedded system developers today is debugging their software. Embedded systems have become complex and I’m not just talking about the software! Microcontrollers today are 32-bit processors, running upwards of 200 MHz with megabytes of flash and on-chip RAM. These chips have as much power and capability as full-fledged microprocessor systems that PC’s had back in the late 90’s. To match that capability and the growing demand for secure, connected devices with every imaginable feature, the real-time software required to get the hardware working, manage time, tasks and integrate with middleware and application stacks has grown considerably.
As any developer can imagine, this means there is the potential to spend far more time debugging and less time innovating if developers don’t utilize modern debugging techniques. In this post, we’ll examine several different debugging techniques from a high-level and go into more detail on each in future posts. For today, sit back, and stay calm. This blog will give you a 30,000-foot view on what tools are available to you to help squash bugs as quickly as possible.
The debugging techniques that are available to embedded system developers can be categorized into four main categories:
Basic debugging techniques are the tried and true techniques that nearly every developer learns about in school. These techniques include:
These techniques, while tried and true, will not necessarily help a developer in every circumstance. Basic debugging techniques often tend to be invasive which means that the systems real-time behavior and performance are compromised. This is easily demonstrated by considering what happens when a break-point is reached. The application breaks execution and stops on the line that contains the break-point. A developer can then look around, browse memory, etc but the system has been halted.
Newer debugging techniques exist that many embedded developers are not familiar with that can be grouped in a category known as deep insight analysis. In general, these techniques are non-invasive. This means that the application continues to execute while the debugging investigation is being performed. The techniques have minimal to no impact on the real-time system performance which means that a developer doesn’t need to be concerned that their debugging session is compromising or disturbing their system.
The first such technique is known as RTOS aware debugging. RTOS aware debugging allows a developer to monitor how the RTOS is performing such as the CPU load, min, max and average task execution times. Developers can even gain access to critical RTOS control structures to gain insights into how the RTOS is behaving which was never available to developers before.
Back in the good old 8 and 16 bit days, developers just crossed their fingers and guessed at what could be happening in their systems. Run-time analysis now allows a developer to stream events within the RTOS and application to monitor how the application is behaving. The run-time analysis includes information such as a time stamp, the program counter along with other information. This data is stored in a buffer and then transferred to a host PC when the embedded application is idle. The trace data can then be rebuilt on a timeline to provide a developer with a visual representation for when task switches occur, semaphores are put and got, message queues are filled along with much more. This allows a developer to see their program execution and avoid guessing at what their software might be doing, resulting in dramatically decreased debug times.
Finally, developers can use profiling and code coverage analysis to gain useful insights into how their system is performing down to even the single instruction that is being executed. In many instances, this analysis type requires that a developer have an ETM trace port on the microcontroller to glean this information without interfering with the real-time system performance. Once a developer has this information, they gain determine whether their test cases are covering every line of code, all branches and even determine how much application time is spent in various functions.
Combining these different debugging strategies can help a developer very quickly discover what their application is doing and if the behavior is incorrect, they can arrive at a conclusion quickly and efficiently. In the next post, we’ll start the discussion with the break-point capabilities that are built into the Synergy development environment and how they can be used to quickly and efficiently navigate code in real-time before diving into these more advanced techniques.
Until next time,
Live long and profit!
Professor_IoT
Hot Tip of the Week
You can download all the available Module Guides in one convenient bundle. Just go to the Synergy Gallery and select the SSP page. Select the Documentation tab and the SSP 1.3.0 Module Guides are in a convenient Zip file.
https://synergygallery.renesas.com/ssp/support#read
Just download it and feast your eyes on all the module guides in one convenient folder. Sweet!