Nxp Semiconductors UM10237 ユーザーズマニュアル
UM10237_2
© NXP B.V. 2008. All rights reserved.
User manual
Rev. 02 — 19 December 2008
750 of 792
NXP Semiconductors
UM10237
Chapter 35: LPC24XX RealMonitor
3.2 How RealMonitor works
In general terms, the RealMonitor operates as a state machine, as shown in
. 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.
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.
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
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
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.
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.
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:
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
mode
•
A background application containing interrupt and exception handlers that are
triggered by certain events in user system, including:
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.
user application is stopped.
Fig 150. RealMonitor as a State Machine
RUNNING
STOPPED
PANIC
stop
go
SWI abort
undef
SWI abort
undef