Embedded Systems Firmware Demystified (With CD-ROM)

Overview

I discussed some fundamental debugging steps in an earlier chapter but in the context of debugging the boot code. In this chapter, I will discuss debugging an application residing on top of MicroMonitor, using only the monitors debugging facilities.

Unlike remote, host-directed debugging, monitor-based debugging uses only target resources and only the capabilities built into the target microprocessor. In most cases (not always), monitor-based debugging requires the ability to write into the applications instruction space. Typically, when a breakpoint is set using the monitors command line interface (CLI), the monitor modifies the applications text space or sets some special registers in the processor. The monitor then transfers control to the application. If the instruction at the breakpoint location is executed, control is returned to the monitors CLI.

It is relatively straightforward to give the monitor the ability to display memory. Depending on the complexity of the application being debugged , it may even be reasonable to single step and resume execution following a breakpoint. Thus the monitor can supply the minimal necessary tools for debugging. Because the monitor, however, doesnt have access to the symbolic information in the source code (nearly all of that information remains on the host with the compiler), monitor-based debugging poses some serious challenges.

For example:

• How do you display memory? Because you are running at the CLI of the target, you cant just ask for a structure by name . Instead, you probably need to look up the symbols address in the output map file generated by the linker and ask the debugger to display memory at that address. Moreover, the monitor doesnt know anything about variable types. Because it doesnt know the symbol type, it wont know how many bytes to fetch for shorts , longs , or char strings. And you can forget about structure display.

• How do you specify a breakpoint location? Again, the lack of symbolic information changes everything. You cant just say set a breakpoint at function foo. Instead, you must first look up the address of the function. After you know the load address, then you can issue some command, such as b 0x123456 where 0x123456 is the address where you want the breakpoint. Keep in mind, you probably need to perform this lookup every time you want to set a breakpoint at f oo() , because each time you rebuild the application, the address could be different. The simplest steps can turn into tedious processes.

• How do you correlate the assembly language execution with your source code? Single-stepping is now at the assembler level, not the C level. Single-stepping at the assembler level isnt very useful for a high-level programmer.

• How does the monitor talk to the serial port? When the breakpoint occurs, the monitor takes over, but the application now owns the serial port. If the monitor reinitializes the serial port for its use, the interface between the application and the serial port is likely to be lost, which means returning control to the application is difficult.

• How does the monitor temporarily shut down the application? When the breakpoint occurs, the monitor takes over the system. If the application is an RTOS-hosted task, with interrupts enabled and a variety of different peripherals configured, how does the monitor deal with shutting all this stuff down?

The preceding list explains why monitor-based debugging isnt that popular. It aint easy! Before you give up on it though, Id like to re-investigate the topic and see if there just might be some breath left in the old beast .