| ||
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.
| ||