TMS570LS0x32 Microcontroller
Silicon Revision A

Silicon Errata

Literature Number: SPNZ197F
March 2013 – Revised May 2016

Contents
12
3
4

Device Nomenclature............................................................................................................ 4
Revision Identification .......................................................................................................... 5
Known Design Exceptions to Functional Specifications .......................................................... 6
Revision History ................................................................................................................. 40

2

Table of Contents

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

List of Figures1

Device Revision Code Identification ....................................................................................... 5

List of Tables
1

Known Design Exceptions to Functional Specifications ............................................................... 6

2

Document Revision History ............................................................................................... 40

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

List of Figures
Copyright © 2013–2016, Texas Instruments Incorporated

3

Silicon Errata
SPNZ197F – March 2013 – Revised May 2016

TMS570LS0x32 Microcontroller

This document describes the known exceptions to the functional specifications for the device.

1

Device Nomenclature
To designate the stages in the product development cycle, TI assigns prefixes to the part numbers of alldevices. Each commercial family member has one of three prefixes: TMX, TMP, or TMS (for example,
TMS570LS3137). These prefixes represent evolutionary stages of product development from engineering
prototypes (TMX) through fully qualified production devices/tools (TMS).
Device development evolutionary flow:
TMX — Experimental device that is not necessarily representative of the final device's electrical
specifications.
TMP — Final silicon die that conforms to the device's electrical specifications but has not completedquality and reliability verification.
TMS — Fully-qualified production device.
TMX and TMP devices are shipped against the following disclaimer:"Developmental product is intended for internal evaluation purposes."
TMS devices have been characterized fully, and the quality and reliability of the device have been
demonstrated fully. TI's standard warranty applies.
Predictions show that prototype devices (TMX or TMP) have a greater failure rate than the standard
production devices. Texas Instruments recommends that these devices not be used in any production
system because their expected end-use failure rate still is undefined. Only qualified production devices areto be used.

4

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

Revision Identification

www.ti.com

2

Revision Identification
Figure 1 provides an example of the TMS570LSx device markings. The device revision can be determinedby the symbols marked on the top of the package.

TMS570LS
0432APZQQ1#######

Device Revision Code

Figure 1. Device Revision Code Identification

Silicon revision is identified by a device revision code. The code is of the format TMS570LS0432xPZQQ1,
where "x" denotes the silicon revision. If x is "A" in the device part number, it represents silicon revision A.
If the device uses the initial silicon version, no revision number is included.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

5Known Design Exceptions to Functional Specifications

3

www.ti.com

Known Design Exceptions to Functional Specifications
The following table lists the known exceptions to the functional specifications for the device.
Table 1. Known Design Exceptions to Functional Specifications

Title......................................................................................................................................

Page

CORTEX-R4#26 (ARM ID-577077) — Thumb STREXD Treated As NOP If Same Register Used For Both Source
Operands ........................................................................................................................ 8
CORTEX-R4#27 (ARM ID-412027) — Debug Reset Does Not Reset DBGDSCR When In Standby Mode ................ 9
CORTEX-R4#33 (ARM ID-452032) — Processor Can Deadlock When Debug Mode Enables Cleared ................... 10
CORTEX-R4#46 (ARM ID-599517) — CP15 Auxiliary ID And Prefetch Instruction Accesses Are UNDEFINED ......... 11
CORTEX-R4#58 (ARM ID-726554) — DBGDSCR.Adadiscard Is Wrong When DBGDSCR.Dbgack Set ................. 12
CORTEX-R4#61 (ARM ID-720270) — Latched DTR-Full Flags Not Updated Correctly On DTR Access. ................ 13
CORTEX-R4#66 (ARM ID-754269) — Register Corruption During a Load-Multiple Instruction at an Exception Vector . 14
CORTEX-R4#67 (ARM ID-758269) — Watchpoint On A Load Or Store Multiple May Be Missed. ......................... 15
DCC#24 — Single Shot Mode Count may be Incorrect ........................................................................... 16
DEVICE#037 — CPU Abort Not Generated on Write to Unimplemented MCRC Space ..................................... 17
DEVICE#038 — Read from E-fuse controller register generates abort ......................................................... 18
DEVICE#41 — Power-on Reset During Bank 7 Sector Erase May Corrupt Other Sectors .................................. 19
DEVICE#42 — Reads of Bank7 may be Corrupted by Short Glitches on nPORRST Pin .................................... 20
DEVICE#B066 — HCLK Stops Prematurely when Executing from Flash ...................................................... 21
FMC#79 — Abort on Unaligned Access at End of Bank .......................................................................... 22
GCM#59 — Oscillator can be disabled while PLL is running ..................................................................... 23
MCRC#18 — CPU Abort Generated on Write to Implemented CRC Space After Write to Unimplemented CRC Space 24
MIBSPI#110 — Multibuffered SPI in Slave Mode In 3- or 4-Pin Communication Transmits Data Incorrectly for SlowSPICLK Frequencies and for Clock Phase = 1 ........................................................................... 25
MIBSPI#111 — Data Length Error Is Generated Repeatedly In Slave Mode when I/O Loopback is Enabled ............ 26
MIBSPI#139 — Mibspi RX RAM RXEMPTY bit does not get cleared after reading ........................................... 27
NHET#54 — PCNT incorrect when low phase is less than one loop resolution ............................................... 28
NHET#55 — More than one PCNT instruction on the same pin results in measurement error ............................... 29
PBIST#4 — PBIST ROM Algorithm Doesn't Execute ............................................................................. 31
SSWF021#44 — Change to PLL Lock Time ........................................................................................ 32
SSWF021#45 — PLL Fails to Start .................................................................................................. 33
STC#26 — The value programmed into the Self Test Controller (STC) Self-Test Run Timeout Counter Preload
Register (STCTPR) is restored to its reset value at the end of each self test run. ................................... 34
STC#29 — Inadvertent Performance Monitoring Unit (PMU) interrupt request generated if a system reset [internal orexternal] occurs while a CPU Self-Test is executing. .................................................................... 35
STC#31 — Self Test Controller Returns a False Failure .......................................................................... 36
SYS#046 — Clock Source Switching Not Qualified With Clock Source Enable And Clock Source Valid .................. 37
SYS#102 — Bit field EFUSE_Abort[4:0] in SYSTASR register is read-clear instead of write-clear ......................... 38
VIM#27 — Unexpected phantom interrupt .......................................................................................... 39

6

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

Known Design Exceptions to Functional SpecificationsSPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

7

CORTEX-R4#26 (ARM ID-577077) — Thumb STREXD Treated As NOP If Same Register Used For Both Source Operands
www.ti.com

CORTEX-R4#26 (ARM ID-577077) Thumb STREXD Treated As NOP If Same Register Used For Both
Source Operands
Severity

3-Medium

Expected Behavior

The STREXD instruction should work in Thumb mode when Rt and Rt2 are the sameregister.

Issue

The ARM Architecture permits the Thumb STREXD instruction to be encoded with thesame register used for both transfer registers (Rt and Rt2). Because of this issue, theCortex-R4 processor treats such encoding as UNPREDICTABLE and executes it as a
NOP.

Condition

This error occurs when the processor is in Thumb state and a STREXD instruction is
executed with Rt = Rt2.
Note: this instruction is new in ARM Architecture version 7 (ARMv7). It is not present in
ARMv6T2 or other earlier architecture versions.

Implication(s)If this error occurs, the destination register, Rd, which indicates the status of the
instruction, is not updated and no memory transaction takes place. If the software is
attempting to perform an exclusive read-modify-write sequence, then it might either
incorrectly complete without memory being written, or loop forever attempting tocomplete the sequence.

Workaround(s)This issue can be avoided by using two different registers for the data to be transferred
by a STREXD instruction. This may involve copying the data in the transfer register to asecond, different register for use by the STREXD.
Comment: TI Code Generation tool does not generate exclusive access load or store
instructions. On these Hercules devices there is no reason to use exclusive accessinstructions.

8

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

CORTEX-R4#27 (ARM ID-412027) — Debug Reset Does Not Reset DBGDSCR When In Standby Mode

CORTEX-R4#27 (ARM ID-412027) Debug Reset Does Not Reset DBGDSCR When In Standby Mode
Severity

3-Medium

Expected Behavior

The debug reset input, PRESETDBGn, resets the processor's debug registers as
specified in the ARMv7R Architecture. The debug reset is commonly used to set the
debug registers to a known state when a debugger is attached to the target processor.

Issue

When the processor is in Standby Mode and the clock has been gated off,
PRESETDBGn fails to reset the Debug Status and Control Register (DBGDSCR).

Condition

1. The DBGDSCR register has been written so that its contents differ from the reset
values (most fields in this register reset to zero, though a few are UNKNOWN at
reset), and
2. The processor is in Standby Mode, and the clocks have been gated off, that is
STANDBYWFI is asserted, and3. The debug reset, PRESETDBGn, is asserted and de-asserted while the processor
clocks remain gated off.
Note: the debug reset is commonly used to set the debug registers to a known state
when a debugger is attached to the target processor.
Implication(s)This issue affects scan based debug utility developers. The end user should not beaffected by this issue if the development tool vendor has implemented the workaround.
If this issue occurs, then after the reset, the DBGDSCR register contains the values thatit had before reset rather than the reset values. If the debugger relies on the reset
values, then it may cause erroneous debug of the processor. For example, the
DBGDSCR contains the ExtDCCmode field which controls the Data Communications
Channel (DCC) access mode. If this field was previously set to Fast mode but the
debugger assumes that it is in Non-blocking mode (the reset value) then debugger
accesses to the DCC will cause the processor to execute instructions which were notexpected.

Workaround(s)This can be avoided by a workaround in the debug control software. Whenever the
debugger (or other software) generates a debug reset, follow this with a write of zero to
the DBGDSCR which forces all the fields to their reset values.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

9

CORTEX-R4#33 (ARM ID-452032) — Processor Can Deadlock When Debug Mode Enables Cleared

www.ti.com

CORTEX-R4#33 (ARM ID-452032) Processor Can Deadlock When Debug Mode Enables Cleared
Severity

3-Medium

Expected Behavior

The Cortex-R4 processor supports two different debugging modes: Halt-mode andMonitor-mode. Both modes can be disabled. Bits [15:14] in the Debug Status andControl Register (DBGDSCR) control which, if any, mode is enabled. Additionally, debug
events can only occur if the invasive debug enable pin, DBGEN is asserted. Deadlocks
should not occur when the debug mode is changed.

Issue

If there are active breakpoints or watchpoints at the time when the debugging modes are
disabled via the DBGDSCR or DBGEN, this issue can cause the processor to deadlock(in the case of a breakpoint) or lose data (in the case of a watchpoint).

Condition

1. DBGEN is asserted and the processor is running, and
2. At least one breakpoint or watchpoint is programmed and active, and3. Either halt-mode debugging or monitor mode debugging is enabled, and4. Either an instruction is fetched which matches a breakpoint, or an item of data isaccessed which matches a watchpoint, and5. After the instruction or data is accessed, but before the instruction completes
execution, either the DBGEN input is de-asserted or both halt-mode and monitormode debugging are disabled by means of a write the DBGDSCR.
Implication(s)This issue affects scan based debug utility developers. The end user should not beaffected by this issue if the development tool vendor has implemented the workaround.
Depending on which of the conditions are met, the processor will either lose data or
deadlock. If the processor deadlocks because of this issue it will still respond tointerrupts provided they are not masked.

Workaround(s)10This issue can be avoided by ensuring that all watchpoints and breakpoints are madeinactive before either de-asserting DBGEN or changing the debug mode enables.

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

CORTEX-R4#46 (ARM ID-599517) — CP15 Auxiliary ID And Prefetch Instruction Accesses Are UNDEFINEDCORTEX-R4#46 (ARM ID-599517) CP15 Auxiliary ID And Prefetch Instruction Accesses Are
UNDEFINED
Severity

3-Medium

Expected Behavior

The ARMv7-R architecture requires implementation of the following two features in
CP15:
1. An Auxiliary ID Register (AIDR), which can be read in privileged modes, and thecontents and format of which are IMPLEMENTATION DEFINED.
2. The operation to prefetch an instruction by MVA, as defined in the ARMv6
architecture, to be executed as a NOP.
Because of this issue, both of these CP15 accesses generate an UNDEFINED exception
on Cortex-R4.

Issue

CP15 accesses to Auxiliary ID Register (AIDR) or an operation to prefetch an instruction
by MVA will generate an UNDEFINED exception on Cortex-R4.

Condition

Either of the following instructions is executed in a privileged mode:• MRC p15,1,<Rt>,c0,c0,7 ; Read IMPLEMENTATION DEFINED Auxiliary ID Register• MCR p15,0,<Rt>,c7,c13,1 ; NOP, was Prefetch instruction by MVA in ARMv6

Implication(s)This issue should only affect portable code supposed to run on different ARM
architecture or code running on cached Cortex-R4. Code written for Hercules products
should not be affected.

Workaround(s)The CP15 AIDR and MVA registers are not implemented on Cortex-R4 CPU. To avoid
this issue, don't read or write to them.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

11

CORTEX-R4#58 (ARM ID-726554) — DBGDSCR.Adadiscard Is Wrong When DBGDSCR.Dbgack Set

www.ti.com

CORTEX-R4#58 (ARM ID-726554) DBGDSCR.Adadiscard Is Wrong When DBGDSCR.Dbgack Set
Severity

3-Medium

Expected Behavior

When the DBGDSCR.ADAdiscard bit is set, asynchronous data aborts are discarded,
except for setting the DBGDSCR.ADAbort sticky flag. The Cortex-R4 processor ensuresthat all possible outstanding asynchronous data aborts have been recognized before it
enters debug halt state. The flag is immediately on entry to debug halt state to indicatethat the debugger does not need to take any further action to determine whether all
possible outstanding asynchronous aborts have been recognized.

Issue

Because of this issue, the Cortex-R4 processor also sets the DBGDSCR.ADAdiscard bit
when the DBGDSCR.DBGack bit is set. This can cause the DBGDSCR.ADAbort bit tobecome set when the processor is not in debug halt state, and it is not cleared when theprocessor enters debug halt state. However, the processor does not discard the abort. Itis pending or generates an exception as normal.

Condition

1. The processor is not in debug halt state
2. The DBGDSCR.DBGack bit is set
3. An asynchronous data abort (for example, SLVERR response to a store to Normaltype memory) is recognized
NOTE:

Implication(s)it is not expected that DBGDSCR.DBGack will be set in any Cortex-R4
systemHercules users will not be impacted by this issue, because Code Composer Studio takes
care of this condition.
If this issue occurs, and the processor subsequently enters debug halt state, the
DBGDSCR.ADAbort bit will be set, when in fact no asynchronous data abort has
occurred in debug state. Before exiting debug state, the debugger will check this bit andwill typically treat it as an error. If no other asynchronous data abort has occurred indebug state, this is a false error.

Workaround(s)

12

None.

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

CORTEX-R4#61 (ARM ID-720270) — Latched DTR-Full Flags Not Updated Correctly On DTR Access.

CORTEX-R4#61 (ARM ID-720270) Latched DTR-Full Flags Not Updated Correctly On DTR Access.
Severity

3-Medium

Expected Behavior

When the debug Data Transfer Register (DTR) is in non-blocking mode, the latched
DTR-full flags (RXfull_l and TXfull_l) record the state of the DTR registers as observedby the debugger and control the flow of data to and from the debugger to prevent race
hazards. For example, when the target reads data from DBGDTRRXint, the associatedflag RXfull is cleared to indicate that the register has been drained, but the latched value
Rxfull_l remains set. Subsequent debugger writes to DBGDTRRXext are ignored
because RXfull_l is set. RXfull_l is updated from RXfull when the debugger reads
DBGDSCRext such that a debugger write to DBGDTRRXext will only succeed after the
debugger has observed that the register is empty. The ARMv7 debug architecture
requires that RXfull_l be updated when the debugger reads DBGDSCRext and when it
writes DBGDTRRXext. Similarly, TXfull_l must be updated when the debugger reads
DBGDSCRext and when it reads DBGDTRTXext.

Issue

Because of this issue, RXfull_l and TXfull_l are only updated when the debugger reads
DBGDSCRext.

Condition

The DTR is in non-blocking mode, that is, DBGDSCR.ExtDCCmode is set to 0b00 and
EITHER:
1. The debugger reads DBGDSCRext which shows that RXfull is zero, that is,
DBGDTRRX is empty, and then
2. The debugger writes data to DBGDTRRXext, and
3. Without first reading the DBGDSCRext, and before the processor has read fromDBGDTRRXint, the debugger performs another write to DBGDTRRXext.
OR
1. The debugger reads DBGDSCRext which shows that TXfull is one, that is,
DBGDTRTX is full, and then
2. The debugger reads data from DBGDTRTXext, and then
3. The processor writes new data into DBGDTRTXint, and
4. Without first reading the DBGDSCRext, the debugger performs another read fromDBGDTRTXext.

Implication(s)The ARMv7 debug architecture requires the debugger to read the DBGDSCRext before
attempting to transfer data via the DTR when in non-blocking mode. This issue only has
implications for debuggers that violate this requirement. If the issue occurs via datatransfer, data loss may occur. The architecture requires that data transfer never occur.
Texas Instruments has verified that TI's Code Composer Studios IDE is not affected bythis issue.

Workaround(s)None.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

13

CORTEX-R4#66 (ARM ID-754269) — Register Corruption During a Load-Multiple Instruction at an Exception Vector
www.ti.com

CORTEX-R4#66 (ARM ID-754269) Register Corruption During a Load-Multiple Instruction at an
Exception Vector
Severity

3-Medium

Expected Behavior

LDM will execute properly when used as the first instruction of an exception routine.

Issue

Under certain circumstances, a load multiple instruction can cause corruption of ageneral purpose register.

Condition

All the following conditions are required for this issue to occur:
1. A UDIV or SDIV instruction is executed with out-of-order completion of divides
enabled2. A multi-cycle instruction is partially executed before being interrupted by either an
IRQ, FIQ or imprecise abort. In this case, a multi-cycle instruction can be any of thefollowing:• LDM/STM that transfers 3 or more registers• LDM/STM that transfers 2 registers to an unaligned address without write back
• LDM/STM that transfers 2 registers to an aligned address with write back
• TBB/TBH
3. A load multiple instruction is executed as the first instruction of the exception handler
4. The load multiple instruction itself is interrupted either by an IRQ, FIQ, imprecise
abort or external debug halt request.
This issue is very timing sensitive and requires the UDIV or SDIV to complete when theload multiple is in the Issue stage of the CPU pipeline. The register that is corrupted is
not necessarily related to the load-multiple instruction and will depend on the state in the
CPU store pipeline when the UDIV or SDIV completes.

Implication(s)For practical systems, it is not expected that an interruptible LDM will be executed as thefirst instruction of an exception handler, because the handler is usually required to savethe registers of the interrupted context. Therefore, it is not expected that this issue has
any implications for practical systems. If the situation of the issue occurs it will result in
the corruption of the register bank state and could cause a fatal failure if the corrupted
register is subsequently read before being written.

Workaround(s)To work around this issue, set bit [7] of the Auxiliary Control Register to disable out-oforder completion for divide instructions. Code performance may be reduced depending
on how often divide operations are used.

14

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

CORTEX-R4#67 (ARM ID-758269) — Watchpoint On A Load Or Store Multiple May Be Missed.

CORTEX-R4#67 (ARM ID-758269) Watchpoint On A Load Or Store Multiple May Be Missed.
Severity

3-Medium

Expected Behavior

The Cortex-R4 supports synchronous watchpoints. This implies that for load and store
multiples, a watchpoint on any memory access will generate a debug event on the
instruction itself.

Issue

Due to this issue, certain watchpoint hits on multiples will not generate a debug event.

Condition

All the following conditions are required for this issue to occur:
1. A load or store multiple instruction is executed with at least 5 registers in the register
list.
2. The address range accessed corresponds to Strongly-Ordered or Device memory.
3. A watchpoint match is generated for an access that does not correspond to either the
first two or the last two registers in the list.
Under these conditions the processor will lose the watchpoint. Note that for a "store
multiple" instruction, the conditions are also affected by pipeline state making themtiming sensitive.

Implication(s)Due to this issue, a debugger may not be able to correctly watch accesses made to
Device or Strongly-ordered memory. The ARM architecture recommends thatwatchpoints should not be set on individual Device or Strongly-ordered addresses thatcan be accessed as part of a load or store multiple. Instead, it recommends the use of
the address range masking functionality provided to set watchpoints on an entire region,
ensuring that the watchpoint event will be seen on the first access of a load or store
multiple to this region.
If this recommendation is followed, this issue will not occur.

Workaround(s)None.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

15

DCC#24 — Single Shot Mode Count may be Incorrect

www.ti.com

DCC#24Single Shot Mode Count may be Incorrect

Severity

3-Medium

Expected Behavior

When the first clock source counts down to zero, the countdown value remaining for theother clock source is accurately captured.

Issue

The first issue is that there is an offset in starting and stopping the two counters due tosynchronization with VCLK that leads to a fixed offset. The second issue is that the value
remaining in the counter that did not reach zero may be latched while the bits are intransition, giving an erroneous value.

Condition

When used in single shot mode and the count value captured is not from VCLK.

Implication(s)The cycle count captured may be incorrect.

Workaround(s)Static frequency offset can be removed by making two measurements and subtracting.
The sporadic offset can be removed by making multiple measurements and discarding
outliers -- an odd filtering algorithm.

16

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

DEVICE#037 — CPU Abort Not Generated on Write to Unimplemented MCRC Space

www.ti.com

DEVICE#037

CPU Abort Not Generated on Write to Unimplemented MCRC Space

Severity

4-Low

Expected Behavior

A write to the illegal address region of the MCRC module will generate an abort

Issue

A CPU Abort does not get generated per the following condition:

Condition

When a normal mode write to an illegal address region of MCRC register space isfollowed by a debug mode access.

Implication(s)When debugging, either a breakpoint on the instruction after the illegal write, or single
stepping through the illegal write will not generate an abort.

Workaround(s)None

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

17

DEVICE#038 — Read from E-fuse controller register generates abort

www.ti.com

DEVICE#038

Read from E-fuse controller register generates abort

Severity

2-HighExpected Behavior

When the peripheral frame for the e-fuse controller is configured as "device" memory,the e-fuse control registers should be able to be read and written in any sequence
without generating an abort.

Issue

When the peripheral frame for the e-fuse controller is configured as "device" memory
and there are three or more writes to e-fuse control registers followed by a read from ane-fuse control register, a data abort is generated.

Condition

This issue occurs when the peripheral frame for the e-fuse controller is configured as"device" memory and there are three or more writes to the e-fuse control registers
followed by a read.

Implication(s)The user will have to insure there are no more than 2 consecutive writes to the e-fusecontrol registers without a read separating them.

Workaround(s)To avoid this issue, the user can insert a dummy e-fuse control register read after every
two writes to the e-fuse control registers.

18

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

DEVICE#41 — Power-on Reset During Bank 7 Sector Erase May Corrupt Other Sectors

DEVICE#41

Power-on Reset During Bank 7 Sector Erase May Corrupt Other Sectors

Severity

3-Medium

Expected Behavior

A power-on reset (nPORRST) during sector erase will leave that sector in an unknown
state, however it should not affect sectors other than the one being erased.

Issue

A power-on reset while doing a sector erase may corrupt other sectors. Typically sector
zero is corrupted when trying to erase one of the other sectors.

Condition

Doing sector erase of bank 7 only

Implication(s)Data in the other sector will be partially erased. This will likely result in ECC errors whentrying to read data from that sector.

Workaround(s)Before starting the sector erase, select bank 7 by writing 0x7 to FMAC (0xFFF87050)
then write to the bank 7 FSM_Sector register (0xFFF872A4) only enabling the sector
desired to be erased.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

19

DEVICE#42 — Reads of Bank7 may be Corrupted by Short Glitches on nPORRST Pin

www.ti.com

DEVICE#42

Reads of Bank7 may be Corrupted by Short Glitches on nPORRST Pin

Severity

3-Medium

Expected Behavior

Glitches on nPORRST less than 475ns in length are ignored by the device

Issue

Glitches on nPORRST may reset bank 7 of the flash without causing a CPU reset

Condition

Low going voltage glitch on the nPORRST pin

Implication(s)The CPU will read bad data from flash bank 7 if the read happens during the glitch. This
will most likely cause an ECC error, but an ECC error is not guaranteed.

Workaround(s)Good layout practices keeping the nPORRST trace protected from induced noise will
prevent occurrence of this problem.

20

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

DEVICE#B066 — HCLK Stops Prematurely when Executing from Flashwww.ti.com

DEVICE#B066

HCLK Stops Prematurely when Executing from Flash

Severity

3-Medium

Expected Behavior

To reduce power consumption, the CPU may request that the memory clock, HCLK, isdisabled by setting bit 1 of the Clock Domain Disable Register (CDDIS.1). After the CPU
makes this request, the flash bank is expected to monitor CPU activity and delay theactual disable of HCLK until the flash bank's Active Grace Period (BAGP) has expired(meaning that the CPU has stopped requesting instructions and data from the flash bankfor some number of clock cycles).

Issue

The flash bank fails to delay the disable of HCLK. Therefore the CPU may freeze before
it executes the WFI instruction.

Condition

The code requests to disable HCLK by setting bit 1 of the Clock Domain Disable register(CDDIS.1).

Implication(s)If HCLK is disabled, and the CPU stops before executing the "WFI" instruction, the CPU
will not resume execution on a wakeup interrupt.

Workaround(s)A WFI instruction should immediately follow the instruction that sets bit 1 of the Clock
Domain Disable Register.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

21

FMC#79 — Abort on Unaligned Access at End of Bank

www.ti.com

FMC#79Abort on Unaligned Access at End of Bank

Severity

4-Low

Expected Behavior

Since packed code and data can be linked to unaligned boundaries, the CPU should be
able to read these locations in memory space independent of the flash bank boundaries.

Issue

The CPU will sometimes get an abort when making an unaligned access near thephysical end of the bank boundary (in the range from 0xnnnnFFF1 through0xnnnnFFFF). Examples of unaligned accesses capable of causing an abort:

Condition

This only occurs within the ATCM space. It only occurs when the flash is in single cycle
mode and operating above 20MHz speed.
- a 32 bit data read such as a LDR at an address not on a 4 byte boundary- a 16 bit data read such as a LDRH at an address not on a 2 byte boundary- fetching a 32-bit thumb2 instruction which is not aligned on a four byte boundary

Implication(s)An abort exception may be generated when accessing unaligned data or instructions inthis range

Workaround(s)Use an option to keep the compiler from generating unaligned data or instructions. For
the TI compiler use --unaligned_access=off. Also ensure that hand generated assembly
language routines do not create an unaligned access to these locations.
OR
Do not use single cycle mode (RWAIT=0) at frequencies above 20MHz.
OR
Reserve the last fifteen bytes of flash in each bank on the ATCM with either a dummy
structure that is not accessed, or with a structure that will not create an unaligned
access.

22

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

GCM#59 — Oscillator can be disabled while PLL is running

www.ti.com

GCM#59Oscillator can be disabled while PLL is running

Severity

4-Low

Expected Behavior

No clock source can be disabled if it is being used

Issue

The oscillator can be disabled if the PLL is the only thing using it as a clock source

Condition

The oscillator may be disabled if:
1. no clock domain relies upon the oscillator
2. no clock domain relies upon any PLL

Implication(s)This issue allows the oscillator to be disabled while used by the PLL. When the oscillator
disables, the PLL will slip. The system behaves exactly like it would in case of a PLL
slip. The response includes:
1. setting the RF SLIP flag (GBLSTAT.8)
2. switching Clock Source 1 from the PLL (if enabled). This autonomous switch preventsuse of the PLL until the fault is cleared.
3. the device generates an ESM error (if enabled)
4. Cause a reset if the Reset-On-Slip Failure bit is set in PLLCTRL1.
If the software now uses the PLL as a clock source, there will be a long delay (mS) for
the oscillator and the PLL to restart and provide a clock. Additionally, the SLIP flag(s)must be cleared in order for the PLL to propagate to the clock domains.
Normally this is not an issue as the software should not attempt to disable the oscillator
when it is being used by the PLL. Also, once the PLL is stable and used as a clock
source, the oscillator can no longer be disabled.

Workaround(s)Since the PLL is a secondary clock source dependent on the Oscillator input, the user
software should not disable the Oscillator while the PLL is enabled while neither of them
are sources for any of the clock domains.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

23

MCRC#18 — CPU Abort Generated on Write to Implemented CRC Space After Write to Unimplemented CRC Space
www.ti.com

MCRC#18

CPU Abort Generated on Write to Implemented CRC Space After Write to
Unimplemented CRC Space

Severity

4-Low

Expected Behavior

A write to the legal address region (0xFE00_0000 to 0xFE00_01FF) of the CRC module
should not generate an abort

Issue

An abort is generated on a write to a legal address region (0xFE000000-0xFE0001FF) of
the CRC register space.

Condition

When a normal mode write to an unimplemented address region (0xFE00_0200 to
0xFE00_FFFF) of the CRC register space is followed by a write to a legal address
region (0xFE00_0000 to 0xFE00_01FF) of the CRC register space.

Implication(s)A write to an unimplemented address region of the CRC register space generates a data
abort as expected. The next write to a legal address region of the CRC register space
generates an unexpected second data abort.

Workaround(s)

None.

24

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

MIBSPI#110 — Multibuffered SPI in Slave Mode In 3- or 4-Pin Communication Transmits Data Incorrectly for
Slow SPICLK Frequencies and for Clock Phase = 1

MIBSPI#110

Multibuffered SPI in Slave Mode In 3- or 4-Pin Communication Transmits Data
Incorrectly for Slow SPICLK Frequencies and for Clock Phase = 1

Severity

3-Medium

Expected Behavior

The SPI must be able to transmit and receive data correctly in slave mode as long as
the SPICLK is slower than the maximum frequency specified in the device datasheet.

Issue

The MibSPI module, when configured in multi-buffered slave mode with 3 functional pins
(CLK, SIMO, SOMI) or 4 functional pins (CLK, SIMO, SOMI, nENA), could transmit
incorrect data.

Condition

This issue can occur under the following condition:• Module is configured to be in multi-buffered mode, AND• Module is configured to be a slave in the SPI communication, AND• SPI communication is configured to be in 3-pin mode or 4-pin mode with nENA, AND• Clock phase for SPICLK is 1, AND• SPICLK frequency is VCLK frequency / 12 or slower

Implication(s)Under the above described condition, the slave MibSPI module can transmit incorrect
data.

Workaround(s)The issue can be avoided by setting the CSHOLD bit in the control field of the TX RAM.
The nCS is not used as a functional signal in this communication, hence setting the
CSHOLD bit does not cause any other effect on the SPI communication.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

25

MIBSPI#111 — Data Length Error Is Generated Repeatedly In Slave Mode when I/O Loopback is Enabled

www.ti.com

MIBSPI#111

Data Length Error Is Generated Repeatedly In Slave Mode when I/O Loopback is
EnabledSeverity

3-Medium

Expected Behavior

After a data length (DLEN) error is generated and the interrupt is serviced the SPI
should abort the ongoing transfer and stop.

Issue

When a DLEN error is created in Slave mode of the SPI using nSCS pins in IO
Loopback Test mode, the SPI module re-transmits the data with the DLEN error insteadof aborting the ongoing transfer and stopping.

Condition

This is only an issue for an IOLPBK mode Slave in Analog Loopback configuration,
when the intentional error generation feature is triggered using
CTRL_DLENERR(IOLPBKTSTCR.16).

Implication(s)The SPI will repeatedly transmit the data with the DLEN error when configured in theabove configuration.

Workaround(s)After the DLEN_ERR interrupt is detected in IOLPBK mode, disable the transfers by
clearing the SPIEN bit of SPIGCR1 register (bit 24) and then re-enable the transfers bysetting SPIEN.

26

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

MIBSPI#139 — Mibspi RX RAM RXEMPTY bit does not get cleared after reading

www.ti.com

MIBSPI#139

Mibspi RX RAM RXEMPTY bit does not get cleared after reading

Severity

3-Medium

Expected Behavior

The MibSPI RXEMPTY flag is auto-cleared after a CPU or DMA read.

Issue

Under a certain condition, the RXEMPTY flag is not auto-cleared after a CPU or DMA
read.

Condition

The TXFULL flag of the latest buffer that the sequencer read out of transmit RAM for thecurrently active transfer group is 0, AND
A higher priority transfer group interrupts the current transfer group and the sequencer
starts to read the first buffer of the new transfer group from the transmit RAM, AND
Simultaneously, the host (CPU/DMA) is reading out a receive RAM location that contains
valid received data from the previous transfers.

Implication(s)The fake RXEMPTY '1' suspends the next Mibspi transfer with BUFMODE 6 or 7.
With other BUFMODEs, a false "Receive data buffer overrun" will be reported for the
next Mibspi transfer.

Workaround(s)1. If at all possible, avoid transfer groups interrupting one another.
2. If dummy buffers are used in lower priority transfer group, select appropriate"BUFMODE" for them (like SKIP/DISABLED) unless there is a specific need to use the"SUSPEND" mode.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

27

NHET#54 — PCNT incorrect when low phase is less than one loop resolution

www.ti.com

NHET#54PCNT incorrect when low phase is less than one loop resolution

Severity

3-Medium

Expected Behavior

PCNT instruction can correctly capture a low going pulse width if the pulse width isgreater than two high resolution clocks

Issue

PCNT instruction may capture incorrect low resolution clock (control field) and highresolution clock value

Condition

When measuring from falling edge to rising edge and the low pulse width is less than
one low resolution clock width.

Implication(s)PCNT cannot be used for capturing the pulse width of a low pulse less than one low
resolution clock wide.

Workaround(s)Connect the input pulse to be measured on two nHET channels using the high resolution
share feature. Then use two WCAP instructions, one to measure the falling edge, thesecond to measure the rising edge. Use the CPU to calculate the time difference. In thisworkaround the period of the input signal must be two loop resolutions or longer.

28

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

NHET#55 — More than one PCNT instruction on the same pin results in measurement error

www.ti.com

NHET#55

More than one PCNT instruction on the same pin results in measurement error

Severity

3 - Medium

Expected Behavior

It should be possible to use more than one Period/Pulse Count (PCNT) instruction tomeasure a single pin, as long as only one of the PCNT instructions is configured for highresolution (hr_lr=HIGH). For example, consider the following code fragments.
Code Fragment 1 - Should Be OK, But Fails Due to This Issue
PC1
PC2

PCNT { hr_lr=HIGH, type=RISE2FALL, pin=2};
PCNT { hr_lr=LOW, type=FALL2FALL, pin=2};

Code Fragment 2 - Should Be OK, But Fails Due to This Issue
PC1
PC2

PCNT { hr_lr=LOW, type=RISE2FALL, pin=2};
PCNT { hr_lr=HIGH, type=FALL2FALL, pin=2};

Code fragments 1 and 2 should work properly because only one of the two PCNT
instructions are configured for hr_lr=HIGH, and there is one hi-res structure available.
Issue

There are two issues.
1. A measurement error is introduced into the result of the PCNT instruction with
hr_lr=HIGH. Normally this instruction would return a result to within ±½ highresolution clock periods of the actual result, due to quantization noise. Howeveranother PCNT instruction on the same pin causes an error of up to ±1 loop resolution
period. Note that this error is greater than the normal loop resolution period error of±½ loop resolution period; because the high-resolution bits also contribute to theerror in this case.
2. A measurement error is introduced into the result of the PCNT instruction with
hr_lr=LOW. The PCNT instruction with hr_lr=LOW should return a value with 0's in bit
positions 6:0 (the high-resolution portion of the measurement result). This is the casewhen both PCNT instructions are set for hr_lr=LOW (Code Fragment 3) but for CodeFragments 1 and 2 the loop resolution PCNT returns a non-zero in bit positions 6:0.

Conditions

This problem occurs when both conditions are true:
1. More than one PCNT selecting the same pin number is executed during the same
loop resolution period.
2. One of the PCNT instructions is configured for high resolution (hr_lr=HIGH).
Please also note that the N2HET assembler defaults to high resolution for PCNT if the
hr_lr field is not specified as part of the instruction. Therefore unless the instruction iscoded explicitly with 'hr_lr=LOW as an option, the assembler will create N2HET machinecode with hr_lr=HIGH.'

Implications

The impact is greatest when workaround option 1 cannot be applied due to the numberof timer pins required by the application. If Option 1 cannot be applied, then the PCNT
measurements on this pin are reduced to ±½ loop resolution period.

Workaround(s)Option 1 - Use the HR Share feature and make both measurements with hr_lr=HIGH.
First, set the appropriate HRSHARE bit in the HETHRSH register. In the following
example this means setting HETHRSH bit 1 - "HRSHARE3/2". This bit causes the input
of device pin 2 to drive the N2HET pin inputs 2 and 3. Then modify the N2HET code
sequence to use pin 3 for one of the PCNT instructions:
Code Fragment 1 Modified for HR SharePC1
PC2

PCNT { hr_lr=HIGH, type=RISE2FALL, pin=2};
PCNT { hr_lr=HIGH, type=FALL2FALL, pin=3};This option exceeds the original measurement resolution objective because both PCNT
measurements are made with high-resolution. The disadvantage of this workaround isthat it requires the high-resolution structure of pin 3, leaving pin 3 only useable as a
GPIO pin rather than as a timer pin.
SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

29

NHET#55 — More than one PCNT instruction on the same pin results in measurement error

www.ti.com

Option 2 - Use only loop resolution mode PCNT instructions (as in Code Fragment 3).
This will work properly while leaving pin 3 available for timing functions, but theresolution on both the period and duty cycle measurements are reduced to loop
resolution.
Code Fragment 3 - OK
PC1
PC2

30

PCNT { hr_lr=LOW, type=RISE2FALL, pin=2};
PCNT { hr_lr=LOW, type=FALL2FALL, pin=2};

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

PBIST#4 — PBIST ROM Algorithm Doesn't Executewww.ti.com

PBIST#4

PBIST ROM Algorithm Doesn't Execute

Severity

3-Medium

Expected Behavior

PBIST controller checks memories with the specified algorithm as documented in the
TRM

Issue

The possibility that the PBIST algorithms will not execute only occurs when PBIST is
initially run after power on reset. Once the PBIST controller starts working, it will continue
to work until the next power cycle.

Condition

The possibility that the PBIST algorithms will not download only occurs when PBIST is
initially executed after power on reset. Once the PBIST ROM starts working, it willcontinue to work until the next power cycle.

Implication(s)The PBIST test may return with a pass status, even though the algorithm was notproperly executed

Workaround(s)This condition does not occur often, but when it does occur the execution time is very
short. Successive attempts eventually succeed. One workaround is to measure theexecution time of the PBIST algorithm. Using a software loop with interrupts disabled issufficient. If the execution time is much shorter than the normal execution time and thestatus indicates PBIST passed, ignore the results and rerun the PBIST test. Normal
execution time is dependent on clock speeds and which memory and algorithms are
selected. The normal execution time can be derived from PBIST times given in thedatasheet, or as measured in initial code development.
TI recommends to use 120% of the normal time as a time out value and less than 80%of the normal execution time as an indication that the PBIST controller did not executeproperly.
A more sophisticated workaround is to use the errata_PBIST_4() function provided in
HALCoGen version 3.08.00 or later.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

31

SSWF021#44 — Change to PLL Lock Timewww.ti.com

SSWF021#44

Change to PLL Lock Time

Severity

4-Low

Expected Behavior

The time for the PLL to lock would be the same for all revisions of a part.

Issue

The PLL lock time has been increased on newer revision parts by 384 OSCIN cycles.

Condition

None

Implication(s)The PLL takes longer to lock. If the software has a timeout loop waiting for the PLL tolock, software developed on this revision of silicon may timeout on future revisions ofsilicon.

Workaround(s)If there is a timeout loop in the software waiting for the PLL to lock, the timeout value
should be large enough to allow for the greater lock time required in newer versions of
the silicon. The lock time increases:from 128 + 1024*NR OSCIN cycles
to 512 + 1024*NR OSCIN cycles
For typical PLL settings, the input divider is larger than 1 so that the percentage increasein lock time is small.

32

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

SSWF021#45 — PLL Fails to Start

www.ti.com

SSWF021#45

PLL Fails to Start

Severity

2-HighExpected Behavior

When the PLL control registers are properly initialized and the appropriate clock source
disable bit is cleared, after the prescribed number of OSCIN cycles, the PLL should belocked and the appropriate CSVSTAT bit should be set.

Issue

On rare occasions the PLL does not start properly. The fail has one of three signatures:
1. CSVSTAT is set, but the ESM flag for PLL slip is set.
2. CSVSTAT is not set and the ESM flag for PLL slip is set.
3. CSVSTAT is set, the ESM flag for PLL slip is not set, but the PLL as measured by
the DCC is not running.

Condition

This issue applies to both PLLs (if the device has more than one PLL). This condition
occurs only from a power-on. Once the PLL has locked, the PLL stays locked. Once
properly locked, the PLL can be disabled and re-enabled with no issues.

Implication(s)If the PLL is used as the main clock source when it has not properly started, the CPU
may stop executing instructions.

Workaround(s)While the main clock is being driven by the oscillator, the software loop checking that the
PLL has locked (CSVSTAT = 1 ) should also check if the ESM flag for PLL slip has been
set. When the CSVSTAT bit is set, the PLL frequency should be measured with the DCC
before using the PLL as a clock source. If either the ESM flag for PLL slip is set, or the
PLL has an incorrect frequency, the PLL should be disabled and the lock procedure
should be repeated; TI recommends allowing a minimum of five attempts.
A more detailed explanation of the workaround with associated source code can befound in the application note:
Hercules PLL Advisory SSWF021#45 Workaround

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

33

STC#26 — The value programmed into the Self Test Controller (STC) Self-Test Run Timeout Counter Preload Register(STCTPR) is restored to its reset value at the end of each self test run.
www.ti.com

STC#26The value programmed into the Self Test Controller (STC) Self-Test Run Timeout
Counter Preload Register (STCTPR) is restored to its reset value at the end ofeach self test run.

Severity

4-Low

Expected Behavior

Once the Self-Test Run Timeout Counter Preload Register (STCTPR) is written, thevalue written into the register will be maintained until it is overwritten or a system or
power on reset occurs and it will be used to preload the timeout counter for each self
test run.

Issue

The STCTPR is reset to the reset default value (0xFFFFFFFF) at the end of each CPU
self test run and the value previously written to the STCTPR register is lost.

Condition

Execution of any CPU self test with a STCTPR value other than the default value(0xFFFFFFFF).

Implication(s)Subsequent self test runs will use a maximum timeout value of 0xFFFFFFFF if not rewritten to the desired value.

Workaround(s)The Timeout preload value in STCTPR register needs to be programmed to the required
time out value before starting each self test if a timeout count other than 0xFFFFFFFF isdesired.

34

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

STC#29 — Inadvertent Performance Monitoring Unit (PMU) interrupt request generated if a system reset[internal or external] occurs while a CPU Self-Test is executing.

STC#29Inadvertent Performance Monitoring Unit (PMU) interrupt request generated if asystem reset [internal or external] occurs while a CPU Self-Test is executing.

Severity

4-Low

Expected Behavior

If an internal or external system reset is asserted the CPU should be reset cleanly withno inadvertent interrupt requests.

Issue

An unexpected PMU interrupt request may be generated.

Condition

This condition can occur when am internal or external system reset is asserted and the
CPU is executing a CPU self test.

Implication(s)The interrupt request signal from the performance monitoring unit (PMUIRQ) may
inadvertently be set. This signal will generate an interrupt to the Vector Interrupt Module(VIM) and later become an interrupt to the CPU. Therefore, it is possible to see an
unexpected interrupt after the CPU comes out of the system reset.

Workaround(s)Clear VIM interrupt request 22 by writing 0x00400000 to location 0xFFFFFE20 before
enabling this interrupt.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

35

STC#31 — Self Test Controller Returns a False Failure

www.ti.com

STC#31

Self Test Controller Returns a False Failure

Severity

3-Medium

Expected Behavior

The STC tests the logic of the CPUs then generates a CPU reset on completion.

Issue

The STC may indicate that the self test (LBIST) failed when the CPU logic is working
properly. The root cause is that the ROM in the STC is not read properly. This is thesame root cause as in erratum PBIST#4.

Condition

This only occurs after initial power on. This fail condition is believed to be very rare, but it
can be reproduce in simulations and has been seen in similar circuits. The fail mode isdependent on temperature, core voltage slew rate and currents into the device from
input pins before the device powers up. The impact of these factors is different on eachdevice.

Implication(s)The CPU self test appears to fail.

Workaround(s)Use the function "errata_PBIST_4()" provided in HALCoGen 3.08.00 or later before
running PBIST or LBIST. Then run the PBIST ROM tests on all ROMs before using the
STC controller to execute LBIST.

36

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

www.ti.com

SYS#046 — Clock Source Switching Not Qualified With Clock Source Enable And Clock Source Valid

SYS#046

Clock Source Switching Not Qualified With Clock Source Enable And ClockSource Valid

Severity

4-Low

Expected Behavior

An attempt to switch to a clock source which is not valid yet should be discarded.

Issue

Switching a clock source by simply writing to the GHVSRC bits of the GHVSRC registermay cause unexpected behavior. The clock will switch to a source even if the clock
source was not ready.

Condition

A clock domain that is programmed to take the clock source which is not yet valid as
indicated by the CSVSTAT register.

Implication(s)Unexpected behavior stated above.

Workaround(s)Always check the CSDIS register to make sure the clock source is turned on and check
the CSVSTAT register to make sure the clock source is valid. Then write to GHVSRC toswitch the clock.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated37

SYS#102 — Bit field EFUSE_Abort[4:0] in SYSTASR register is read-clear instead of write-clear

www.ti.com

SYS#102

Bit field EFUSE_Abort[4:0] in SYSTASR register is read-clear instead of write-clear

Severity

3-Medium

Expected Behavior

The Technical Reference Manual states that EFUSE_Abort[4:0] of the SYSTASR
register should be write-clear in privilege mode.

Issue

However, these bits are implemented as read-clear.

Condition

Always.

Implication(s)Software implementation for error handling needs to take care of this as the subsequent
reads of the register can return value of zero.

Workaround(s)Avoid multiple read accesses of the SYSTASR register.
None

38

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

VIM#27 — Unexpected phantom interrupt

www.ti.com

VIM#27

Unexpected phantom interrupt

Severity

2-HighExpected Behavior

When responding to an interrupt and a subsequent interrupt is received, thecorresponding VIM request should be flagged as pending in the VIM status registers.
When the CPU is ready to service the subsequent interrupt, the correct service routine
address should be fetched by the CPU.

Issue

On rare occasions the VIM may return the phantom interrupt vector instead of the realinterrupt vector.

Condition

This condition is specific to software and hardware vectored modes. This is notapplicable for legacy interrupt servicing mode. This condition occurs when the ratio of
GCLK to VCLK is 3:1 or greater for hardware vectored mode, or the ratio of GCLK toVCLK is 5:1 or greater for software vectored mode. A subsequent interrupt request mustoccur when the VIM is finishing acknowledging a previous interrupt.

Implication(s)The subsequent interrupt request vectors to the phantom interrupt routine instead of thecorrect service routine.

Workaround(s)The issue can be completely avoided if the GCLK:VCLK ratio is configured as 1:1 or 2:1.
For other VCLK ratios, the phantom interrupt handler simply needs to exit as normal,
without taking any special steps. If this issue is present, the VIM will interrupt the CPU
again, providing the correct vector.

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback

TMS570LS0x32 Microcontroller
Copyright © 2013–2016, Texas Instruments Incorporated

39

Revision History

4

www.ti.com

Revision History
This silicon errata revision history highlights the technical changes made from the previous revision of thisdocument to the current revision.
Table 2. Document Revision History
Advisory Changes in Advisory List

40

Advisory ID

Added advisory(s)SSWF021#45

Removed advisory(s)NoneModified advisory(s)

None

Other

None

TMS570LS0x32 Microcontroller

SPNZ197F – March 2013 – Revised May 2016
Submit Documentation Feedback
Copyright © 2013–2016, Texas Instruments Incorporated

IMPORTANT NOTICE AND DISCLAIMER
TI PROVIDES TECHNICAL AND RELIABILITY DATA (INCLUDING DATASHEETS), DESIGN RESOURCES (INCLUDING REFERENCEDESIGNS), APPLICATION OR OTHER DESIGN ADVICE, WEB TOOLS, SAFETY INFORMATION, AND OTHER RESOURCES “AS IS”
AND WITH ALL FAULTS, AND DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION ANYIMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF THIRDPARTY INTELLECTUAL PROPERTY RIGHTS.
These resources are intended for skilled developers designing with TI products. You are solely responsible for (1) selecting the appropriate
TI products for your application, (2) designing, validating and testing your application, and (3) ensuring your application meets applicablestandards, and any other safety, security, or other requirements. These resources are subject to change without notice. TI grants you
permission to use these resources only for development of an application that uses the TI products described in the resource. Other
reproduction and display of these resources is prohibited. No license is granted to any other TI intellectual property right or to any third
party intellectual property right. TI disclaims responsibility for, and you will fully indemnify TI and its representatives against, any claims,
damages, costs, losses, and liabilities arising out of your use of these resources.
TI’s products are provided subject to TI’s Terms of Sale (www.ti.com/legal/termsofsale.html) or other applicable terms available either onti.com or provided in conjunction with such TI products. TI’s provision of these resources does not expand or otherwise alter TI’s applicablewarranties or warranty disclaimers for TI products.
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2019, Texas Instruments Incorporated