In software development, perhaps the most critical, yet least predictable stage in the process is debugging. Many factors come into play when debugging software applications. Among these factors, time is of the utmost importance. The time required to set up and debug a software application can have significant impacts on time-to-market, meeting customer expectations, and the financial impact of a well developed product that succeeds in the market. The integration of an application follows a model of multiple spirals through the stages of build, load, debug/tune, and change, as shown in Figure 1.
Figure 1 The integration and debug cycle. The goal is to minimize the number of times around this loop as well as minimizing the time spent in each segment.
Debugging embedded real-time systems is part art and part science. The tools and techniques used in debugging and integrating these systems have a significant impact on the amount of time spent in the debug, integration, and test phase. The more visibility we gain into the running system, the faster we are able to detect and fix bugs.
One of the more traditional and simplest ways of gaining visibility into the system is to add messages at certain points in the software to output information about the state of the system. These messages can be in the form of "printf" statements output to a monitor or the blinking of a LED or set of LEDs to indicate system status and health. Each function or task can begin by outputting a status message to indicate that the system has made it to a certain point in the program. If the system fails at some point, diagnosis of the output messages can help the engineer isolate the problem by knowing where the system was last "good." Of course, instrumenting the system in this way introduces overhead, which changes the behavior of the system. The engineer must either remove the instrumentation after the system has been tested and re-validate the system before shipping, or ship the system with the instrumented code in the system. The engineer must usually ship what is being tested (including this instrumentation) and test what is going to be shipped.
Engineers can use more sophisticated debug approaches to reduce the time spent in the integration and test phase. One approach is the use of a device called a "debug monitor." A debug monitor is a relatively small piece of code embedded in the target application or integrated into the micro controller or DSP core that communicates over a serial interface to a host computer[1]. These monitors provide the ability to download code, read and write DSP memory and registers, set simple and complex breakpoints, single step the program, and profile source code at some level.
For systems with ROM based software programs, another form of debug monitor, called a ROM emulator, is used. A ROM emulator is a plug-in replacement for the target system ROM devices. The plug-in device connects to the host computer over a link (serial, parallel, Ethernet, and so on). A ROM emulator provides the engineer with faster turnaround time during the debugging process. Instead of re-programming the ROM device using a ROM programmer for each software iteration, the code can instead be downloaded into fast RAM on the ROM emulator. The system is then run as if code was running out of the ROM device.
Debug monitors and ROM monitors certainly provide a large benefit to the embedded system debug phase. But, as embedded processors become faster and faster, and as systems migrate to system on a chip solutions, visibility into the internal processor presents challenges that require even more sophisticated debug solutions.
Integrating and debugging complex digital systems also requires the use of sophisticated and complex debug tools such as logic analyzers. A logic analyzer is a tool that allows the system integrator to capture and display digital signals in various formats such as bit, byte, and word formats. Using a logic analyzer, the system integrator can analyze digital behavior such as:
- Digital counters
- Complex state machines
- Buffers and FIFOs
- System buses
- Other system on a chip (SoC) functions such as FPGA, ASIC and standard cell implementations
Logic analyzers are powerful tools that are also portable and very versatile. These tools require a small learning curve as well as high initial investment (depending on how much capability is needed by the tool and what clock rates need to be supported). By using triggering mechanisms in the tool, the system integrator can capture data into large buffers within the logic analyzer. This data can be pre-trigger data, post-trigger data, or a combination. Traces can be saved and printed and the data can be filtered in a number of different ways.
A fundamental disadvantage to using a logic analyzer for embedded DSP software debug is that they are complex hardware debug tools being used for software debug. The degree of success using a logic analyzer is related to how hardware savvy the system integrator is since the tool is hardware-debug based and may require complex setup and configuration to get the right information to analyze.
Another disadvantage to using a logic analyzer for system debug is visibility of the signals. A logic analyzer needs to be connected to the pins of the DSP device in order to get visibility into the system. The visibility is limited by the types of pins on the DSP. As DSP devices become more integrated into system on a chip capability, the visibility to see what is going on inside the device diminishes.
Footnote
1. Arnold Berger provides a very intuitive overview of debuggers in Embedded Systems Design, Chapter 6, CMP Books, copyright 2002.
