Intel IXC1100, IXP42X - page 127

Intel® IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor
September 2006 DM
Order Number: 252480-006US 127
Intel XScale® Processor—Intel® IXP42X product line and IXC1100 control plane processors
While the processor is still in reset, the debugger should set up the DCSR to trap the
reset vector. This causes a debug exception to occur immediately when the processor
comes out of reset. Execution is redirected to the debug handler allowing the debugger
to perform any necessary initialization. The reset vector trap is the only debug
exception that can occur with debug globally disabled (DCSR[31]=0). Therefore, the
debugger must also enable debug prior to existing the handler to ensure all subsequent
debug exceptions correctly break to the debug handler.
3.6.15.1.1 Setting up Override Vector Tables
The override default vector table intercepts the reset vector and branches to the debug
handler when a debug exception occurs. If the vector table is relocated, the debug
vector is relocated to address 0xffff0000. Thus, an override relocated vector table is
required to intercept vector 0xffff0000 and branch to the debug handler.
Both override vector tables also intercept the other debug exceptions, so they must be
set up to either branch to a debugger specific handler or go to the application’s
handlers.
It is possible that the application modifies its vector table in memory, so the debugger
may not be able to set up the override vector table to branch to the application’s
handlers. The Debug Handler may be used to work around this problem by reading
memory and branching to the appropriate address. Vector traps can be used to get to
the debug handler, or the override vector tables can redirect execution to a debug
handler routine that examines memory and branches to the application’s handler.
3.6.15.1.2 Placing the Handler in Memory
The debug handler is not required to be placed at a specific pre-defined address.
However, there are some limitations on where the handler can be placed due to the
override vector tables and the two-way set associative mini instruction cache.
In the override vector table, the reset vector must branch to the debug handler using:
• A direct branch, which limits the start of the handler code to within 32 Mbytes of
the reset vector, or
• An indirect branch with a data processing instruction. The data processing
instruction creates an address using immediate operands and then branches to the
target. An LDR to the PC does not work because the debugger cannot set up data in
memory before starting the debug handler
The two-way set associative limitation is due to the fact that when the override default
and relocated vector tables are downloaded, they take up both ways of Set 0 (w/
addresses 0x0 and 0xffff0000). Therefore, debug handler code can not be downloaded
to an address that maps into Set 0, otherwise it will overwrite one of the vector tables
(avoid addresses w/ lower 12 bits=0).
The instruction cache two-way set limitation is not a problem when the reset vector
uses a direct branch, since the branch offset can be adjusted accordingly. However, it
makes using indirect branches more complicated. Now, the reset vector actually needs
multiple data processing instructions to create the target address and branch to it.
One possibility is to set up vector traps on the non-reset exception vectors. These
vector locations can then be used to extend the reset vector.
Another solution is to have the reset vector do a direct branch to some intermediate
code. This intermediate code can then uses several instructions to create the debug
handler start address and branch to it. This would require another line in the mini
instruction cache, since the intermediate code must also be downloaded. This method
also requires that the layout of the debug handler be well thought out to avoid the
intermediate code overwriting a line of debug handler code, or vice versa.