Typically, embedded platforms are too resource limited and specialized to support a full-featured debugger. Debuggers for embedded systems address this limitation by distributing the debugger; a portion of the debugger resides on the host computer, and a portion resides in the target system. The two elements of the debugger communicate with each other over a communications channel, such as a serial port or Ethernet port. The portion of the debugger that resides in the target is called the target agent or the debug kernel. The portion of the debugger that resides in the host computer is sometimes called the debugger front end or GUI. The same functionality that you expect from your host debugger is generally available in an embedded debugger, assuming that you have a spare communications channel available. Figure 6.4 shows a typical architectural block diagram for an embedded debugger. (The Wind River debug kernel is a bit more complex than most because it is integrated with VxWorks, Wind River s RTOS.)

Figure 6.4: Typical architectural block diagram.

Schematic representation of the Wind River Systems debugger (courtesy of Wind River Systems).

The debugger generally provides a range of run control services. Run control services encompass debugging tasks such as:

• Setting breakpoints

• Loading programs from the host

• Viewing or modifying memory and registers

• Running from an address

• Single-stepping the processor

The debugging features encompassed by run control are certainly the most fundamental debugging tools available. The combination of the functionality of the remote debug kernel...