Figure 52: Realmonitor As A State Machine - Philips LPC2119 User Manual

Philips Semiconductors
ARM-based Microcontroller
How RealMonitor works
In general terms, the RealMonitor operates as a state machine, as shown in Figure 52. RealMonitor switches between running
and stopped states, in response to packets received by the host, or due to asynchronous events on the target. RMTarget
supports the triggering of only one breakpoint, watchpoint, stop, or semihosting SWI at a time. There is no provision to allow
nested events to be saved and restored. So, for example, if user application has stopped at one breakpoint, and another
breakpoint occurs in an IRQ handler, RealMonitor enters a panic state. No debugging can be performed after RealMonitor enters
this state.
Running
A debugger such as the ARM eXtended Debugger (AXD) or other RealMonitor aware debugger, that runs on a host computer,
can connect to the target to send commands and receive data. This communication between host and target is illustrated in
Figure 51.
The target component of RealMonitor, RMTarget, communicates with the host component, RMHost, using the Debug
Communications Channel (DCC), which is a reliable link whose data is carried over the JTAG connection.
While user application is running, RMTarget typically uses IRQs generated by the DCC. This means that if user application also
wants to use IRQs, it must pass any DCC-generated interrupts to RealMonitor.
To allow nonstop debugging, the EmbeddedICE-RT logic in the processor generates a Prefetch Abort exception when a
breakpoint is reached, or a Data Abort exception when a watchpoint is hit. These exceptions are handled by the RealMonitor
exception handlers that inform the user, by way of the debugger, of the event. This allows user application to continue running
without stopping the processor. RealMonitor considers user application to consist of two parts:
• a foreground application running continuously, typically in User, System, or SVC mode
• a background application containing interrupt and exception handlers that are triggered by certain events in user system,
including:
- IRQs or FIQs
- Data and Prefetch aborts caused by user foreground application. This indicates an error in the application being debugged.
In both cases the host is notified and the user application is stopped.
- Undef exception caused by the undefined instructions in user foreground application. This indicates an error in the
application being debugged. RealMonitor stops the user application until a "Go" packet is received from the host.
When one of these exceptions occur that is not handled by user application, the following happens:
RealMonitor
SWI
Abort
Undef
Stop
Stopped
Go

Figure 52: RealMonitor as a state machine

260
LPC2119/2129/2292/2294
SWI
Abort
Undef
Panic
Preliminary User Manual
January 08, 2004