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 monitor s 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 application s instruction space. Typically, when a breakpoint is set using the monitor s command line interface (CLI), the monitor modifies the application s 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 monitor s 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, doesn t 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 can t just ask for a structure by name. Instead, you probably need to look up the symbol s address in the output map file generated...