Intel 80200 Processor based on Intel XScale Microarchitecture

<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on<strong>Intel</strong> ® XScale MicroarchitectureSpecification UpdateJanuary 22, 2003Notice: The <strong>Intel</strong> ® <strong>80200</strong> processor may contain design defects or errors known as errata.Characterized errata that may cause the product’s behavior to deviate from publishedspecifications are documented in this specification update.Order Number: 273415-011

Information in this document is provided in connection with <strong>Intel</strong> ® products. No license, express or implied, by estoppel or otherwise, to any intellectualproperty rights is granted by this document. Except as provided in <strong>Intel</strong>'s Terms and Conditions of Sale for such products, <strong>Intel</strong> assumes no liabilitywhatsoever, and <strong>Intel</strong> disclaims any express or implied warranty, relating to sale and/or use of <strong>Intel</strong> products including liability or warranties relating tofitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. <strong>Intel</strong> products are notintended for use in medical, life saving, or life sustaining applications.<strong>Intel</strong> may make changes to specifications and product descriptions at any time, without notice.Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." <strong>Intel</strong> reserves these forfuture definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.<strong>Intel</strong> ® internal code names are subject to change.Contact your local <strong>Intel</strong> sales office or your distributor to obtain the latest specifications and before placing your product order.Copies of documents which have an ordering number and are referenced in this document, or other <strong>Intel</strong> literature may be obtained by calling1-800-548-4725 or by visiting <strong>Intel</strong>'s website at http://www.intel.com.Copyright © <strong>Intel</strong> Corporation, 2003AlertVIEW, i960, AnyPoint, AppChoice, BoardWatch, BunnyPeople, CablePort, Celeron, Chips, Commerce Cart, CT Connect, CT Media, Dialogic,DM3, EtherExpress, ETOX, FlashFile, GatherRound, i386, i486, iCat, iCOMP, Insight960, InstantIP, <strong>Intel</strong>, <strong>Intel</strong> logo, <strong>Intel</strong>386, <strong>Intel</strong>486, <strong>Intel</strong>740,<strong>Intel</strong>DX2, <strong>Intel</strong>DX4, <strong>Intel</strong>SX2, <strong>Intel</strong> ChatPad, <strong>Intel</strong> Create&Share, <strong>Intel</strong> Dot.Station, <strong>Intel</strong> GigaBlade, <strong>Intel</strong> InBusiness, <strong>Intel</strong> Inside, <strong>Intel</strong> Inside logo, <strong>Intel</strong>NetBurst, <strong>Intel</strong> NetStructure, <strong>Intel</strong> Play, <strong>Intel</strong> Play logo, <strong>Intel</strong> Pocket Concert, <strong>Intel</strong> SingleDriver, <strong>Intel</strong> SpeedStep, <strong>Intel</strong> StrataFlash, <strong>Intel</strong> TeamStation,<strong>Intel</strong> WebOutfitter, <strong>Intel</strong> Xeon, <strong>Intel</strong> XScale, Itanium, JobAnalyst, LANDesk, LanRover, MCS, MMX, MMX logo, NetPort, NetportExpress, Optimizerlogo, OverDrive, Paragon, PC Dads, PC Parents, Pentium, Pentium II Xeon, Pentium III Xeon, Performance at Your Command, ProShare,RemoteExpress, Screamline, Shiva, SmartDie, Solutions960, Sound Mark, StorageExpress, The Computer Inside, The Journey Inside, This Way In,TokenExpress, Trillium, Vivonic, and VTune are trademarks or registered trademarks of <strong>Intel</strong> Corporation or its subsidiaries in the United States andother countries.*Other names and brands may be claimed as the property of others.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

ContentsRevision History ......................................................................................... 5Preface....................................................................................................... 6Summary Table of Changes....................................................................... 7Identification Information...........................................................................11Errata ....................................................................................................... 13Specification Changes ............................................................................. 36Specification Clarifications ....................................................................... 39Documentation Changes ......................................................................... 40<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 3

This Page Intentionally Left Blank4 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Revision HistoryscDate Version Description1/22/2003 0118/05/2002 0104/2/2002 00912/20/01 00809/24/01 007Added Specification Changes 4 and 5.Added Documentation Change 15.Added errata 47 through 49.Revised and moved Specification Change 1 to Specification Clarification 2.Added Specification Clarification 3.Added Documentation Changes 13 and 14.Added Errata 43 through 46.Added Document Changes 11 and 12.Added Errata 40, 41 and 42. Updated errata 5 and 34.Added Specification Change 3.Added Document Changes 9 and 10.Added Errata 38 and 39.Added Specification Change 2.Added Document Change 8.Added Device ID’s for C-0 Stepping.07/10/01 006Added Errata 34 through 37.Added C-0 Stepping column to Errata, Specification Changes and SpecificationClarifications.Added Document Changes 6 and 7.Removed “MALAY” from Topside Markings.Added JTAG Device IDs to Device ID Registers.Corrected page number in Document Change 2 heading.Added Affected Document to Document Changes 2 through 5.05/05/01 005 Corrected JTAG ID in Document Change1.04/04/01 004Added Errata 28 through 33.Added Specification Clarification 1.Added Document Changes 2 through 5.12/08/00 003Added Errata 20 through 27.Added Step A-1 column to Errata.Added Specification Change 2.Added Document Change 1.Added A-1 Stepping row to Device ID Registers09/29/00 002 Added errata 17, 18 and 19.09/25/00 001This is the new Specification Update document. It contains all identified erratapublished prior to this date.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 5

PrefacePrefaceThis document is an update to the specifications contained in the Affected Documents/RelatedDocuments table below. This document is a compilation of device and documentation errata,specification clarifications and changes. It is intended for hardware system manufacturers andsoftware developers of applications, operating systems, or tools.Information types defined in Nomenclature are consolidated into the specification update and areno longer published in other documents.This document may also contain information that was not previously published.Affected Documents/Related DocumentsTitle Order #<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual 273411<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Datasheet 273414<strong>Intel</strong> ® 80310 I/O <strong>Processor</strong> Chipset with <strong>Intel</strong> ® XScale Microarchitecture Design Guide 273354<strong>Intel</strong> ® 80312 I/O Companion Chip Developer’s Manual 273410<strong>Intel</strong> ® 80312 I/O Companion Chip Specification Update 273416NomenclatureErrata are design defects or errors. These may cause the <strong>Intel</strong> ® 80303 I/O <strong>Processor</strong>’s behavior todeviate from published specifications. Hardware and software designed to be used with any givenstepping must assume that all errata documented for that stepping are present on all devices.Specification Changes are modifications to the current published specifications. These changeswill be incorporated in any new release of the specification.Specification Clarifications describe a specification in greater detail or further highlight aspecification’s impact to a complex design situation. These clarifications will be incorporated inany new release of the specification.Documentation Changes include typos, errors, or omissions from the current publishedspecifications. These will be incorporated in any new release of the specification.Note:Errata remain in the specification update throughout the product’s lifecycle, or until a particularstepping is no longer commercially available. Under these circumstances, errata removed from thespecification update are archived and available upon request. Specification changes, specificationclarifications and documentation changes are removed from the specification update when theappropriate changes are made to the appropriate product specification or user documentation(datasheets, manuals, etc.).6 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Summary Table of ChangesSummary Table of ChangesThe following table indicates the errata, specification changes, specification clarifications, ordocumentation changes which apply to the <strong>Intel</strong> ® 80303 I/O <strong>Processor</strong> product. <strong>Intel</strong> may fix someof the errata in a future stepping of the component, and account for the other outstanding issuesthrough documentation or specification changes as noted. This table uses the following notations:Codes Used in Summary TableSteppingPageX: Errata exists in the stepping indicated. Specification Change orClarification that applies to this stepping.(No mark)or (Blank box): This erratum is fixed in listed stepping or specification change does notapply to listed stepping.(Page):Page location of item in this document.StatusDoc:PlanFix:Fixed:NoFix:Document change or update will be implemented.This erratum may be fixed in a future stepping of the product.This erratum has been previously fixed.There are no plans to fix this erratum.RowChange bar to left of table row indicates this erratum is either new ormodified from the previous version of the document.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 7

Summary Table of ChangesErrata (Sheet 1 of 2)No.SteppingsA-0 A-1 B-0 C-0 D-0Page Status Errata1 X X 13 FixedBranch and Link instruction does not branch after BranchTarget Buffer (BTB) invalidate2 X X X X X 13 NoFix Multiple ECC errors reported on a single transaction3 X X 13 FixedPerformance Monitor Control Register (PMCR) needs anextra write on initial enable of branch count4 X X 13 FixedInvalidates and cleans of the Translation Look-aside Buffer(TLB) and cache, will PIDify the address5 X X X X X 14 NoFix External abort is missed when lock command is outstanding6 X X 14 Fixed Data Cache generates imprecise aborts on Preload (PLD)7 X X X X X 14 NoFix Dynamic steering of interrupts results in recursive interrupts8 X X 14 Fixed Back to back aborts on store requests cause incorrect data9 X X X X X 15 NoFix10 X X 15 Fixed11 X X 15 Fixed12 X X 15 FixedLast abort is missed on read/write/write sequence withexternal abortsClock Counter (CCNT) needs to be reset before using64-divide modeIncorrect interaction between RX ready flag and writing to theTX registerThe overflow bit in the Performance Monitor Unit (PMU) isset at 0xffffffff in 64-divide mode instead of 013 X X 15 FixedPerformance Monitor Unit overflow erroneously clearsprevious overflow flag14 X X 16 Fixed Preload instruction may stall for up to three cycles15 X X 16 Fixed16 X X 16 Fixed17 X X X X X 17 NoFix18 X 18 FixedDebug overflow flag not set when debugger writes RX atsame time as handler reads RXInstruction executes multiple times under certain codesequencesBoundary scan is not fully compliant to the IEEE 1149.1specificationStore of less than a word length, corrupts data of a previousaborting store19 X X 18 FixedBack to back I/O transactions are not synchronized asspecified20 X X X X X 19 NoFix Drain is not flushed correctly when stalled in the pipeline21 X X X X X 19 NoFixUndefined data processing-'like' instructions are interpretedas an MSR instruction22 X X X X X 20 NoFix Debug unit synchronization with the TXRXCTRL register23 X X X X X 20 NoFixSynchronization Request is not asserted when the DataCache Unit pipe is empty24 X X 20 Fixed Data Cache parity eviction25 X X 21 FixedDirty bits are not cleared on invalidate by address to DataCache Unit26 X X 21 Fixed Vector trap is lost in the presence of a stall27 X X X X X 21 NoFix Extra circuitry is not JTAG boundary scan compliant28 X X X X X 22 NoFixIncorrect decode of Unindexed Mode, using AddressingMode 5, can corrupt protected registers8 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Summary Table of ChangesErrata (Sheet 2 of 2)No.SteppingsA-0 A-1 B-0 C-0 D-0Page Status Errata29 X X X X X 22 NoFix Load immediately following a DMM flush entry is also flushed30 X X X X X 22 NoFix Trace Buffer does not operate below 1.3 V31 X X 23 FixedThumb branch with the Branch Target Buffer enabled, can goto the wrong address32 X X X X X 23 NoFix Back to back external aborts can cause a hang33 X X X X X 23 NoFix Data Cache Unit can stall for a single cycle34 X X X X X 24 NoFixAborted Store that Hits the Data Cache May MarkWrite-Back Data as Dirty35 X X X 24 FixedData Cache Unit Signals Incorrect Number of Misses orMemory Operations to the Performance Monitoring Unit36 X X X 25 Fixed Incorrect ECC Attribute Used on Instruction Fetch37 X X X 25 Fixed Performance Monitoring Unit May Miscount SWI/UNDEFs38 X X X 26 Fixed39 X X X 27 Fixed40 X X X X 28 Fixed41 X X 31 Fixed42 X X 31 Fixed43 X X X X X 32 NoFix44 X X X X X 32 NoFix45 X X X X 33 Fixed46 X X 34 Fixed47 X X X X X 34 NoFix48 X X X X X 35 NoFix49 X X X X X 35 NoFixTLB Lookup in Special Debug State May Use Incorrect PageAttribute Bit Values on Subsequent Code FetchesCP15 Data Cache Unlock Command Can Cause Unlock inUser Mode or when Flushed from the Pipe in SupervisorModeStore to cacheable memory, interrupted by an exception,may inadvertently write to memoryData cache dirty bits may be corrupted if a line invalidate isfollowed immediately by a storeData cache dirty bits may be corrupted if a bus error on acache line fill is followed immediately by a storePerformance Monitor Unit event 0x1 can be incrementederroneously by unrelated eventsIn Special Debug State, back-to-back memory operations —where the first instruction aborts — may cause a hangInstruction Memory Management Unit address translation isturned off for the first fetch after exiting Special Debug StateData cache dirty bits may be corrupted if a store to cacheablememory occurs during a tag replacement for a differentcache lineAccesses to the CP15 ID register with opcode2 > 0b001returns unpredictable valuesDisabling and re-enabling the MMU can hang the core orcause it to execute the wrong codeUpdating the JTAG parallel registers requires an extra TCKrising edge<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 9

Summary Table of ChangesSpecification ChangesNo.SteppingsA-0 A-1 B-0 C-0 D-0Page Status Specification Changes1 X X X X X 39 Doc Revised and moved to Specification Clarification 2.2 X X X X X 36 Doc Drowsy Mode has been De-Specified3 X X 36 New ECC Disable Bit Available on the C-0 and D-0 Step4 X 36 200MHz <strong>Processor</strong> Available5 X 37 Extended Temperature Products AvailableSpecification ClarificationsNo.SteppingsA-0 A-1 B-0 C-0 D-0Page Status Specification Clarifications1 X X X X X 39 Doc TRST# Usage2 X X X X X 39 Doc STRD and LDRD Instructions3 X X X X X 39 Doc Write Coalescing with the <strong>Intel</strong> ® 80312 I/O Companion ChipDocumentation ChangesNo. Document Revision Page Status Documentation Changes1 273411-002 40 Doc Section C.2.4.1, Table C-42 273411-002 40 Doc Example 6-3 on page 6-12 may not work properly3 273411-002 41 DocFigure 13-12 on page 13-39 and Figure 13-13 on page 13-41 show incorrectsignal states4 273411-002 41 Doc Section A.2 on page A-2 has incorrect text5 273411-002 41 Doc Section B.2.3.1 on page B-6 has incorrect text6 273411-002 41 Doc Table 7-3 on page 7-4 shows incorrect register access7 273411-002 41 Doc Table 7-15 on page 7-13 shows incorrect register access8 273411-002 42 DocAll References to Drowsy Mode should be Removed from the <strong>80200</strong>Developer’s Manual9 273411-002 42 Doc Table 11-6 on page 11-10 has a new bit function for ECTST.3110 273411-002 42 Doc Figure C-2 on page C-7 shows an incorrect state11 273411-002 42 Doc Example code is incorrect on page 13-1512 273411-002 42 Doc Example code is incorrect on page 13-4513 273411-002 42 Doc Number of clocks is incorrect on page 8-214 273411-002 43 Doc Figure 10-12 on page 10-22 shows incorrect BE# value15 273411-002 43 Doc Example code is incorrect on page 7-1710 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Identification InformationIdentification InformationMarkingsTopside MarkingsFW<strong>80200</strong>Mxxx{FPO#}SLxxxINTEL © ‘2000M<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong>Die Details (Sheet 1 of 2)Part NumberSteppingQDF/SpecificationNumberVoltage(V)<strong>Intel</strong> ®<strong>80200</strong><strong>Processor</strong>Speed(MHz)NotesFW<strong>80200</strong> A-0 Q198 1.3 333-733 Samples - limited testingFW<strong>80200</strong>M400FW<strong>80200</strong>M600FW<strong>80200</strong>M733FW<strong>80200</strong>M733A-1A-1A-1A-1SL589SL58BSL58CQ2891.31.51.51.5up to 400up to 600up to 733up to 733Limited ProductionLimited ProductionLimited ProductionGeneral SamplesFW<strong>80200</strong>M400FW<strong>80200</strong>M600FW<strong>80200</strong>M733B-0B-0B-0SL58DSL58ESL58F1.31.51.5up to 400up to 600up to 733Not Production MaterialNot Production MaterialNot Production MaterialFW<strong>80200</strong>M600FW<strong>80200</strong>M733FW<strong>80200</strong>M400FW<strong>80200</strong>M600FW<strong>80200</strong>M733C-0C-0C-0C-0C-0Q308Q309SL5YHSL5YJSL5YK1.51.51.31.51.5up to 600up to 733up to 400up to 600up to 733General SamplesGeneral SamplesProduction MaterialProduction MaterialProduction Material<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 11

Identification InformationDie Details (Sheet 2 of 2)Part NumberSteppingQDF/SpecificationNumberVoltage(V)<strong>Intel</strong> ®<strong>80200</strong><strong>Processor</strong>Speed(MHz)NotesFW<strong>80200</strong>M600FW<strong>80200</strong>M733FW<strong>80200</strong>M200FW<strong>80200</strong>M400FW<strong>80200</strong>M600FW<strong>80200</strong>M733FW<strong>80200</strong>M200TFW<strong>80200</strong>M400TFW<strong>80200</strong>M600TFW<strong>80200</strong>M733TD-0D-0D-0D-0D-0D-0D-0D-0D-0D-0Q367Q368SL6WLSL676SL677SL678SL6WMSL6WNSL6WPSL6WQ1.51.51.11.31.51.51.11.31.51.5up to 600up to 733up to 200up to 400up to 600up to 733up to 200up to 400up to 600up to 733General SamplesGeneral SamplesProduction MaterialProduction MaterialProduction MaterialProduction MaterialExt Temp. Prod. MaterialExt Temp. Prod. MaterialExt Temp. Prod. MaterialExt Temp. Prod. MaterialDevice ID RegistersDevice andStepping<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture(ARM* architecture compliant)Device ID (CP15, Register0 - opcode_2=0)JTAG Device IDA-0 0x69052000 0x09263013A-1 0x69052001 0x19263013B-0 0x69052002 0x29263013C-0 0x69052003 0x39263013D-0 0x69052004 0x4926301312 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

ErrataErrata1. Branch and Link instruction does not branch after Branch Target Buffer(BTB) invalidateProblem:A branch and link (BL) instruction after a BTB invalidate can branch to the wrong address. Thiscould result in incorrect software operation. The BTB invalidate can happen with a CP15 register 7function, a write to the Process ID register, or when the instruction cache is invalidated via CP15register 7 function.Workaround: Flush the execution pipeline after code that invalidates the BTB. For example, the followinginstruction does this:SUB PC, PC, #4 ;flush the pipeStatus: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.2. Multiple ECC errors reported on a single transactionProblem:Workaround:A multi-bit ECC error is logged on more than one 64-bit bus cycle of a cache line fill. In somesituations (specifically when a store is issued soon after the cache line fill), the bus controlleridentifies an extra error back to the core. The effect is that multiple data aborts are taken. The extraabort occurs soon after the real abort (before the link register of the first abort is saved off). Theeffect is to lose the original link register. This can be identified by detecting when the link registerpoints to the beginning of the data abort handler and that only one error is logged in the buscontroller registers.Software can detect the situation if it occurs, but recovery may be impossible. Systems have littlealternative other than logging the error and returning back to a stable state, which may entail asystem restart.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.3. Performance Monitor Control Register (PMCR) needs an extra write oninitial enable of branch countProblem:Workaround:When first enabling the counting of event 0x5, branch instruction executed, the PerformanceMonitoring Unit can incorrectly count a branch that never occurs.Write the PMCR register twice. The first time the Counter Rest bit is set and the Enable bit is a“don’t care”. The second time, both the Counter Reset and Enable bits must be set.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.4. Invalidates and cleans of the Translation Look-aside Buffer (TLB) andcache, will PIDify the addressProblem:Workaround:When invalidating of cleaning a TLB or cache entry, the address is getting ORed by the ProcessID. This issue only occurs when the first 7 bits of the address are zero and the Process ID is ineffect.Always supply a Modified Virtual Address (MVA) to these functions, or disable the PID byzeroing it before performing these operation.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 13

Errata5. External abort is missed when lock command is outstandingProblem:A bus abort occurs on a code fetch while an instruction TLB or I-Cache lock MCR, Move toCoprocessor from ARM Register, command is outstanding. The <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> fails toabort, instead executing the instruction returned on the aborting transaction. Parity errors are notaffected. The bus abort may be due to either an ABORT pin assertion or a multi-bit ECC error.Workaround: Branch flush after every I-TLB or I-Cache lock. For example, the following instruction does this:SUB PC, PC #4 ;flush the pipeStatus: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.6. Data Cache generates imprecise aborts on Preload (PLD)Problem:Workaround:Even though all exceptions generated by PLD are supposed to be ignored, exceptions caused byparity, ECC, and bus aborts are not currently ignored. These errors can be generated either by thedata being pre-loaded or the data being evicted. Errors due to the evicted data should not be maskedsince these errors can not be safely ignored.Systems may be able to avoid external aborts by ensuring that the page table prohibits access tothese areas of memory. Parity errors and multi-bit ECC errors are not predictable and could in rarecases generate exceptions.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.7. Dynamic steering of interrupts results in recursive interruptsProblem:Workaround:If the Performance Monitoring Unit (PMU) or Bus Controller Unit (BCU) interrupts are unmaskedwhen steering is changed via INTSTR, then any previously captured interrupt is not cleared. Thisresults in multiple interrupt exceptions.Mask interrupts in INTCTL before changing the PMU steering.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.8. Back to back aborts on store requests cause incorrect dataProblem:Workaround:When two back to back burst store requests get aborted, external bus ABORT pin only, then the<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> sends incorrect data on the external bus for the next request.Systems that use the <strong>Intel</strong>® 80312 I/O companion chip do not encounter this problem, since it doesnot support multiple outstanding memory requests. For a pipelined memory accessimplementation, there is no way to avoid the possibility of a corrupted store. The only suggestionis, to avoid having that store being the one that is necessary for your data abort handler to report outdebugging and failure information. Because only the first store after the pair of aborts is affected, adummy store to non-cacheable memory at the beginning of the data abort handler guarantees thatlater necessary stores in the handler are not corrupted.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.14 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata9. Last abort is missed on read/write/write sequence with external abortsProblem:Workaround:This errata occurs when a read/write/write sequence occurs on the external bus with all three beingaborted by assertion of the external ABORT pin. The first two aborts are separated by only therequired single dead cycle and global ECC enable is on. If there is a write that does not abort afterthe read/write pair, this errata does not occur.Systems that use the <strong>Intel</strong>® 80312 I/O companion chip do not encounter this problem, since it doesnot support multiple outstanding memory request. With other chipsets, this scenario is unlikely tooccur. If the second store that aborts is already in the pipeline when the first abort occurs, then themachine state is exactly as expected (multiple aborts reported and the BCU registers have tworecorded aborts and the overflow bit is set). If the second store is a store issued in the data aborthandler and then aborts, the abort is not reported. However, if you are getting aborted stores in thedata abort handler, something is seriously wrong. If there was a valid reason for getting an externalabort on a store in the data abort handler, doing a dummy non-cacheable store at the beginning ofthe data abort handler fixes the state machine.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.10. Clock Counter (CCNT) needs to be reset before using 64-divide modeProblem:Workaround:If the clock counter register (CCNT) in the Performance Monitor Unit is not reset before setting theClock Counter Dived bit (PMNC.3) to count evert 64 th processor clock cycles, then the CCNTregister fails to increment.Reset the CCNT register before programming the clock counter divider bit in the PMNC.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.11. Incorrect interaction between RX ready flag and writing to the TX registerProblem:Workaround:This problem only affects debug handlers or monitors that use the TX/RX registers to read andwrite through the JTAG interface. The TR (TX ready) bit synchronizes the writes to the TXregister. If the TR bit is clear, then software should be able to safely write to the TX register. Butwith this problem, even if the TR (TX ready) bit is clear, then software writes to the TX registermight not update the TX register.Debug handler workaround exists.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.12. The overflow bit in the Performance Monitor Unit (PMU) is set at 0xffffffff in64-divide mode instead of 0Problem:Workaround:In the Performance Monitoring Unit 64-divide mode, the overflow bit is set when CCNT reaches0xffffffff instead of when CCNT rolls over to 0.No workaround.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.13. Performance Monitor Unit overflow erroneously clears previous overflowflagProblem:Workaround:In the Performance Monitoring Unit, if one of the overflow flags is set, PMNC[10:8], and anotheroverflow occurs, then the first overflow bit in PMNC[10:8] gets cleared.No workaround.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 15

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

Errata17. Boundary scan is not fully compliant to the IEEE 1149.1 specificationProblem:Workaround:The IEEE Standard 1149.1 specifies the boundary scan logic to support two main goals:a. To allow the interconnections between the various components to be tested, test data canbe shifted into all the boundary-scan register cells associated with component output pinsand loaded in parallel through the component interconnections into those cells associatedwith inputs pins; andb. To allow the components on the board to be tested, the boundary-scan register can beused as a means of isolating on-chip system logic from stimuli received from surroundingcomponents while an internal self-test is performed. Alternatively, if the boundary-scanregister is suitably designed, it can permit a limited slow-speed static test of the on-chipsystem logic since it allows delivery of test data to the component and examination of thetest results. (IEEE std. 1149.1-1990, page 1-5)The <strong>Intel</strong>® <strong>80200</strong> processor does not support the second goal, because it does not support theoptional INTEST or RUBIST instructions. The <strong>Intel</strong>® <strong>80200</strong> processor is not required to providethese instructions, however, since it doesn't, this makes the following statement practically invalid.The IEEE std. 1149.1 description of the SAMPLE/PRELOAD instruction states that “When theSAMPLE/PRELOAD instruction is selected, the state of all signals flowing through system pins(input or output) shall be loaded into the boundary scan register on the rising edge of the TCK inthe Capture-DR controller state.” (Page 7-8).The boundary scan cells of the <strong>Intel</strong>® <strong>80200</strong> processor bidirectional pads do not capture the datadriven from the on-chip system logic to the pins when these pads are acting as outputs. This wouldonly be useful if a customer was trying to capture the data driven from the on-chip logic duringnormal operation of the assembled board. However, the <strong>Intel</strong>® <strong>80200</strong> processor does not allowsingle stepping of its clocks. Thus, even if the <strong>Intel</strong>® <strong>80200</strong> processor did provide the compliantboundary scan cell, it would be extremely difficult (or impossible) to synch the boundary scanlogic with the state of the on-chip logic. Therefore, this feature of the boundary scan cells is notuseful. This has NO effect on the customer's ability to determine the integrity of theinterconnections on their boards which is what the <strong>Intel</strong>® <strong>80200</strong> processor boundary scan logicwas designed to support.No workaround.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 17

Errata18. Store of less than a word length, corrupts data of a previous aborting storeProblem:If there is a store instruction that hits the cache but receives a data TLB abort, and the nextinstruction was another store with a different byte footprint within an aligned 32 bit word (seebelow), the cache data may be modified in some or all of the bytes that would have been written bythe store.The abort will be taken, but the aborted store may partially modify the cache data.This means that a user process may be able to modify up to three bytes of one word in a protectedmemory region before going to the abort handler.If the abort handler removes the cause of the abort and re-executes the aborting instruction withouta fault, the memory location will now be correct with the stored value.If the aborting store is not re-executed:If the aborting store was to a write-through region, only the cached copy of line will be updated.This modified data will never be evicted to external memory. If the abort handler invalidates thatcache line in the cache, memory will now be correct. Invalidating that line is safe because externalmemory has a coherent copy of that data at all times.If the memory region is not write-through, the cache line can be invalidated, but any other data inthat line that has been modified but not updated in external memory will be lost. There is no cleanway for the abort handler to recover the data that was modified by the aborting store.Footprint Cases:Aborting Instruction Next Instruction Resultstr strb, strh failstr str passstrh (efa(1) = 0) strb, strh (efa(1) = 1) failstrh (efa(1) = 0) str, strh (efa(1) = 0) passstrh (efa(1) = 1) strb, strh (efa(1) = 0) failstrh (efa(1) = 1) str, strh (efa(1) = 1) passstrbstrbstrb (different efa(1:0)),strh (different efa(1))str, strh (same efa(1),strb (same efa(1:0))failpassWorkaround:If data aborts are rare in the system and indicate broken user code to be fixed, you may not beaffected by the problem.If you are affected, one workaround is to use write-through memory, and in the data abort handlerfor any store, invalidate the data cache line at the address of the store.Status: Fixed. Fixed on A-1 stepping. See the Table “Summary Table of Changes” on page 7.18 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata19. Back to back I/O transactions are not synchronized as specifiedProblem:Loads or stores to memory with the page table attributes X=0, C=0, B=0 (I/O memory) should goout to the bus one at a time. Instruction execution should cease soon after the memory instruction isissued until any imprecise data aborts generated by the memory instruction are reported. Becauseseveral more instructions may execute after the memory instruction before the core stalls, theimprecise data aborts are not guaranteed to be precise (reported on the memory instructiongenerating the fault), but will be reported within three instructions of the instruction triggering theabort.On the <strong>Intel</strong>® <strong>80200</strong> processor, the above specification breaks for back to back memory requests toI/O memory. If two or more memory requests to I/O memory space are within three instructions ofeach other, the core will stall correctly for the first instruction only. Instruction execution willresume before the subsequent I/O transactions have completed.The execution of these instructions works correctly. The problem is that any imprecise data abortson the affected memory instructions may be reported much later than the three- instruction windowin the specification.Workaround:I/O memory transactions will correctly go on the <strong>Intel</strong>® <strong>80200</strong> processor bus one at a time (eachone finishing completely before any subsequent memory transactions are issued).If the customer is not using I/O memory to guarantee that imprecise data aborts (external bus abortsor ECC memory aborts) are reported on an instruction close to the issuing instruction, there is noproblem and the customer will not be affected by this errata.For customers that are using I/O memory to guarantee that imprecise data aborts are reported on aninstruction close to the issuing instruction. Follow these I/O memory requests with twoinstructions, that are not memory transactions to I/O memory.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.20. Drain is not flushed correctly when stalled in the pipelineProblem:Implication:Workaround:In a load followed by a drain scenario, the load table walks and then gets a precise data abort. The<strong>Intel</strong> <strong>80200</strong> processor fetches the address for the abort handler, but in the same cycle does not flushthe drain.Not a functional problem, but may effect performance.No workaround.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.21. Undefined data processing-'like' instructions are interpreted as an MSRinstructionProblem:Workaround:The instruction decoder allows undefined opcodes, which look similar to the MSR (Move to Statusregister from an ARM* register) instruction, to be interpreted as an MSR instruction. Themis-decoded MSR instruction also adds a SUBNV PC, 0x4 to the instruction flow.Do not use undefined opcodes of this form:31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0- - - - 0 0 0 1 0 - 1 0 - - - - - - - - - - - - 0 0 1 0 - - - -- - - - 0 0 0 1 0 - 1 0 - - - - - - - - - - - - 0 1 0 0 - - - -- - - - 0 0 0 1 0 - 1 0 - - - - - - - - - - - - 0 1 1 0 - - - -Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 19

Errata22. Debug unit synchronization with the TXRXCTRL registerProblem:Workaround:The RX bit in the TXRXCTRL (TX/RX Control) register comes from the JTAG clock domain tothe core clock domain, and several cycles are needed for the register in the core clock domain toupdate. During this time, a debugger which is running a fast JTAG clock, relative to the core clock,may read the bit before it updates in the register, thus reading the old value.The JTAG clock should be slower than the core clock.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.23. Synchronization Request is not asserted when the Data Cache Unit pipe isemptyProblem:Workaround:When the 'Drain Write Buffer' command is issued, the <strong>Intel</strong> <strong>80200</strong> <strong>Processor</strong> should drain anymemory transactions in its own pipe and issue a synchronization request on the external bus. If thedrain command is issued when there are no memory transactions in the <strong>Intel</strong> <strong>80200</strong> <strong>Processor</strong>, thecommand does nothing. The <strong>Intel</strong> <strong>80200</strong> <strong>Processor</strong> recognizes that it is drained and assumes noaction is necessary, therefore no synchronization requests are driven on the external bus.See items #1 and #2 below:1. When a store needs to be drained, perform a load back from that location and introduce adependency.Example: str r2,[r1] ; r1 = memory mapped register, etc.ldr r2,[r1]mov r2,r2 ; nop with dependencyThis stalls the core correctly, but has some performance hit over the drain solution.2. Do any I/O transaction (a memory request to a page with attributes X=C=B=0). The dummyI/O transaction stalls the core until the I/O transaction and all previous transactions havefinished.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.24. Data Cache parity evictionProblem:If a line is evicted from the data cache (most likely by replacement, but possibly by an explicit datacache clean line command), depending on the timing of data returning from the bus, the parity errormay not be reported. The corrupted data may be written to external memory without any abortbeing triggered.This is seen if the following is true:1. There is a parity error in the data cache.2. It is in the first two words of an eight word aligned cache line.3. It is to write back memory.4. The data is dirty (not updated in external memory yet).If there are no parity errors introduced into the array, no problem is seen.Workaround: No workaround.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.20 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata25. Dirty bits are not cleared on invalidate by address to Data Cache UnitProblem:In write back memory (c=b=1, x=0 or x=1), if there is dirty data in the data cache and an 'invalidatedata cache line' operation is performed on that cache line, then the dirty bits are not cleared in thecache array.At a later time, that modified data could be evicted from the cache to external memory. After aninvalidate by address of this line, that should never happen.Global cache invalidate is not affected by this.Workaround: Always do a 'clean D-cache line' to an address before doing a 'invalidate D-cache line'.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.26. Vector trap is lost in the presence of a stallProblem:Workaround:If a vector trap occurs at the same time as certain types of stalls on the core, it will cause the vectortrap to be lost.The specific types of stalls that cause this problem include:1. DTLB (Data Translation Look-aside Buffer) miss.2. Buffer not available for valid memory operations in D2.3. Fill buffer complete (last word written to the fill buffer from external memory).This problem applies to all vector traps (except reset).The following sequence describes how to recreate the problem:• The SWI vector has a vector trap set on it.• An external memory access occurs before the SWI executes.• The SWI occurs.• Before going to the SWI handler, a vector trap should occur.• The memory stalls, caused by a DTLB miss (due to the memory accesses), and causes thevector trap to be ignored by the processor.• The vector at address 0x8 executes and continues execution from there (in Supervisor mode).The behavior is the same as if there was no vector trap.No workaround.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.27. Extra circuitry is not JTAG boundary scan compliantProblem:Workaround:The IEEE 1149.1 (JTAG) specification states that “when the HIGHZ instruction is selected, allsystem logic outputs .... shall immediately be placed in an inactive drive state”. The JTAG unit onthe <strong>Intel</strong> <strong>80200</strong> processor creates an internal ‘float’ signal which is driven to the I/O pads. Thissignal is derived from the HIGHZ instruction; however, the HIGHZ instruction gets flopped by arising edge of TCK first before it’s able to ‘float’ the pads. This is in violation of the JTAGspecification, specifically the term “immediately”. It is possible for TCK to stop after the HIGHZinstruction is loaded and thus the pads may never ‘float’.Do not stop the JTAG clock (TCK).Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 21

Errata28. Incorrect decode of Unindexed Mode, using Addressing Mode 5, cancorrupt protected registersProblem:Workaround:The instruction decoder incorrectly decodes the valid combination of P=0, U=1 and W=0, whenusing unindexed mode in addressing mode 5 (load and store coprocessor). In this case, the LDC orSTC should produce consecutive address loads or stores, with no base update until the coprocessorsignals that it has received enough data. Instead, the instruction gets separated into an LDR/STRand a CP access.The LDR/STR gets decoded as a post-index address, updating the base register. Due to thedecoding as post-index, the ‘option’ bits, normally reserved for the coprocessor in unindexedmode, will become the 8 bit offset value used in the base register update calculation.The implication is that protected registers can be corrupted. This errata can cause the corruption ofFIQ registers, R13-R14, in user and system modes when the LDC instruction is executed usingunindexed addressing mode. It can also cause the corruption of FIQ registers, R8-R12, in any modewhen the LDC instruction is executed using unindexed addressing. The R13 register in debugmode may also be corrupted during an LDC in any mode. In the case of STC, only Rn is corrupted.Unexpected memory accesses can also occur. In the case of an LDC, any memory location may beaccessed, since the FIQ registers may be improperly used as the base register. In the case of anSTC, the memory word located at Rn+4 will be corrupted. This is the memory locationimmediately following the locations which should be modified by STC unindexed.Do not use unindexed addressing in addressing mode 5 - Load and Store Coprocessor.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.29. Load immediately following a DMM flush entry is also flushedProblem:Workaround:A load that immediately follows a data memory management (DMM) flush entry command, thatalso hits the data TLB, is also flushed. Therefore, the instruction immediately following the flush isalso flushed from the data TLB.All flush entry commands to the data TLB must be followed by 2 nops. The first ensures that theerrata is not encountered, and the second ensures that the speed path is not hit.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.30. Trace Buffer does not operate below 1.3 VProblem:Workaround:The trace buffer within the debug unit is not guaranteed to operate, due to voltage sensitivity, whenthe Vcc voltage supply is below 1.3 V.Make sure the voltage is above 1.3 V during debug.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.22 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata31. Thumb branch with the Branch Target Buffer enabled, can go to the wrongaddressProblem:Workaround:A mispredicted 'not taken' thumb branch, with the branch target buffer (BTB) enabled, can causeincorrect program flow.Conditions to cause the problem:1. BTB must be enabled2. Thumb mode3. Conditional branch at address XXXX X1FC4. The branch must be predicted as taken, but then is not taken.Branch flush occurs but execution continues from the wrong address, rather than just 'fallingthrough'.Don't run thumb code with the BTB enabled.Status: Fixed. Fixed on B-step. See the Table “Summary Table of Changes” on page 7.32. Back to back external aborts can cause a hangProblem:Workaround:The following causes a bus hang:1.

Errata34. Aborted Store that Hits the Data Cache May Mark Write-Back Data as DirtyProblem:Workaround:When there is an aborted store that hits clean data in the data cache (data in an aligned four wordrange that has not been modified from the core since it was last loaded in from memory or cleaned),the data in the array is not modified (the store is blocked), but the dirty bit is set.When the line is then aged out of the data cache or explicitly cleaned, the data in that four wordrange is evicted to external memory, even though it has never been changed. In normal operationthis is nothing more than an extra store on the bus that writes the same data to memory that isalready there.Here is the boundary condition where this might be visible:1. A cache line is loaded into the cache at address A.2. Another master externally modifies address A.3. A core store instruction attempts to modify A, hits the cache, aborts because of MMUpermissions, and is backed out of the cache. That line normally is not marked dirty, butbecause of this errata is marked as dirty.4. The cache line at A then ages out or is explicitly cleaned. The original data from location Awill be evicted to external memory, overwriting the data written by the external master.This only happens when software is allowing an external master to modify memory that is,write-back or write-allocate in the <strong>80200</strong> page tables, and depending on the fact that the data is not'dirty' in the <strong>80200</strong> cache, to preclude the cached version from overwriting the external memoryversion. When there are any semaphores or any other handshaking to prevent collisions on sharedmemory, this is not a problem.For this shared memory region, mark it as write-through memory in the <strong>80200</strong> page table. Thisprevents the data from ever being written out as dirty.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.35. Data Cache Unit Signals Incorrect Number of Misses or Memory Operationsto the Performance Monitoring UnitProblem:Workaround:Under certain conditions inside the Data Cache Unit pipeline, the DCU can allow an operation tomove from the D2 pipe stage to the D3 pipe stage without the deassertion of D2 stall. The operationthat does this is not properly signaled to the Performance Monitoring Unit and therefore the PMUcount of cache misses and memory operations can be lower than expected.No workaround.Status: Fixed. Fixed on C-step. See the Table “Summary Table of Changes” on page 7.24 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata36. Incorrect ECC Attribute Used on Instruction FetchProblem:Workaround:On rare occasions an instruction fetch uses the wrong ECC attribute. This only occurs when ainstruction fetch return from the external bus lines up with a invalidate of the BTB. BTBinvalidates are caused by PID changes, or MCR commands which invalidate the instruction cacheor BTB. When this occurs a new fetch may get the ECC attribute of the returning fetch instead ofthe requested line. This can cause one of two things to happen:1. A fetch, that should be checked for ECC errors, is not checked.2. A fetch, that should not be checked for ECC errors, generates an ECC prefetch abort in anon-ECC memory region. When this happens, the prefetch abort handler can usually safelyreturn to the aborting instruction. When however, the processor was already in abort mode asthis occurred, r14 is modified, and the link to the original process may be lost.This errata is rare because it requires the processor to be executing from an ECC protected region,a branch to a non-ECC region followed by a BTB invalidate all lined up appropriately with twoseparate instruction cache misses.Software workarounds include:1. Do not use ECC. This errata does not apply when all page table entries are marked asnon-ECC regions.2. Do not flush the BTB or change the PID while in abort mode until the link register and SPSRhas been saved. When an ECC prefetch abort is generated for a non-ECC region, simply retrythe offending instruction.3. Drain the fill buffers before causing a BTB invalidate. Make sure the drain command and theinvalidate have the same memory ECC attributes.Status: Fixed. Fixed on C-step. See the Table “Summary Table of Changes” on page 7.37. Performance Monitoring Unit May Miscount SWI/UNDEFsProblem:Workaround:In some cases, depending on data cache activity, the signal coming from the debug unit indicatingto the Performance Monitoring Unit that a software interrupt or an undefined opcode event hasoccurred may be ignored. This leads to fewer than the actual number of software interrupts orundefined opcodes executed being reported in the PMU count.No workaround.Status: Fixed. Fixed on C-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 25

Errata38. TLB Lookup in Special Debug State May Use Incorrect Page Attribute BitValues on Subsequent Code FetchesProblem:Workaround:In Special Debug State (SDS) the Instruction Translation Look-aside Buffer (ITLB) is supposed toact like it is disabled. But both the cacheability and P-bit are not effected by the SDS bit. Therefore,they could be incorrect upon entering SDS and stay incorrect on subsequent code fetches in SDS.The potentially incorrect values for the cacheability bit and the P-bit are always logical one, incases where logical zero was the appropriate value.Because only the instruction TLB fetches are affected, the incorrect cacheability bit is not likely tobe noticed outside of a minor performance change (i.e., code which should be non-cacheable maybe cached).In the <strong>80200</strong>, the P-bit is used for ECC protection. When the P-bit is incorrectly set and the buscontroller is configured for ECC protection, then non-ECC memory may be interpreted as ECCmemory on code fetches. When the bus controller attempts to ‘correct’ code due to a perceivedsingle-bit ECC error, code corruption results. When a multi-bit error is detected erroneously, thecore hangs because the resulting abort does not be taken in SDS. This scenario can only occur in an<strong>80200</strong> system with code located in both ECC and non-ECC protected memory.No workaround is available for the cacheability issue. When the system can be debuggedeffectively with ECC off, then ECC can be turned off globally in the BCU to prevent the P-bit codecorruption/hang problem.Status: Fixed. Fixed on C-step. See the Table “Summary Table of Changes” on page 7.26 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata39. CP15 Data Cache Unlock Command Can Cause Unlock in User Mode orwhen Flushed from the Pipe in Supervisor ModeProblem:Correct behavior for the “unlock data cache” command (mcr p15, 0, Rd, c9, c2, 1) issued in usermode, is to generate an invalid instruction exception and not affect the state of the cache. Instead,the exception is generated, but the cache is unlocked anyway. In this case, the illegal instructionevent is generated. When the OS does not attempt to recover from illegal instructions, this erratumshould not be an issue.Workaround:A secondary effect of this erratum is, that even in a privileged mode, when an instruction shouldexecute, the data cache unlock hardware activity can occur while the actual mcr instruction is stillin the execution pipeline. When an interrupt or some other event causes the instruction to beflushed from the pipe, the hardware activity may still occur. It is likely that the instruction executesshortly after returning from the handler, so unlocking the cache early probably would not be anissue, unless the event handler code makes an assumption about data cache locking.When user mode code is well controlled, the OS can detect that user code did the illegal operationand report the error for software debugging purposes. Then re-code the user application and tryagain.When code deliberately trying to crash the machine is a concern, here are possible ways to recoverif the cache is unlocked in user mode:1. When data cache locking is used with the knowledge of the OS to keep local copies of externaldata for performance, it is possible, but not graceful, for the OS to fix things. The OS woulddetect that the invalid instruction fault was caused by a coprocessor 15 operation, clean out thecache, and relock the data that was supposed to be locked. The offending user applicationshould be terminated.2. When data cache locking is used as part of the data cache as SRAM (allocated with theallocate data cache line operation, rather than loading in existing memory), it becomes difficultfor the machine to recover. When any of the SRAM locations are evicted, external memory ata random location could be corrupted. One solution is, to immediately turn off the data cacheat the beginning of the invalid instruction event handler, to avoid evictions in the cache. TheSRAM contents could then be copied to scratch memory, the cache cleaned and invalidated,and the SRAM reallocated and locked. At that point, the contents could be copied back in andoperation could continue.When early unlocking of the data cache in privileged modes is a concern, the following softwareworkarounds exist:1. Disable interrupts before unlocking the data cache, and ensure that no abort conditions existaround the unlock code. Imprecise external data aborts and parity errors are still potentialissues, when software attempts to recover from these situations.2. Do not make assumptions about data cache lock state in the event handlers. When the eventhandler code does not require access to locked data cache regions, the early unlock istransparent, as the unlock mcr is executed once the handler is finished.Status: Fixed. Fixed on C-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 27

Errata40. Store to cacheable memory, interrupted by an exception, may inadvertentlywrite to memoryProblem:In some cases, if a store to a cacheable region of memory occurs simultaneously with an exception,the store will not be properly cancelled and may update memory. This may occur even if the storedid not have permission to write to that memory region, and no data abort will be recorded at thetime memory is incorrectly modified. It is important that developers review this erratum and assessthe impact to their specific application to ensure that no potential exists for data corruption.This combination of events is required for the erratum to occur:1. A memory operation occurs that requires a cache line fill, which in turn causes a cache lineeviction. For example, a load or prefetch.2. A few cycles later, an exception event occurs. The following exception events will cause theerratum: interrupt, prefetch abort, instruction breakpoint, invalid opcode fault, and imprecisedata abort. A precise data abort may not cause the erratum.3. The instruction which is being flushed by the exception event is a store to write-back memory,and the store address coincides with the cache line that is being evicted to make room for thecache line fill.4. Returning data on the bus causes a data cache stall at a specific cycle.Result:The store writes to memory when it should not. If the store is to write-back memory, the cache lineis evicted and external memory is incorrectly updated as if that store had occurred. The exceptionreturn points to the store instruction.If the store is to write-through memory, the store instruction is properly flushed and externalmemory is not updated.Memory access permissions are not checked before the store updates the cache. This means thestore may change memory without permission and without taking an abort.If the store did a pre- or post-index update on its address, the register file correctly flushes theupdate. This means that if the store is executed on return from the exception, correct data will bestored into memory at the correct address.Example Manifestations:The following examples explain how the erratum may manifest itself. The examples are intendedto help developers assess the impact upon their applications. Note that this is not an exhaustive list,there may be other examples depending upon how specific application code is architected.a.) Copy on Write -In a multi-tasking OS, a process has read access to a shared memory region, but not write access.Upon a write, the data abort handler will create a physical copy of that region and allow writeaccess to that new region.In the failing case, the shared read-only region could be updated incorrectly and without a dataabort. Eventually, when the original process is returned to, a data abort will happen, but theproblem is that the memory has already been corrupted. Linux supports Copy on Write and ifactivated, could experience the erratum. Other OSes may also be affected.b.) Flags to memory shared with interrupt handler -28 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

ErrataIf there is a flag used to communicate between a process and the interrupt handler, and the store toset the flag is being set by the store that is interrupted, the interrupt handler may see the flag set, dothe required work, and clear the flag. Upon return to the interrupted process, the store instructionwould be executed and the flag set. The interrupted process would incorrectly assume that theinterrupt handler had not yet seen that flag and serviced it. This flag error could also occur betweentwo task switched processes.c.) Debug -Workaround:Instruction breakpoints and prefetch aborts on a store can cause the erratum. If a user is singlestepping through code, stops with an instruction breakpoint on a store, and then checks externalmemory for the pre-store value of the address the store is about to write to, the debugger may seethe post store value.The global workaround for the erratum would be to disable write-back cache within theapplication. This will ensure the erratum does not manifest itself. However, it is understood thatthis could be cumbersome in performance-sensitive applications. As an alternative, developersmay simply prevent the conditions from occurring simultaneously which would cause the erratumto be manifested. By preventing these conditions, one effectively has implemented a workaround.1. Disable write-back cache. This could apply to Linux-<strong>based</strong> applications due to the fact thatLinux utilizes copy-on-write.2. Enable write-back cache and insure the code does not allow the simultaneous occurrence ofthe conditions required to manifest the erratum.Here are some workaround options for the specific examples listed above:a.) Copy on Write -This section is concerned with permissions as applied to first Linux and then to an embeddedreal-time controller. In Linux, Copy on Write, is a memory allocation technique used to provide aperformance boost. The erratum can be avoided by setting the caching policy for a copy-on-writeread-protected page to write-through. There will be no memory access penalties because thememory is read-only. When a write occurs and a write-able copy is made, that memory cachepolicy should be set to write-back. Without this change, errors may occur.When concerned with a real-time controller, the purpose for using permissions usually is to detecta misbehaving pointer or for quickly detecting runaway code. This erratum only applies to themisbehaving pointer problem, which if missed on one misuse will most likely be found on the next,resulting in the software problem being found and fixed.b.) Flags to memory shared with interrupt handler -The impact of this problem will most likely only involve a handful of sensitive variables for anembedded controller. That is because most variables are used within a task. Only some variables,which need to be passed from one task to another task, will be affected. A classic example variablewould be a semaphore flag. These variables can be protected in one of three ways:1. Locate the variable in locked cache or non-evicting mini-cache. This is the ideal solution fortime critical variables such as those passed between an interrupt handler and a backgroundprocessing task. A non-evicting mini-cache region can be created by setting up a mini-cachememory region and then limiting all access to that region to a 2K aligned address range.Because accesses are not outside the cache boundary, an eviction does not occur and thememory behaves as if it were on-board RAM.2. Surround the write of these variables with interrupt disable/enable commands. This is oftenalready done because manipulation of these variables exists in 'critical code' regions where an<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 29

Erratainterrupt between any of the instructions in the critical code region may cause an errorcondition. Modifying a semaphore is a typical critical code example.3. Use the atomic instructions, SWP or SWPB. Therefore, limiting the manipulation of sensitivevariables to these instructions will avoid the erratum.c.) Debug / Breakpoints -Most debug handlers flush the cache when a break occurs, which reduces the potential for a cacheeviction and reduces the potential for a system to be affected by the erratum. So there are few timesthis erratum should be seen in a debug session, and misinterpreting an apparent bug may beavoided by knowing where this erratum might occur.Status: Fixed. Fixed on D-step. See the Table “Summary Table of Changes” on page 7.30 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata41. Data cache dirty bits may be corrupted if a line invalidate is followedimmediately by a storeProblem: The dirty bits in the data cache can be corrupted by an Invalidate Data Cache Line command toaddress “A” immediately followed by any store to address “B” where address “B” and address “A”are to the same cache set (bits 9:5 of the two addresses are the same).This can lead to clean or invalid data being marked dirty in the cache, or dirty data in the cachebeing marked clean. Possible outcomes:1. Invalid data being marked dirty can lead to unpredictable four word stores to an unpredictableaddress in memory.2. Valid, but clean write-back data, being marked dirty can lead to unnecessary evictions toexternal memory.3. Valid dirty data being marked clean can lead to data corruption. External memory will not beupdated upon cache line replacement.Workaround: Do not perform a store operation immediately following an Invalidate Data Cache Line command.Invalidate Data Cache Line is a supervisor mode instruction. Placing a NOP between these twooperations will avoid the erratum.Status: Fixed. Fixed on D-step. See the Table “Summary Table of Changes” on page 7.42. Data cache dirty bits may be corrupted if a bus error on a cache line fill isfollowed immediately by a storeProblem: This erratum is very similar to erratum #41. The problem is the same, but the root cause isdifferent. If certain types of bus errors occur, and a store to the cache occurs near the time when theerror is reported, the dirty bits in the array in the same set as the store may be corrupted. The buserrors that can cause this erratum are a multi-bit ECC error on a returning cache line fill orassertion of the external ABORT pin on a returning cache line fill.This can lead to clean or invalid data being marked dirty in the cache, or dirty data in the cachebeing marked clean. Possible outcomes:1. Invalid data being marked dirty can lead to unpredictable four word stores to an unpredictableaddress in memory.2. Valid, but clean write-back data, being marked dirty can lead to unnecessary evictions toexternal memory.3. Valid dirty write-back data being marked clean can lead to data corruption. External memorywill not be updated upon cache line replacement.Bus errors reported on any store, or on loads that are smaller than 32 bytes will not cause this bug.Workaround: Set up the page tables such that unimplemented regions of memory do not have valid page tableentries. A precise data abort will occur on accesses to those regions and no bus error will be seen.Any region of memory that has valid memory locations and unimplemented memory locationswithin one page should be marked non-cacheable to avoid cache line fills. This will preclude theerratum. An example of this might be a memory mapped register region.Any region of memory that may generate bus aborts that cannot be prevented by appropriate pagetable entries should be marked non-cacheable.If there is some reason that code must do a cache line fill that will have a chance of creating a busabort, then avoid store instructions in supervisor mode while potentially aborting cache line fillsare pending. The drain write buffer CP15 command issued right after the cache line fill can be usedto stall the core during these transactions.For any triggering abort that cannot be avoided by page table permissions or cacheability (such asmulti-bit ECC error on a cache line fill), there is no known workaround. Bus aborts should, ingeneral, be avoided during normal operation.Status: Fixed. Fixed on D-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 31

Errata43. Performance Monitor Unit event 0x1 can be incremented erroneously byunrelated eventsProblem:Event 0x1 in the performance monitor unit (PMU) can be used to count cycles in which theinstruction cache cannot deliver an instruction. The only cycles counted should be those due to aninstruction cache miss or an instruction TLB miss. The following unrelated events in the core, willalso cause the corresponding count to increment when event number 0x1 is being monitored:• Any architectural event (e.g. IRQ, data abort)• MSR instructions which alter the CPSR control bits• Some branch instructions, including indirect branches and those mispredicted by the BTB• CP15 MCR instructions to registers 7, 8, 9, or 10 which involve the instruction cache or theinstruction TLBEach of the preceding items may cause the performance monitoring count to increment severaltimes. The resulting performance monitoring count may be higher than expected, if the precedingitems occur, but should never be lower than expected.Workaround:There is no way to obtain the correct number of cycles stalled due to instruction cache misses andinstruction TLB misses. Extra counts, due to branch instructions mispredicted by the BTB, may beone component of the unwanted count that can be filtered out.The number of mispredicted branches also can be monitored using performance monitoring event0x6 during the same time period as event 0x1. The mispredicted branch number then can besubtracted from the instruction cache stall number generated by the performance monitor to get avalue closer to the correct one. This workaround only addresses counts contributed by branchesthat the BTB is able to predict.All the items in the preceding bulleted list still affect the count. Depending on the nature of thecode being monitored, this workaround may have limited value.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.44. In Special Debug State, back-to-back memory operations — where the firstinstruction aborts — may cause a hangProblem:If back-to-back memory operations occur in the Special Debug State (SDS, used by ICE andDebug vendors) and the first memory operation gets a precise data abort, the first memoryoperation is correctly cancelled and no abort occurs. Depending on the timing, however, the secondmemory operation may not work correctly. The data cache may internally cancel the secondoperation, but the register file may have scoreboarded registers for that second memory operation.The effect is that the core may hang (due to a permanently scoreboarded register) or that a storeoperation may be incorrectly cancelled.Workaround:In Special Debug State, any memory operation that may cause a precise data abort should befollowed by a write-buffer drain operation. This will preclude further memory operations frombeing in the pipe when the abort occurs. Load Multiple/Store Multiple that may cause precise dataaborts should not be used.Status: NoFix. Will not be fixed on D-step. See the Table “Summary Table of Changes” on page 7.32 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata45. Instruction Memory Management Unit address translation is turned off forthe first fetch after exiting Special Debug StateProblem:When the processor enters SDS (Special Debug State), the Instruction Memory Management Unitis disabled. This means that the instruction TLB is no longer accessed and physical-to-virtualaddress translation no longer occurs. The first code executed after exiting SDS mode should causean instruction TLB access and execute from the physical memory specified in the appropriate pagetable entry.In certain timing cases, this may not occur. The physical address of the code that executes next willbe the same as the virtual address, without regard to the page tables. This can cause the wrong codeto execute.Workaround:Depending on the nature of the special debug routines, one of the following code sequences may beused to avoid this issue. These routines occur just before the CPSR restore instruction used to exitSDS.• SDS code is cacheable (external or in mini-icache):.align 5mov r13, addr@ Invalidate I-cache line, causes stall until all inst fetches completemcr p15, 0, r13, c7, c5, 1CPSR restore• SDS code is non-cacheable (external or mini-icache):.align 5b next_cache_lineprevious_cache_line:CPSR restore.align 5next_cache_line:bprevious_cache_line• SDS code is either non-cacheable or cacheable (but cannot be located in mini-icache):This workaround assumes that code is in a region mapped 1-to-1. This ensures the data access doesnot actually get remapped to another region of memory which may be faster than the regioncontaining the debug handler. Note that the clean data cache line command used below is notnecessary if the location “addr” is not used to hold some state for the use of the debug handler.mov rx, addr @ use some addr that is within the dbg hdlr@ clean and invalidate D-cache line, make sure that addr is not in D-cachemcr p15, 0, rx, c7, c6, 1mcr p15, 0, rx, c7, c10, 1bnext_cache_line.align 5@ make sure we start fetching next cache line@ before loading from it.next_cache_line:ldr rx, [rx] @ load from addrmov rx, rx @ data dependency, waits for load to completeCPSR restoreStatus: Fixed. Fixed on D-step. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 33

Errata46. Data cache dirty bits may be corrupted if a store to cacheable memoryoccurs during a tag replacement for a different cache lineProblem:Workaround:The dirty bits in the data cache may become corrupted if a store to cacheable memory hits anoutstanding cache line fill and is presented to the cache during a tag replacement for a differentcache line. There is no reasonable way to avoid these events lining up in normal code. This erratumis caused by a circuit race condition, and may be sensitive to voltage, temperature, or noise.This can lead to clean or invalid data being marked dirty in the cache, or dirty data in the cachebeing marked clean. Possible outcomes include:• Invalid data being marked dirty can lead to unpredictable four-word stores to an unpredictableaddress in memory.• Valid, but clean write-back data being marked dirty can lead to unnecessary evictions toexternal memory.• Valid dirty data being marked clean can lead to data corruption. External memory will not beupdated upon cache line replacement.Example 1. Scenario of Data-Cache Dirty Bit Becoming Corrupted1. A store, of 0xaaaa to address 0x1000, hits write-back memory in the cache and marks it dirty.2. Clean and invalidate commands are issued to address 0x1000, correctly pushing the data out ofthe cache to memory.At this point a clean invalid copy of the 0xaaaa data exists in the cache.3. A store, of 0xbbbb to address 0x1000, is cleaned and invalidated and memory is updated correctly.4. The erratum occurs and the original, 0xaaaa copy of the data is incorrectly marked “dirty.” It isthen evicted, overwriting the 0xbbbb data in memory.In an application, this may appear to be general memory corruption. It also may seem that the secondstore did not occur correctly, when in fact the second store worked and old data overwrote it.The only software workaround is to disable write-back cache. For cacheable memory regions, onlyuse write-through mode. Write-through cacheable regions ignore the dirty bits and therefore are notaffected. This erratum is only on the B and C stepping of the <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong>.Status: Fixed. Fixed on D-step. See the Table “Summary Table of Changes” on page 7.47. Accesses to the CP15 ID register with opcode2 > 0b001 returnsunpredictable valuesProblem:The ARM Architecture Reference Manual (ARM DDI 0100E) states the following in chapter B-2,section 2.3:If an value corresponding to an unimplemented or reserved ID register isencountered, the System Control processor returns the value of the main ID register.ID registers other than the main ID register are defined so that when implemented, their valuecannot be equal to that of the main ID register. Software can therefore determine whetherthey exist by reading both the main ID register and the desired register and comparing theirvalues. If the two values are not equal, the desired register exists.The <strong>Intel</strong> ® XScale core does not implement any CP15 ID code registers other than the Main IDregister (opcode2 = 0b000) and the Cache Type register (opcode2 = 0b001). When any of theunimplemented registers are accessed by software (e.g., mrc p15, 0, r3, c15, c15, 2), the value ofthe Main ID register was to be returned. Instead, an unpredictable value is returned.Workaround:No workaround.Status: NoFix. See the Table “Summary Table of Changes” on page 7.34 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Errata48. Disabling and re-enabling the MMU can hang the core or cause it to executethe wrong codeProblem:Workaround:When the MMU is disabled via the CP15 control register (CP15, CR1, opcode_2 = 0, bit 0) afterbeing enabled, certain timing cases can cause the processor to hang. In addition to this, re-enablingthe MMU after disabling it can cause the processor to fetch and execute code from the wrongphysical address. To avoid these issues, the code sequence below must be used whenever disablingthe MMU or re-enabling it afterwards.The following code sequence can be used to disable and/or re-enable the MMU safely. Thealignment of the mcr instruction that disables or re-enables the MMU must be controlled carefully,so that it resides in the first word of an instruction cache line.@ The following code sequence takes r0 as a parameter. The value of r0 will be@ written to the CP15 control register to either enable or disable the MMU.mcr p15, 0, r0, c10, c4, 1 @ unlock I-TLBmcr p15, 0, r0, c8, c5, 0 @ invalidate I-TLBmrc p15, 0, r0, c2, c0, 0 @ CPWAITmov r0, r0sub pc, pc, #4b 1f @ branch to aligned code.align 51:mcr p15, 0, r0, c1, c0, 0 @ enable/disable MMU, cachesmrc p15, 0, r0, c2, c0, 0mov r0, r0sub pc, pc, #4@ CPWAITStatus: NoFix. See the Table “Summary Table of Changes” on page 7.49. Updating the JTAG parallel registers requires an extra TCK rising edgeProblem:Workaround:The IEEE 1149.1 spec states that the effects of updating all parallel JTAG registers should be seenon the falling edge of TCK in the Update-DR state. The <strong>Intel</strong> ® XScale core parallel JTAGregisters, incorrectly require an extra TCK rising edge to make the update visible. Therefore,operations like hold-reset, JTAG break, and vector traps require either an extra TCK cycle bygoing to Run-Test-Idle or by cycling through the state machine again in order to trigger theexpected hardware behavior.When the JTAG interface is polled continuously, this erratum has no effect. When not, an extraTCK cycle can be caused by going to Run-Test-Idle after writing a parallel JTAG register.Status: NoFix. See the Table “Summary Table of Changes” on page 7.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 35

Specification ChangesSpecification Changes1. Revised and moved to Specification Clarification 2.2. Drowsy Mode has been De-SpecifiedIssue: Drowsy mode is no longer a low power mode that is supported on the <strong>80200</strong> processor. Use idlemode or sleep mode instead. For drowsy mode references in the <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on<strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual, see documentation change #8. Writing a‘2’ to the PWRMODE register in CP14, register 7, is considered a ‘reserved’ mode and should notbe used.3. New ECC Disable Bit Available on the C-0 and D-0 StepIssue: When using the 80312 companion chip with the <strong>80200</strong> processor, both devices will generate ECCbits for sub-64 bit stores (writes) to SDRAM. Therefore, the <strong>80200</strong> does not need to performRead-Modify-Writes (RMWs) for sub-64 bit stores as this is handled by the 80312 and will impactperformance.A new bit has been defined for the <strong>80200</strong> C-0 and D-0, which disables the RMWs for sub-64 bitstores. Bit 31 in ECTST (register 8, CP13) is now defined as the Disable Write ECC (DWE) bit. IfDWE is written as a '1', even if ECC is enabled, then the <strong>80200</strong> will not perform the usual ECCactions when writing data. In other words, if DWE = '1' and a write is performed to ECC-protectedmemory, the Bus Controller Unit (BCU) will not perform a RMW. The value on the ECC bus(DCB[7:0] signals) in this case will be unpredictable but will be consistent with whatever is beingdriven on D[63:0]. For example, in the case of a non-cacheable DWORD write, D[31:0] is definedby the store instruction and D[63:32] is unpredictable. However, DCB[7:0] is still consistent withwhat is driven out on D[63:0].DWE resets to '0' and is write-only. Reads of DWE result in an unpredictable value. The actionsthat the <strong>80200</strong> perform when reading data are unaffected by the setting of DWE.When DWE is written, it must be done while ECC is disabled in the BCU (BCUCTL.3 = '0').Software should only change the value of DWE once, typically at initialization/reset time.Changing the value of DWE in other circumstances results in unpredictable behavior.The <strong>80200</strong> processor is still responsible for validating ECC on reads, and therefore is required tohave ECC enabled when being used with the 80312 I/O companion chip. This new bit eliminatesthe ECC redundancy on writes.4. 200MHz <strong>Processor</strong> AvailableIssue: On November 12, 2002, <strong>Intel</strong> announced a 200MHz version of the <strong>80200</strong> processor. This productis <strong>based</strong> on the D-0 stepping and is only guaranteed to operate at 200MHz with a voltage of 1.1v+/-5%.At a core frequency of 200MHz, the MCLK is restricted to 66MHz or less. CLK and MCLK areasynchronous clocks, but the internal core frequency must be at least 3x faster than MCLK (seesection 8.1 in the <strong>80200</strong> <strong>Processor</strong> Manual). For example, if the core clock is 200MHz, MCLK isrestricted to 66MHz or less. Therefore, the 80312 I/O companion chip cannot be used with the200MHz processor because it provides an MCLK of 100MHz.The <strong>80200</strong> processor can initialize and operate at 200MHz when CLK = 33MHz, PLLCFG = 1(initial clock multiplier of 6) and MCLK is < or = 66MHz.36 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Specification Changes5. Extended Temperature Products AvailableIssue:On November 12, 2002, <strong>Intel</strong> announced the <strong>80200</strong>T, an extended temperature version of the<strong>80200</strong> processor. The <strong>80200</strong>T is <strong>based</strong> on the D-0 stepping and is available at 733MHz, 600MHz,400MHz and 200MHz. It is functionally identical to the commercial temperature <strong>80200</strong> processorbut is tested to operate at an extended temperature range of -40C to +85C. The <strong>80200</strong> processormanual and datasheet should be used when designing with the <strong>80200</strong>T processor.To provide a reference point for <strong>80200</strong>T thermal considerations, the following simulation resultsare listed below.Here are the parameters used in the model:• Tjunction max = 110C• Tcase_ext max = 105C• Tambient max = 85C• Typical power for 733MHz processor = 1.2W• Board size = 5" x 6"• Board layers:— 4 layers = signal, power, ground, signal— 6 layers = signal, power, signal, signal, ground, signal— 8 layers = signal, ground, signal, power, ground, signal, power, signal• No heat sink.• Theta ja target is < 20.83 C/W.— Based on the following equation: Tjunction - Tambient / P (w)110c - 85c / 1.2w = 20.83Thermal Simulation ResultsTheta ja< 20.83 C/WHeat Dissipatedthrough PCBHeat Dissipatedthrough TopHeat Dissipatedthrough Sides4 layer,no airflow6 layer,no airflow8 layer,no airflow4 layer,50 lfm airflow6 layer,50 lfm airflow8 layer,50 lfm airflow21.01 1.11w, 92% 0.06W, 5% 0.03W, 3%19.31 1.12w, 93% 0.05w, 5% 0.03w, 2%18.01 1.13w, 94% 0.05w, 4% 0.02w, 2%20.19 1.07w, 89% 0.10w, 8% 0.04W, 3%18.61 1.08w, 90% 0.08w, 7% 0.03w, 3%17.41 1.10w, 91% 0.08W, 7% 0.03w, 2%This data shows that the most important factor in heat dissipation with the <strong>80200</strong> package is theboard design (i.e., the number of layers, the size, other components dumping heat into the board,and so on.). With this package, adding a heat sink may have some affect, but this was not includedin the model.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 37

Specification ChangesThe four layer, no airflow configuration shows a theta ja of 21.01, which is higher than the target of20.83. Even in this scenario the <strong>80200</strong> should be fine, <strong>based</strong> on the fluctuation of the power.Note:This information is given as a reference point only. Customers need to perform thorough thermalsimulations <strong>based</strong> on their specific application. The easiest method is to measure the casetemperature on top of the package to verify that Tcase is below the 105C limit.38 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Specification ClarificationsSpecification Clarifications1. TRST# UsageProblem:Here are three different options for TRST# on the <strong>Intel</strong> ® <strong>80200</strong> processor:1. Tie TRST# to ground, if the JTAG port is never be used.2. Tie TRST# to RESET#. TRST# doesn't need to be asserted every time RESET# is asserted,but TRST# does need to be asserted on power-up or else the TAP controller is in an unknownstate. The issue with this option is with an ICE connected to the JTAG port, it needs to be ableto control TRST# independently of RESET# or it looses debug functionality.3. Assert TRST# on power-up and when instructed by an external JTAG/debug controller. Thisgives full debug functionality. See the ‘Recommended JTAG Circuitry for Debug’ applicationnote located at: developer.intel.com/design/iio/applnots/273538.htm, or see your debugger'sdocumentation for special requirements.2. STRD and LDRD InstructionsProblem: STRD (store double-word) and LDRD (load double-word) are new instructions in the ARMArchitecture Specification, v5TE. These load and store instructions can be used to transfer twoadjacent words of memory to or from any of the register pairs.The instruction decoder on the <strong>Intel</strong> ® <strong>80200</strong> processorr divides the STRD instruction into two STRinstructions. This is because the internal (core) data width is 32 bits. When coalescing is turned 'off'(CP15, R1, bit 0 = 1), the core always emits two 32-bit transactions. When coalescing is turned 'on'(CP15, R1, bit 0 = 0), the write buffer may combine them into one 64-bit request.3. Write Coalescing with the <strong>Intel</strong> ® 80312 I/O Companion ChipProblem: The write coalescing feature in the <strong>Intel</strong> ® <strong>80200</strong> processor (<strong>80200</strong>) can be used with the <strong>Intel</strong> ®80312 I/O Companion Chip (80312) to deliver higher memory throughput on core writes to localmemory. Enabling write coalescing may also significantly increase overall applicationperformance. Write coalescing is globally enabled by CP15, CR1, opcode_2=1, bit 0 = 0, andindividually enabled by the MMU page table descriptors using the C, B and X bits.For write coalescing to local memory to work correctly, ECC must be enabled in the <strong>80200</strong> for allpage descriptors that have coalescing enabled. When ECC is enabled, the <strong>80200</strong> always generates64-bit memory writes due to the ECC mechanism for handling partial writes of less than 64-bits tomemory regions. For sub 64-bit writes, the <strong>80200</strong> always generates read-modify-write (RMW) bustransactions, in order to update ECC by merging in the byte lanes from main memory beforewriting the data back out.For steppings of the <strong>80200</strong> that have the Disable Write ECC feature (see Specification Change 3),write coalescing and the enabling of the DWE bit are mutually exclusive when used with the80312. Setting the DWE bit disables the RMW mechanism that allows coalesced writes tocomplete correctly. The disable write ECC feature (DWE bit) should not be used with writecoalescing enabled.With coalescing enabled, writes may occur out of program order to external memory. When theorder of the writes is important, then use fences, since anything that is coalesced can be transferredout of order (see section 3.2.2.6 in the <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual).<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 39

Documentation ChangesDocumentation Changes1. Section C.2.4.1, Table C-4Issue: Table should include A-1 stepping showing JTAG ID of 0x19263013.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.2. Example 6-3 on page 6-12 may not work properlyIssue:Workaround:The data cache code locking example has some side effects when using the PLD instruction toperform the cache fill operation. When the address generated by the PLD forces a table walk, thePLD instruction is silently ignored. This means that when a page boundary is crossed into a pagethat is not in the TLB, then the PLD never causes a fill and the cache line (and probably the entirepage) does not get locked. Using loads is the only way to guarantee a fill (and a page lock) occurs.A register rotation scheme should be used to provide the best performance in locking the cache.Replace Example 6-3 with the following example.; configured with C=1 and B=1; R0 is the number of 32-byte lines to lock into the data cache. In this; example 16 lines of data are locked into the cache.; MMU and data cache are enabled prior to this code..macroCPWAITMRC P15, 0, R0, C2, C0, 0MOV R0, R0SUB PC, PC, #4.endm.macroDRAINMCR P15, 0, R0, C7, C10, 4 ; drain pending loads and stores.endm.macroLOCKLINE, Rx, Ry; Write back the line if it's dirty in the cacheMCR P15, 0, \Rx, C7, C10, 1; Flush/Invalidate the line from the cacheMCR P15, 0, \Rx, C7, C6, 1; Load and lock 32 bytes of data located at [R1]; into the data cache. Post-increment the address; in R1 to the next cache line.LDR \Ry, [\Rx], #32.endm; LockLines(int cache_lines, void *start_address).global LockLinesLockLines:STMFDSP!, {R4-R6, LR}MOV R6, R0DRAINMOV R2, #0x1MCR P15, 0, R2, C9, C2, 0 ; Put the data cache in lock modeCPWAIT40 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Documentation ChangesLOOP1:LOCKLINE R1, R2SUBSR6, R6, #1; Decrement loop countBEQ DONELOCKLINE R1, R3SUBSR6, R6, #1; Decrement loop countBEQ DONELOCKLINE R1, R4SUBSR6, R6, #1; Decrement loop countBEQ DONELOCKLINE R1, R5SUBSR6, R6, #1; Decrement loop countBNE LOOP1; Turn off data cache lockingDONE:DRAINMOV R2, #0x0MCR P15, 0, R2, C9, C2, 0 ; Take the data cache out of lock mode.CPWAITLDMFDSP!, {R4-R6, PC}Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.3. Figure 13-12 on page 13-39 and Figure 13-13 on page 13-41 show incorrectsignal statesIssue:Both RESET# and TRST# are active low, so these signals, as shown in figures, change polarity.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.4. Section A.2 on page A-2 has incorrect textIssue:The third bullet under Instruction Cache, needs to be changed from 'Fill Buffer' to 'Fetch Buffer'.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.5. Section B.2.3.1 on page B-6 has incorrect textIssue:The last sentence in this section needs to be changed from 'Fill Buffer' to 'Fetch Buffer'.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.6. Table 7-3 on page 7-4 shows incorrect register accessIssue:The access column for CR9 needs to be changed from ‘Read/Write’ to ‘Read-unpredictable/Write’.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.7. Table 7-15 on page 7-13 shows incorrect register accessIssue:The access column for the Data Cache Lock register needs to be changed from ‘Read/Write’ to‘Read-unpredictable/Write’.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 41

Documentation Changes8. All References to Drowsy Mode should be Removed from the <strong>80200</strong>Developer’s ManualIssue: Drowsy Mode has been de-specified (See specification change #2).The following Drowsy Mode references in the <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manuall should be removed:• Figure 1-1 on page 1-2• Section 1.1.2.6 on page 1-4• Table 7-23 on page 7-19 (2 = ‘reserved’)• Table 7-24 on page 7-19• Introduction section of page 8-1• All sections and figures on pages 8-5 and 8-6.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.9. Table 11-6 on page 11-10 has a new bit function for ECTST.31Issue:Bit 31 in the ECTST register is no longer Reserved. ECTST.31 is now defined as Disable WriteECC (DWE). See specification change 3 for more details.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.10. Figure C-2 on page C-7 shows an incorrect stateIssue:The initial TRST# state does not belong in this state diagram. It should be shown instead as'TRST# = 0'. A correct version can be seen in Figure 14-2 of the <strong>Intel</strong> ® 80312 I/O Companion ChipDeveloper’s Manual.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual.11. Example code is incorrect on page 13-15Issue:The first instruction in the example code, at the bottom of page 13-15, should be changed from‘mcr’ to ‘mrc’ (loop: mrc p14, 0, r15, c14, c0, 0).Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual(273411).12. Example code is incorrect on page 13-45Issue: The third instruction in the loop routine should change ‘c8’ to ‘c9’ (mrc p14, 0, r0, c9, c0, 0).Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual(273411).13. Number of clocks is incorrect on page 8-2Problem: On page 8-2, the last sentence of the second paragraph, change ‘approximately one thousand CLKcycles’ to ‘approximately two thousand CLK cycles’.It should read as: “If there are no external bus transactions, this procedure takes approximately twothousand CLK cycles, the same time it takes to transition out of reset.”Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual(273411).42 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update

Documentation Changes14. Figure 10-12 on page 10-22 shows incorrect BE# valueProblem:The BE# value in Figure 10-12 is incorrect. Change from ‘0x00’ to ‘0xF0’ to indicate 4 bytes, asused in the example.Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual(273411).15. Example code is incorrect on page 7-17Problem: Example 7-1 on pg 7-17 reads:LDR R0, =0x3FFE ; bit 0 is clearIt should read:LDR R0, =0x0000 ; bit 0 is clearorMOV R0, #0x00 ; bit 0 is clearThis conflicts with the statement made at the bottom of table 7-20, "Setting any of bits 12:1 has anundefined effect."Affected Docs: <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Developer’s Manual(273411).<strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update 43

Documentation ChangesThis Page Intentionally Left Blank44 <strong>Intel</strong> ® <strong>80200</strong> <strong>Processor</strong> <strong>based</strong> on <strong>Intel</strong> ® XScale Microarchitecture Specification Update