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
132 Order Number: 252480-006US
These actions ensure that the application program executes correctly after the
debugger has been disconnected.
3.6.16 Software Debug Notes and Errata
• Trace buffer message count value on data aborts:
LDR to non-PC that aborts gets counted in the exception message. But an LDR to
the PC that aborts does not get counted on exception message.
• SW Note on data abort generation in Special Debug State.
— Avoid code that could generate precise data aborts.
— If this cannot be done, then handler needs to be written such that a memory
access is followed by 1 nops. In this case, certain memory operations must be
avoided - LDM, STM, STRD, LDC, SWP.
• Data abort on Special Debug State:
When write-back is on for a memory access that causes a data abort, the base
register is updated with the write-back value. This is inconsistent with normal (non-
SDS) behavior where the base remains unchanged if write-back is on and a data
abort occurs.
• Trace Buffer wraps around and loses data in Halt Mode when configured for fill-once
mode:
It is possible to overflow (and lose) data from the trace buffer in fill-once mode, in
Halt Mode. When the trace buffer fills up, it has space for 1 indirect branch
message (5 bytes) and 1 exception message (1 Byte).
If the trace buffer fills up with an indirect branch message and generates a trace
buffer full break at the same time as a data abort occurs, the data abort has higher
priority, so the processor first goes to the data abort handler. This data abort is
placed into the trace buffer without losing any data.
However, if another imprecise data abort is detected at the start of the data abort
handler, it will have higher priority than the trace buffer full break, so the processor
will go back to the data abort handler. This 2nd data abort also gets written into the
trace buffer. This causes the trace buffer to wrap-around and one trace buffer entry
is lost (oldest entry is lost). Additional trace buffer entries can be lost if imprecise
data aborts continue to be detected before the processor can handle the trace
buffer full break (which will turn off the trace buffer).
This trace buffer overflow problem can be avoided by enabling vector traps on data
aborts.
• TXRXCTRL.RR prevents TX register from being updated (even if TXRXCTRL.TR is
clear). This will be fixed on B0-step.
The problem is that there is incorrect (and unnecessary) interaction between the
RX ready (RR) flag and writing the TX register. The debug handler looks at the TX
ready bit before writing to the TX register. If this bit is clear, then the handler
should be able to write to the TX register. However, in the current implementation
even if the TR bit is clear, if the RR bit is set, TX will be unchanged when the
handler writes to it. It is OK to prevent a write to TX when the TR bit is set (since
the host has not read the previous data in the TX, and we don’t want a write to TX
to overwrite previous data).
• The TXRXCTRL.OV bit (overflow flag) does not get set during high-speed download
when the handler reads the RX register at the same time the debugger writes to it.
If the debugger writes to RX at the same time the handler reads from RX, the
handler read returns the newly written data and the previous data is lost. However,
in this specific case, the overflow flag does not get set, so the debugger is unaware
that the download was not successful.