Intel® IXP42X product line and IXC1100 control plane processors—Intel XScale® Processor
Intel® IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor
DM September 2006
130 Order Number: 252480-006US
If the dynamic function is already downloaded in the main instruction cache, the
debugger immediately downloads the address, signalling the handler to continue.
The static Debug Handler only needs to support one dynamic function command.
Multiple dynamic functions can be downloaded to different addresses and the
debugger uses the function’s address to specify which dynamic function to execute.
Since the dynamic function is being downloaded into the main instruction cache,
the downloaded code may overwrite valid application code, and conversely,
application code may overwrite the dynamic function. The dynamic function is only
guaranteed to be in the cache from the time it is downloaded to the time the debug
handler returns to the application (or the debugger overwrites it).
• External memory
Dynamic functions can also we downloaded to external memory (or they may
already exist there). The debugger can download to external memory using the
write-memory commands. Then the debugger executes the dynamic command
using the address of the function to identify which function to execute. This method
has the many of the same advantages as downloading into the main instruction
cache.
Depending on the memory system, this method could be much slower than
downloading directly into the instruction cache. Another problem is the application
may write to the memory where the function is downloaded. If it can be guaranteed
that the application does not modify the downloaded dynamic function, the debug
handler can save the time it takes to re-download the code. Otherwise, the ensure
the application does not corrupt the dynamic functions, the debugger should re-
download any dynamic functions it uses.
For all three methods, the downloaded code executes in the context of the debug
handler. The processor will be in Special Debug State, so all of the special functionality
applies.
The downloaded functions may also require some common routines from the static
debug handler, such as the polling routines for reading RX or writing TX. To simplify the
dynamic functions, the debug handler should define a set of registers to contain the
addresses of the most commonly used routines. The dynamic functions can then access
these routines using indirect branches (BLX). This helps reduce the amount of code in
the dynamic function since common routines do not need to be replicated within each
dynamic function.
3.6.15.2.4 High-Speed Download
Special debug hardware has been added to support a high-speed download mode to
increase the performance of downloads to system memory (vs. writing a block of
memory using the standard handshaking).
The basic assumption is that the debug handler can read any data sent by the
debugger and write it to memory, before the debugger can send the next data. Thus, in
the time it takes for the debugger to scan in the next data word and do an Update_DR,
the handler is already in its polling loop, waiting for it. Using this assumption, the
debugger does not have to poll RR to see whether the handler has read the previous
data - it assumes the previous data has been consumed and immediately starts
scanning in the next data word.
The pitfall is when the write to memory stalls long enough that the assumption fails. In
this case the download with normal handshaking can be used (or high-speed download
can still be used, but a few extra TCKs in the Pause_DR state may be necessary to
allow a little more time for the store to complete).
The hardware support for high-speed download includes the Download bit (DCSR[29])
and the Overflow Flag (DCSR[30]).