Embedded Systems Firmware Demystified

First, let s be realistic about our expectations. A monitor-based debugging environment can t do everything. It s 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 you ll 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. |
I ll 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...