[Design View / Design Solution]
Take The Guesswork Out Of Debugging
Move past the hit-and-miss game of “printf()” debugging, and instead look to streamline the task with run-time visualization tools.
Now, consider what might happen if, unbeknownst to this function’s author, the register involved in initialization could only be accessed once every hundred clock cycles. During the debugging process, no problems would be detected, because the first p r i n t f ( )call shown in Figure 2 would provide the requisite separation between the initialization sequence’s two register accesses. Upon removal of p r i n t f ( ), however, the second register access would most likely fail, possibly causing subsequent code to malfunction.
Listing 2 hints at another shortcoming of p r i n t f ( ): this function might not allow you to monitor all of your application’s code. Libraries and operating systems can’t be monitored with p r i n t f ( ) unless you possess the source code for these components. Clearly, if Flash_Reg_Wr() were available only in object code, p r i n t f ( ) would be a cumbersome means of debugging the flash-controller initialization sequence.
Even if you could obtain the source code for Flash_Reg_ Wr(), you would be wise to avoid polluting this code with unnecessary function calls. Typically, p r i n t f ( ) calls, like those shown in Listing 2, must be removed in the latter stages of the development process, either by redefining a configuration constant or by manually deleting code. Until then, the function calls simply constitute additional code that you and your colleagues must maintain.
In a perfect world, this additional code would provide helpful monitoring and debugging capabilities. For engineers who operate in the real world, however, p r i n t f ( ) affords meager benefits. The cryptic messages that rapidly scroll across your debugger’s console as this function is invoked leave you ill-prepared to resolve tricky bugs. If you intend to gather valuable information from your embedded system, you must look beyond printf().
WATCH WINDOWS Conveniently enough, the tool chain already used probably provides alternatives to Watch WindoWs. In particular, the debugger likely incorporates a watch window. As the example shown in Figure 1 indicates, watch windows provide snapshots of an application’s variables.
The basic watch-window theme has multiple variations. Essentially, all watch windows operate similarly. Most display variables in a tabular format. A watch window may require a table to be filled with variable names. Alternatively, this table may be automatically populated with names by the debugger. In either case, whenever a debugger halts execution of an embedded system (for instance, when triggering a breakpoint), the watch window will display the current value of each variable that’s listed.
Usually, the engineer is responsible for interpreting the numbers displayed by the watch window. If, for instance, the watch window indicates that a value of zero was returned by a particular function, it must be determined whether zero means that a grievous problem occurred or that the function completed successfully.
However, there’s a notable exception to this rule. Debuggers that offer what’s commonly known as kernel awareness are specially equipped to assist engineers whose applications incorporate a real-time operating system (RTOS). These debuggers translate variable values into helpful, RTOS-specific status information that’s then displayed in a watch window or a similar interface. Figure 2 shows the output of one such debugger, IAR’s C-SPY.
In many regards, a watch window, even one that’s incapable of displaying RTOS statistics, is a marked improvement over p r i n t f ( ). By using a watch window, the engineer isn’t forced to add a new line of code to an application whenever monitoring a new variable. Consequently, this diminishes the likelihood that debugging efforts will actually become the source of bugs. Freed of the burden of maintaining line upon line of ad hoc debugging code, it’s possible to focus efforts on code that won’t ultimately be deleted. While watch windows can certainly benefit engineers struggling to meet deadlines, they are by no means perfect. Perhaps the most disappointing limitation of watch windows is that they typically don’t allow a running embedded system to be monitored. When debugging efforts involve a watch window, it’s mandatory to stop the execution of code to view fresh variable values.
Regularly halting processors to view a particular variable’s status might not be problematic when debugging, say, an implementation of Quicksort. Code that simply manipulates arrays of integers can be stopped indefinitely. The data required by the code will still be available when execution resumes.
The code running on most embedded systems, though, requires regular data from the outside world. Such I/O-bound code (as opposed to the CPU-bound code of Quicksort) usually can’t be stopped without negative consequences. Accordingly, a watch window is poorly suited for monitoring I/O-bound code.
If you’re unconvinced of this point, consider how to use a watch window to monitor a hypothetical USB device’s software. Imagine that this device regularly receives hundreds of packets from a PC and that the software progresses through multiple states based on the contents of those packets. There would likely not be problems with monitoring the variables associated with the application’s initial state. Engineers could simply stop the processor and consult the watch window.
Reprints
