Intel 80200 Processor based on Intel XScale Microarchitecture

Errata14. Preload instruction may stall for up to three cyclesProblem:Workaround:A Preload (PLD) instruction may stall if one of the three operations before it is a memoryoperation. The stall may be for up to three cycles even if these instructions are in the cache.Make sure the three instructions before a PLD instruction are not memory operations.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.15. Debug overflow flag not set when debugger writes RX at same time ashandler reads RXProblem:Workaround:Typically the software debugger and the handler never access the RX register at the same timebecause of the RX handshaking via the RR bit in TXRXCTRL. However, during high-speeddownload, the debugger and handler bypass part of this handshaking. The debugger skips the checkto see whether the handler has read the previous data because ideally the handler is waiting for thenew data by the time the debugger does an Update_DR.The problem occurs because the debugger skips this check. In the test, the handler reads the firstdata word and stalls during the store. During this time the debugger scans in the second word andstarts scanning in the third word. Then the handler unstalls and sees that the data is valid in RX. Soas it reads the data, at the same time the debugger completes scanning in the third word. It turns outthat the handler see this third word, not the second word, which is OK since this is just an overflowcondition. But the problem is that the overflow flag is not set. So the handler continues and storesthis data out, but it lost the second word.So this is a problem for the debugger because the code and data it just downloaded is corrupted.The high-speed download is a feature for enhancing debugger performance during code download.A debugger can work around this for now by either not using it or restricting usage to memoryregions which are guaranteed to be fast enough not to run into this problem. The alternative routineis the normal write_mem function, which does the normal handshaking, although it can be muchslower depending on how the debugger implements the handshaking.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.16. Instruction executes multiple times under certain code sequencesProblem:Workaround:If the following sequence of instructions executes:MCR invalidate TLBMCR any IFU (instruction fetch unit) or IMMU commandCISC any instruction that requires multiple issue cyclesInstructions nInstruction n+1Then instruction n+1 executes multiple timesBreak the MCR (Move to Coprocessor from ARM Register) sequence above with any instruction,such as the CPWAIT routine described in section 2.3.3 of the <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on<strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual, an ARM architecture compliantdocument.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.16 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update