Different Type of Debug Philosophy

First, lets be realistic about our expectations. A monitor-based debugging environment cant do everything. Its not meant to compete with a top-of-the-line in-circuit emulator (ICE). After you put aside this expectation and re-think the way certain debugging tasks are performed, I think youll agree that monitor-based debugging offers quite a bit of functionality.

Note 

So what do you think of when you think about debugging an embedded system? You might think of a JTAG/BDM-based debug port, an emulator or logic analyzer, the printf() statement, or one of the many sophisticated source-level debuggers available today. Each of these has its own advantages and disadvantages. Some debuggers are very powerful but come at a hefty price. Some are tied to a particular compiler tool set, while others are only useful on certain CPU families. The JTAG-based debug port is probably the most common now because it is a good balance between cost and capability. These devices can still cost a thousand dollars, and then they are only useful if they are connected to the system, usually requiring some bulky pod to hang fairly close to the target.

Ill begin by establishing a debugging model for the boot monitor. Instead of thinking within the confines of a typical breakpoint, think about a runtime analysis that includes the breakpoint as one of its features. I will not consider single stepping, and I will not allow an application to be continued after a breakpoint turns control over to the monitor CLI. I will, however, consider auto-return breakpoints used for runtime analysis. I will also provide a certain amount of access to the symbol table ( variables will be displayable as something more than just a basic memory dump). I will even support the ability to do a stack trace. The major limitation is that the monitor debugger is not able to return control to the running application after a hard breakpoint occurs (see the following Breakpoints section). If you can live with that, you will see that a lot can be done within the so-called limitations of a monitor-based debug environment.