OMAP5912 Applications Processor Silicon Errata ... - Curtin University
OMAP5912 Applications Processor Silicon Errata ... - Curtin University
OMAP5912 Applications Processor Silicon Errata ... - Curtin University
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>OMAP5912</strong><br />
<strong>Applications</strong> <strong>Processor</strong><br />
<strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
December 2003 − Revised September 2004<br />
Copyright © 2004, Texas Instruments Incorporated
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
REVISION HISTORY<br />
This revision history highlights the technical changes made to SPRZ209B to generate SPRZ209C.<br />
Scope: Added MMC_8 and DM_TIMER_1 advisories, etc.<br />
PAGE(S)<br />
NO.<br />
ADDITIONS/CHANGES/DELETIONS<br />
7 Section 1.1:<br />
− replaced “Quality and Reliability Conditions” section with “Device and Development-Support Tool Nomenclature” section<br />
32 Added MMC_8, SPI Mode on the MMC/SD Peripheral is Not Supported<br />
60 Added Section 6.19, Dual-Mode Timers Advisories<br />
60 Added DM_TIMER_1, Dual-Mode Timer Peripherals May Not Detect Incoming Events<br />
SPRZ209C<br />
2
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
Contents<br />
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.1 Device and Development-Support Tool Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.2 Revision Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
2 Important Notices and Information About <strong>OMAP5912</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1 Useful Information Regarding TMS320C55x Assembler Diagnostic Messages . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1.1 ERROR Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1.2 WARNING Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.1.3 REMARK Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3 DSP Subsystem Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.1 DSP ICACHE Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
DSP_ICACHE_1 ICACHE Update of TAG-RAM on Wrong Location When a Miss Occurs Between<br />
RAMSET Preload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.2 DSP Emulation Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
DSP_EMU_1 DSP IDLE Interrupt Not Serviced When an Emulator is Connected . . . . . . . . . . . . . . . . . . 13<br />
DSP_EMU_2 Emulation is Broken When the DSP is in Isolation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
3.3 DSP EMIF Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
DSP_EMIF_1 DSP EMIF/DMA Port Hangs During EMIF Bus Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.4 DSP System Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
DSP_SYS_1 Bus Error Issued on Byte Accesses to I/O Space, 0x0 Through 0x5f . . . . . . . . . . . . . . . . . 16<br />
DSP_SYS_2 Use Caution When Reading Following a Configuration Change . . . . . . . . . . . . . . . . . . . . . 16<br />
DSP_SYS_3 Page Table of DSPMMU Gets Corrupted in Synchronous Scalable Mode . . . . . . . . . . . . . 17<br />
DSP_SYS_4 Data Page Register and Stack Pointer Updates are not Pipeline-Protected Against<br />
Data Move Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
4 MPU Subsystem Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
4.1 System Direct Memory Access (DMA) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
SYS_DMA_1 Incorrect Value in DMA_PCHx_SR Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
4.2 MPU Emulation Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
MPU_EMU_1 Emulation Connection is Intrusive to ARM Idle Mode.<br />
<strong>OMAP5912</strong> Cannot Go Into Idle With Code Composer Studio Connected. . . . . . . . . . . . . 21<br />
4.3 MPU System Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
MPU_SYS_1 MPU IRQ122−127 Can Cause Spurious Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
MPU_SYS_2 Special Software Procedure is Needed to Acknowledge ARM LV1 Interrupt . . . . . . . . . . . 22<br />
4.4 MPU Watchdog Timer Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
MPU_WATCHDOG_1 MPU Watchdog Does Not Reset DPLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .<br />
24<br />
3
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
5 Traffic Controller Subsystem Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
5.1 EMIF Slow (EMIFS) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
EMIFS_1 Wrong Behavior on CS0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
EMIFS_2 Program Fetch Prevents Sleep Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
5.2 EMIF Fast (EMIFF) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
EMIFF_1 Dual Data Rate (DDR) SDRAM Interface Does Not Support Dual Data Rate Speeds . . . . . . . . . . 26<br />
EMIFF_2 SDRAM Interface MRS/EMRS Command Issued Twice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
EMIFF_3 Glitch in DPLL Clock During Reset Assertion Affects EMIFF State Machine . . . . . . . . . . . . . . . . . 27<br />
5.3 Traffic Controller Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
TC_1 <strong>OMAP5912</strong> Global Software Reset Affects Traffic Controller Frequency . . . . . . . . . . . . . . . . . . . . . 28<br />
6 <strong>OMAP5912</strong> Peripheral Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
6.1 Multimedia Card/Secure Digital (MMC/SD) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
MMC_1 MMC/SDIO2 Clock is Not Fed Back to the Peripheral for Some I/O Configuration . . . . . . . . . . . . 30<br />
MMC_2 Emulation Mode is Intrusive to the MMC/SDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
MMC_3 CMD12 Implementation in TI MMC/SDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
MMC_4 MMC/SDIO CRC Error in CSD_STRUCTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
MMC_5 When Reset With MMC_CON Register Bit 11 (POW), MMC_STAT Does Not Reset . . . . . . . . . . 31<br />
MMC_6 MMC/SDIO CIRQ Interrupt Does Not Occur for SD-BT Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
MMC_7 MMC/SDIO Partial Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
MMC_8 SPI Mode on the MMC/SD Peripheral is Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
6.2 MICROWIRE Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
UWIRE_1 MICROWIRE Interface RX Data Failures Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
6.3 Inter-Integrated Circuit (I2C) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
I2C_1 I2C Interface Needs to Preload Data Before Transmitting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
6.4 Universal Serial Bus (USB) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
USB_1 W2FC USB Device’s Pullup Enable Wrong Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
USB_2 W2FC USB Does Not Work for Some <strong>OMAP5912</strong> I/O Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
6.5 32k Timer Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
TIMER_1 Timer32K Reload TRB Bit Does Not Work Correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
6.6 Microprocessor Unit I/O (MPUIO) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
MPUIO_1 MPUIO INPUT_LATCH Register Latch is Disabled During TIPB Read Access to it . . . . . . . . . . . . 39<br />
MPUIO_2 MPUIO GPIO_INT is Not Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
6.7 Pulse-Width Tone (PWT) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
PWT_1 Write Followed by Immediate Read not Supported on the PWT Peripheral . . . . . . . . . . . . . . . . . . .<br />
41<br />
4
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
6.8 Camera Interface Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
CAM_1 Interrupt Observability on Camera Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
CAM_2 Camera Interface PEAK_COUNTER May be Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
CAM_3 Camera Interface RAZ FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
CAM_4 Shutdown of Camera Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
CAM_5 Wrong Interrupt Behavior for Camera Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
6.9 Infrared Data Adapter (IrDA) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
IRDA_1 NIRQ can Stay Low for a Few OCP Clock Cycles After an Interrupt is Serviced . . . . . . . . . . . . . . 44<br />
IRDA_3 UART IrDA (MIR Mode) Sends an Additional Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
IRDA_4 When the UART is in Sleep Mode, a Write to THR Wakes Up the UART and<br />
Causes FIFO Synchronization Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
IRDA_5 Rx Overrun and TX_FIFO_FULL Bit Not Operational When FIFO is Disabled . . . . . . . . . . . . . . . . 46<br />
6.10 Universal Asynchronous Receiver/Transmitter (UART) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
UART_1 Falling Edge on UART2.RX May Cause a Wake-up Event on <strong>OMAP5912</strong> . . . . . . . . . . . . . . . . . . . 47<br />
UART_2 Disabled UART’s FIFO Interrupts DMA Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
UART_4 Receive Overrun Not Reset on an Early Read of LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
6.11 Emulation Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
EMU_1 32-bit Peripheral Register Access Through the Debugger Between Two 16-Bit Application<br />
Reads May Corrupt the On-going Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
EMU_2 GDD Does Not Support Execution Suspension in Case of CPU<br />
SUSPEND and FREE Bit = 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
EMU_3 Emulation Access to IT_STATUS_REG Clears Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
EMU_4 Default TDO State During Reset is Unpredictable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
6.12 Specially Optimized Screen Interface (SoSSI) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
SOSSI_1 SoSSI Match Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
SOSSI_2 SoSSI CPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
6.13 Compact Camera Port (CCP) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
CCP_1 Compact Camera Port Software Reset Does Not Reset Attn-Signal Registers . . . . . . . . . . . . . . . 52<br />
CCP_2 CCP DMA Does Not Operate as Expected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
6.14 32-kHz Oscillator Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
OSC_1 32-kHz Oscillator Does Not Power Down in Deep Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
OSC_2 32-kHz Oscillator Does Not Work Properly in <strong>OMAP5912</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
6.15 Serial Peripheral Interface (SPI) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
SPI_1 SPI Slave Not Supported on SPIF.DOUT on ZZG Ball R18 (ZDY Ball N17) . . . . . . . . . . . . . . . . . . 55<br />
SPI_2 SPI Not Able to Receive the First Data While Waking up From Sleep Mode . . . . . . . . . . . . . . . . . . 55<br />
SPI_3 SPI Outputs are not Controlled Correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
SPI_4 SPI Module Does Not Support 8-Bit Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .<br />
56<br />
5
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
6.16 Ultra Low-Power Device (ULPD) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57<br />
ULPD_1 ULPD Analog Cell Configuration are Reset After a MPU Peripheral Reset . . . . . . . . . . . . . . . . . . . 57<br />
6.17 Multichannel Serial Interface (MCSI) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
MCSI_1 Late Generation of TX DMA Request in the MCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
6.18 Multichannel Buffered Serial Port (McBSP) Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
MCBSP_1 McBSP3 3-Pin Operation Versus 4-Pin Operation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
6.19 Dual-Mode Timers Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
DM_TIMER_1 Dual-Mode Timer Peripherals May Not Detect Incoming Events . . . . . . . . . . . . . . . . . . . . . 60<br />
7 <strong>OMAP5912</strong> Device/System Level Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
7.1 System Advisories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
SYS_1 Pulldown on the UWIRE.SDI Pin Needs to be Disabled by Software to Save Power . . . . . . . . . . . 61<br />
SYS_2 When Disabled, the OMAP Peripheral Clock Prevents the <strong>OMAP5912</strong> From Going Into<br />
Deep Sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
SYS_3 <strong>OMAP5912</strong> Gated Outputs Forced to 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
SYS_4 If BVLZ is Not Configured, the Corresponding Interrupt Must be Masked . . . . . . . . . . . . . . . . . . . . 62<br />
SYS_5 Configuration Registers FUNC_MUX_CTRL_10[8:3] and FUNC_MUX_CTRL_9[11:9]<br />
Reset Values Do Not Reflect M8, L3, AA20 Configuration in Reset Mode 1 . . . . . . . . . . . . . . . . . . 63<br />
8 Documentation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .<br />
64<br />
6
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
1 Introduction<br />
SPRZ209C<br />
This document describes the silicon updates to the functional specifications for the<br />
<strong>OMAP5912</strong>, silicon revision B. Issues related to CPU operation are documented in the<br />
TMS320C55x DSP CPU Programmer’s Reference Supplement (literature number SPRU652).<br />
1.1 Device and Development-Support Tool Nomenclature<br />
To designate the stages in the product development cycle, TI assigns prefixes to the part numbers of all TMS320<br />
DSP devices and support tools. Each TMS320 DSP commercial family member has one of three prefixes: TMX,<br />
TMP, or TMS. Texas Instruments recommends two of three possible prefix designators for its support tools: TMDX<br />
and TMDS. These prefixes represent evolutionary stages of product development from engineering prototypes<br />
(TMX/TMDX) through fully qualified production devices/tools (TMS/TMDS).<br />
Device development evolutionary flow:<br />
TMX Experimental device that is not necessarily representative of the final device’s electrical specifications<br />
TMP Final silicon die that conforms to the device’s electrical specifications but has not completed quality and<br />
reliability verification<br />
TMS Fully qualified production device<br />
Support tool development evolutionary flow:<br />
TMDX Development-support product that has not yet completed Texas Instruments internal qualification testing.<br />
TMDS Fully qualified development-support product<br />
TMX and TMP devices and TMDX development-support tools are shipped against the following disclaimer:<br />
“Developmental product is intended for internal evaluation purposes.”<br />
TMS devices and TMDS development-support tools have been characterized fully, and the quality and reliability of the<br />
device have been demonstrated fully. TI’s standard warranty applies.<br />
Predictions show that prototype devices (TMX or TMP) have a greater failure rate than the standard production<br />
devices. Texas Instruments recommends that these devices not be used in any production system because their<br />
expected end-use failure rate still is undefined. Only qualified production devices are to be used.<br />
All trademarks are the property of their respective owners.<br />
7
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
1.2 Revision Identification<br />
SPRZ209C<br />
To designate the stages in the product development cycle, TI assigns prefixes to the part numbers of all OMAP<br />
processors and support tools. Each commercial OMAP platform member has one of three prefixes: X, P, or null (no<br />
prefix). Texas Instruments recommends two of three possible prefix designators for its support tools: TMDX and TMDS.<br />
These prefixes represent evolutionary stages of product development from engineering prototypes (TMDX) through<br />
fully qualified production devices/tools (TMDS).<br />
Device development evolutionary flow:<br />
X Experimental device that is not necessarily representative of the final device’s electrical specifications and<br />
may not use production assembly flow. (TMX definition)<br />
P Prototype device that is not necessarily the final silicon die and may not necessarily meet final electrical<br />
specifications. (TMP definition)<br />
null Production version of the silicon die that is fully qualified. (TMS definition)<br />
Support tool development evolutionary flow:<br />
TMDX Development support product that has not yet completed Texas Instruments internal qualification testing.<br />
TMDS Fully qualified development support product<br />
TMX and TMP devices and TMDX development-support tools are shipped with appropriate disclaimers describing their<br />
limitations and intended uses. Experimental devices (TMX) may not be representative of a final product and Texas<br />
Instruments reserves the right to change or discontinue these products without notice.<br />
TMS devices and TMDS development-support tools have been characterized fully, and the quality and reliability of the<br />
device have been demonstrated fully. TI’s standard warranty applies.<br />
Predictions show that prototype devices (TMX or TMP) have a greater failure rate than the standard production devices.<br />
Texas Instruments recommends that these devices not be used in any production system because their expected<br />
end-use failure rate still is undefined. Only qualified production devices are to be used.<br />
The device revision can be determined by the symbols marked on the top of the ZDY package as shown in<br />
Figure 1. Some prototype devices may have markings different from those shown in Figure 1 with the device name<br />
in the following format: X<strong>OMAP5912</strong>ZDY where X = product level as defined above and ZDY = package.<br />
<strong>OMAP5912</strong><br />
X<strong>OMAP5912</strong>ZDY<br />
4−39Z1158<br />
NOTE: Qualified devices are marked with no prefix at the beginning of the device name, while nonqualified devices are marked with the letter “X”<br />
at the beginning of the device name.<br />
OMAP is a trademark of Texas Instruments.<br />
Figure 1. Example Markings for <strong>OMAP5912</strong> ZDY Package, Revision B<br />
8
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
2 Important Notices and Information About <strong>OMAP5912</strong><br />
2.1 Useful Information Regarding TMS320C55x Assembler Diagnostic Messages<br />
SPRZ209C<br />
The TMS320C55x (C55x) DSP assembler generates three types of diagnostic messages when it detects a<br />
potential or probable <strong>Silicon</strong> Exception.<br />
2.1.1 ERROR Diagnostics<br />
The assembler generates ERROR diagnostics in cases where it can fully determine that the code will cause a<br />
silicon exception to occur on hardware.<br />
2.1.2 WARNING Diagnostics<br />
The assembler generates WARNING diagnostics in cases where it can fully determine that the code will cause a<br />
silicon exception to occur on hardware, but which, under certain circumstances, may not be an issue for the user.<br />
2.1.3 REMARK Diagnostics<br />
The assembler generates REMARK diagnostics in conditions where it can fully determine that the code may cause<br />
a silicon exception to occur on hardware, but the exception itself also depends on non-visible trigger conditions that<br />
the assembler has no knowledge of, such as whether interrupts are enabled.<br />
Since the assembler cannot determine the state of these trigger conditions, it cannot know that the exception will<br />
affect this code. Therefore, it generates a REMARK to instruct the user to examine the code and evaluate whether<br />
this is a potential silicon exception situation. (Please see the following sections for how to suppress remarks in<br />
situations where you have determined that the other trigger conditions do not exist.)<br />
Intended Treatment of REMARK Diagnostics<br />
The intent of generating REMARK diagnostics is to inform the user that the code could potentially cause a silicon<br />
exception and that it should be reviewed by the user side by side with the trigger conditions and a determination be<br />
made whether the code is a potential silicon exception situation.<br />
If the code is determined to be a potential silicon exception situation, users should modify their code to prevent that<br />
exception from occurring.<br />
If users determine that their code will not cause a silicon exception based on the trigger conditions, then the<br />
REMARK that the assembler generates can be suppressed. There are two methods of doing so; please see the<br />
“Suppressing REMARK Diagnostics” section.<br />
Suppressing REMARK Diagnostics<br />
Once the user determines that a silicon exception REMARK diagnostic is not appropriate for the code as written,<br />
the REMARK diagnostic can be suppressed in one of the following ways.<br />
• REMARK directives<br />
• REMARK command-line options<br />
TMS320C55x and C55x are trademarks of Texas Instruments.<br />
9
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
REMARK Directives:<br />
SPRZ209C<br />
The .noremark.remark directives can be used to suppress the generation of a REMARK diagnostic for particular<br />
regions of code. The .noremark directive turns off the generation of a particular REMARK diagnostic. The .remark<br />
directive re-enables the generation of a particular REMARK diagnostic.<br />
A ’.noremark ##’ (where ## is the remark id) directive is placed at the beginning of the region, and a ’.remark ##’<br />
directive is placed at the end of the region.<br />
NOTE: The .noremark.remark directive combination should always be placed around the<br />
entire region of code that participates in the potential silicon exception. Otherwise, spurious<br />
diagnostics may still be generated.<br />
Additionally, the user has the option of disabling a silicon exception diagnostic for the entire file by placing just the<br />
.noremark directive at the top of the assembly file. However, this may be dangerous if, during inevitable code<br />
maintenance, the code is modified by someone not familiar with all the exception conditions. Please take great<br />
care when using the directives in this manner.<br />
REMARK Command-Line Options:<br />
The compiler shell (cl55) supports a command line option to suppress a particular REMARK diagnostic. The shell<br />
option −ar# (where # is the assembler’s silicon exception id as described above) suppresses the named REMARK<br />
for the entire scope of all assembly files compiled with that command. Using the option −ar without a number<br />
suppresses all REMARK diagnostics.<br />
Again, this may be dangerous if, during inevitable code maintenance, the code is modified by someone not familiar<br />
with all the silicon exception conditions. Please take great care when using the command-line REMARK options.<br />
Using the .noremark/.remark directives covering the shortest possible range of source lines is much safer.<br />
10
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
3 DSP Subsystem Advisories<br />
3.1 DSP ICACHE Advisories<br />
Advisory<br />
DSP_ICACHE_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
ICACHE Update of TAG-RAM on Wrong Location When a Miss Occurs Between<br />
RAMSET Preload<br />
Details: The two ramset banks inside the ICACHE are preloaded when the corresponding ramset tag<br />
registers’ content are updated through I/O access. The ramset preload uses the same line-fill<br />
mechanism as the cache miss line-fill; therefore, there is a conflict of resource when the<br />
ramset refill happens while the I-cache miss line-fill is on. Although there is logic to arbitrate<br />
this conflict, a functional bug can corrupt the content of Tag ram under a corner condition as<br />
described below:<br />
1. I-cache must be turned on with ramset(s) enabled.<br />
2. The instruction(s) for updating the ramset tag register(s) are embedded with other<br />
program code in external memory.<br />
3. The external memory space where the instruction(s) for updating the ramset tag(s) are not<br />
present in the ICACHE will generate cache miss.<br />
Example:<br />
The following assembly code is likely to encounter this faulty corner case:<br />
Address Instruction<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
...<br />
......<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
Ext Mem *port(#0x1400) = #0xc 2f ; Configure icache<br />
Ext Mem bit(ST3,#14) = #1 ; Turn on icache<br />
Ext Mem *port(#0x1406) = #0x0800 ; Update ramset tag for bank1<br />
Ext Mem *port(#0x1408) = #0x0801 ; Update ramset tag for bank2<br />
Ext Mem DSP code<br />
Ext Mem DSP coI......<br />
......<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
While the ramset tag is being updated by the I/O bus, the CPU IBQ is prefetching instructions<br />
that are not present in ICACHE.<br />
11
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Workaround:<br />
SPRZ209C<br />
ICACHE Update of TAG-RAM on Wrong Location When a Miss Occurs Between RAMSET Preload (Continued)<br />
1. Put the code for updating the ramset tag in internal memory, i.e., non-cacheable memory<br />
space.<br />
2. Branch from external memory program code to the ramset tag update code.<br />
3. Continue polling the ramset tag valid bit to make sure the ramset preload has finished.<br />
4. Branch back to external memory for normal program execution after the preload has<br />
finished.<br />
For example:<br />
Address Instruction<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
...<br />
......<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
Ext Mem *port(#0x1400) #0xce2f ; Configure icache<br />
Ext Mem bit(ST3,#14) = #1 ; Turn on icache<br />
EXt Mem goto Preload_ramsets<br />
Preload_ramsets:<br />
Int Mem *port(#0x1406) = #0x0800 ; Update ramset tag for bank1<br />
Scan0:<br />
Int Mem TC1 = bit(*port(0x1405), #15) ; Read the Tag Valid<br />
; bit of ramset bank 0<br />
Int Mem nop_16<br />
Int Mem if (!TC1) goto Scan0 ; Continue polling if the<br />
; Tag Valid bit is not 1.<br />
Int Mem *port(#0x1408) = #0x0801 ; Update ramset tag for bank1<br />
Scan1:<br />
Int Mem TC1 = bit(*port(0x1407), #15) ; Read the Tag Valid<br />
; bit of ramset bank 1<br />
Int Mem nop_16<br />
Int Mem if (!TC1) goto Scan1 ; Continue polling if the<br />
; Tag Valid bit is not 1.<br />
Int Mem goto Back_from_ramset_preload<br />
Back_from_ramset_preload:<br />
Ext Mem DSP code<br />
Ext Mem I Ie<br />
......<br />
......<br />
Ext Mem DSP code<br />
Ext Mem DSP code<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
12
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
3.2 DSP Emulation Advisories<br />
Advisory<br />
DSP_EMU_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
DSP IDLE Interrupt Not Serviced When an Emulator is Connected<br />
Details: A DSP IDLE Interrupt is not serviced when the emulator is connected as shown below:<br />
1. Emulator connected<br />
2. RT mode is set<br />
3. Run test code<br />
ASM code sets INTM<br />
ASM code clears all pending interrupts in IFR<br />
ASM code configures timers, but does not enable<br />
ASM code sets ICR to 0x3f<br />
4. Emulator halts CPU<br />
PC indicates halted at IDLE instruction<br />
DBGSTAT = 0x805f (IDLE, DSUSP and FXWOK)<br />
ISR = 0x3f<br />
No interrupts pending in IFR<br />
5. Provide single interrupt.<br />
6. Enable RT int by emulation write to DBIER0<br />
Halted background code immediately comes out of idle<br />
ISR = 0x3F (interrupt not taken)<br />
Workaround: There is no workaround. The emulator result is different from the functional mode (which will<br />
service the ISR). This only affects the debugger mode.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
13
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
DSP_EMU_2<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Emulation is Broken When the DSP is in Isolation Mode<br />
Details: DSP isolation does not route TDI to TDO signals to allow the emulation to continue operating<br />
once the DSP is put in isolation mode. The DSP can be placed in isolation mode to save<br />
leakage current by setting bit 12 of POWER_CTRL_REG in ULPD.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
14
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
3.3 DSP EMIF Advisories<br />
Advisory<br />
DSP_EMIF_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
DSP EMIF/DMA Port Hangs During EMIF Bus Error<br />
Details: If the EMIF times out, the CPU will get a timeout bus error interrupt which may also cause a<br />
DMA interrupt. If this occurs, the DMA will not timeout but will hang instead.<br />
Workaround: Whenever an EMIF bus error interrupt occurs, the software needs to reset the DMA and<br />
reschedule the transfer.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
15
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
3.4 DSP System Advisories<br />
Advisory<br />
DSP_SYS_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Bus Error Issued on Byte Accesses to I/O Space, 0x0 Through 0x5f<br />
Details: A bus error is wrongly issued when a byte access is made to I/O space, address 0x0 through<br />
0x5f. A bus error is captured by IFR1 bit 8 as “BERRINTF” and ST3 bit 7 as “CBERR”. The<br />
following is the entire list of byte-access instructions.<br />
dst = uns(high_byte(Smem))<br />
dst = uns(low_byte(Smem))<br />
ACx = low_byte(Smem)
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
DSP_SYS_3<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Page Table of DSPMMU Gets Corrupted in Synchronous Scalable Mode<br />
Details: When the DSPMMU is configured in the following configuration:<br />
1. Walking Table Logic (WTL) is enabled<br />
2. Configured for large or small or tiny page (with two level descriptors)<br />
3. <strong>OMAP5912</strong> is in Synchronous Scalable mode.<br />
The page table inside external memory gets corrupted when a miss occurs due to an extra<br />
write request generated by the SYNC DSP modules.<br />
When a SYNC DSP module request is registered to transfer the request from the DSPMMU to<br />
the TC, and the WTL is enabled and a miss occurs, the DSPMMU reads the descriptors from<br />
the page table through the sync DSP module and Traffic Controller. During the transition<br />
between the first level descriptor fetch and second level descriptor fetch, the SYNC DSP<br />
generates an extra write request to the first level descriptor location due to improper<br />
synchronization of request signal. This extra write corrupts the page table. As long as the TLB<br />
does not get flushed, there is no problem with this extra write to the page table. When the TLB<br />
is flushed and another miss occurs, the DSPMMU fetches the wrong descriptor.<br />
This problem does not occur with section (only first level descriptor fetch only). This is<br />
because there are no back-to-back requests from the DSPMMU to SYNC DSP.<br />
Workaround: There is no workaround; however, this exception only occurs when the clock mode is set to<br />
synchronous scalable mode, and walking table logic and two level descriptors are used.<br />
Except for operating systems, normal applications do not use two level descriptors and<br />
walking table logic functions. Use only sections in the DSPMMU to avoid any problem due to<br />
the corruption of the page table.<br />
17
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
DSP_SYS_4<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Data Page Register and Stack Pointer Updates are not Pipeline-Protected Against<br />
Data Move Instructions<br />
Details: The following registers are used for address generation in direct-addressing mode:<br />
• XDP[22:0] (DPH[6:0] and DP[15:0]) when the CPL bit (ST1[14]) is 0. (Note that DP[15:7] is<br />
mapped to ST0[8:0].)<br />
• XSP[22:0] (SPH[6:0] and SP[15:0]) when the CPL bit (ST1[14]) is 1.<br />
Any update to these registers, followed by direct-addressing mode, is completed by the<br />
address generation. However, because of a missing pipeline-protection mechanism, under the<br />
following conditions, the update of the registers will not be reflected for the address<br />
generation.<br />
Condition 1<br />
• Instruction to update the Data Page register or Stack Pointer in the EXECUTE phase.<br />
(*See the instruction list below.)<br />
• less than 4 instruction cycles<br />
• Smem = coeff || readport() or coeff = Smem || writeport()<br />
(Smem is in direct-addressing mode. Only these two pairs are problem cases; other<br />
instructions work fine.)<br />
(*)<br />
When CPL = 0,<br />
Xdst = Xsrc (Xdst is XDP)<br />
Xdst = popboth() ( ” )<br />
XAdst = dbl(Lmem) (XAdst is XDP)<br />
DP = Smem<br />
DPH = Smem<br />
bit(ST0,#k4) = #0/1 (k4 is 8,7, ... ,1,0)<br />
When CPL = 1,<br />
Xdst = Xsrc (Xdst is XSP or XSSP)<br />
Xdst = popboth() ( ” )<br />
XAdst = dbl(Lmem) (XAdst is XSP or XSSP)<br />
SP = Smem<br />
SP = TAx<br />
SP = SP + K8<br />
18
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
Data Page Register and Stack Pointer Updates are not Pipeline Protected Against Data Move Instructions (Continued)<br />
Condition 2<br />
Instruction with MMR write to<br />
• DPH(0x2B)/DP(0x2E)/ST0_55(0x02)/ST0(0x06) with CPL = 0 or<br />
SPH(0x4E)/SP(0x18,0x4D) with CPL = 1 in WRITE phase<br />
• less than 5 instruction cycles<br />
• “Smem = coeff || readport()” or “coeff = Smem || writeport()”<br />
(Smem is in direct-addressing mode. Only these two pairs are problem cases; other<br />
instructions work fine.)<br />
Workaround: Make sure enough instruction slots are inserted between the two events as follows:<br />
• More than 4 instruction slots for Condition 1.<br />
• More than 5 instructions slots for Condition 2.<br />
Example:<br />
XDP = AC0<br />
nop<br />
nop<br />
nop<br />
nop<br />
@#0xa = coef(*CDP) || readport()<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
19
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
4 MPU Subsystem Advisories<br />
4.1 System Direct Memory Access (DMA) Advisories<br />
Advisory<br />
SYS_DMA_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Incorrect Value in DMA_PCHx_SR Register<br />
Details: The SDMA global registers—PchSR_M0, PchSR_M1, and PchSR_P—are used to display the<br />
current logical channel which is running on the M0, M1, and P physical channels, respectively.<br />
However, in <strong>OMAP5912</strong> these registers do not show the correct logical channel when the<br />
channels are individually enabled. These registers get updated only when all the physical<br />
channels (M0, M1, and P) are working simultaneously. Update of any particular PchSR<br />
register depends on the enabling of other physical channels.<br />
Workaround: Do not rely on these registers if you are running less than 3 logical channels.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
20
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
4.2 MPU Emulation Advisories<br />
Advisory<br />
MPU_EMU_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Emulation Connection is Intrusive to ARM Idle Mode.<br />
<strong>OMAP5912</strong> Cannot Go Into Idle With Code Composer Studio Connected.<br />
Details: The JTAG on ARM926EJ-S does not work if the functional clock is halted.<br />
The logic to the on-chip power management is gated by emulator connection so that the<br />
functional clock is not shut down and the sleep mode is not entered.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
ARM926EJ-S is a trademark of ARM Limited in the EU and other countries.<br />
21
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
4.3 MPU System Advisories<br />
Advisory<br />
MPU_SYS_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MPU IRQ122−127 Can Cause Spurious Interrupts<br />
Details: On <strong>OMAP5912</strong>, MPU IRQ122 through IRQ127 are tied low and therefore, are capable of<br />
interrupting the system if their corresponding ILR registers (from address 0xFFFE:0384 for<br />
IRQ122 to 0xFFFE:0398 for IRQ127) are configured as level-sensitive.<br />
A level interrupt is configured if SENS_EDGE is set to 1 (bit 1 of ILR register).<br />
Workaround: Make sure SENS_EDGE is cleared to 0 for IRQ122−IRQ127’s IRL registers (from address<br />
0xFFFE:0384 for IRQ122 to 0xFFFE:0398 for IRQ127).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
MPU_SYS_2<br />
Revision(s) Affected: B<br />
Special Software Procedure is Needed to Acknowledge ARM LV1 Interrupt<br />
Details: The correct procedure for acknowledging an interrupt in the LV1 interrupt handler is described<br />
below:<br />
• INTH asserts an interrupt<br />
• ARM enters an interrupt routine<br />
• ARM executes the interrupt routine<br />
At the end of the interrupt routine, ARM needs to do the following:<br />
• Save the LV1 MIR (Mask interrupt) register<br />
• Mask all interrupts<br />
• For level-sensitive interrupt, clear the source of the interrupt<br />
• For edge-sensitive interrupt, clear the current interrupt line in the INTH<br />
• Write to the NEW_IRQ_AGR register to clear the register<br />
• Restore MIR<br />
22
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
Special Software Procedure is Needed to Acknowledge ARM LV1 Interrupt (Continued)<br />
If this is not done, no interrupt will be missed; however, there might be an interrupt priority<br />
problem:<br />
• If the interrupt that is acknowledged in the interrupt routine is asserted again before<br />
NEW_IRQ_AGR bit is written, then the LV1 INTH will register this interrupt as the currently<br />
pending interrupt, even if higher-priority interrupts are still pending.<br />
• The other interrupts will have to wait.<br />
One common case when this might happen is if two or more lv2 interrupts fire almost at the<br />
same time.<br />
At the end of ISR, LV2 INTH’s NEW_IRQ_AGR is set at first and LV1’s one is set next. IRQ to<br />
LV1 is asserted again before setting Lv1’s NEW_IRQ_AGR if there is other pending interrupt<br />
request on Lv2. Interrupt request on Lv2 will be serviced first regardless of priority on any<br />
possibly active Lv1 interrupts.<br />
Workaround: At the end of the interrupt routine, ARM needs to do the following:<br />
• Save the LV1 MIR (Mask interrupt) register<br />
• Mask all interrupts<br />
• For level-sensitive interrupts, clear the source of the interrupt<br />
• For edge-sensitive interrupts, clear the current interrupt line in the INTH<br />
• Write to the NEW_IRQ_AGR register to clear the register.<br />
• Restore MIR<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
23
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
4.4 MPU Watchdog Timer Advisories<br />
Advisory<br />
MPU_WATCHDOG_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MPU Watchdog Does Not Reset DPLL<br />
Details: If the MPU watchdog timer expires, a reset is provided to the ARMCK_CTL registers (resetting<br />
the clock divisors) but not to the DPLL.<br />
This means that when <strong>OMAP5912</strong> is operating at 192 MHz with SDRAM at 96 MHz (/2) and a<br />
WD timer reset occurs, the ARM will begin executing code at the reset vector with the DPLL<br />
remaining at 192 MHz and all clock divisors set at /1. See below:<br />
• Before reset:<br />
− DPLL register (0xFFFE CF00) = 0x2813 (DPLL Lock mode, 16 x multiplier)<br />
− ARM_SYSST register (0xFFFE CE18) = 0x1000 (Synchronous scalable mode)<br />
− ARM_CKCTL register (0xFFFE CE00) = 0x5101 (ARMINTH, TC. PER clocks div/2;<br />
clkref = CLKGen1)<br />
• After reset:<br />
− DPLL register (0xFFFE CF00) = 0x2813 − No change<br />
− ARM_SYSST register (0xFFFE CE18) = 0x000C (Full synchronous mode,<br />
WD + MPU reset)<br />
− ARM_CKCTL register (0xFFFE CE00) = 0x3000 (No div; clkref = CLKGen1)<br />
Workaround: Use the 32k watchdog timer. It properly resets the DPLL when it expires; however, the 32k WD<br />
Timer has less precision on the timer value (it counts 30.5 µs ticks instead of ~0.1 µs ticks)<br />
and cannot cause a WD reset to occur in less than 30.5 µs.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
24
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
5 Traffic Controller Subsystem Advisories<br />
5.1 EMIF Slow (EMIFS) Advisories<br />
Advisory<br />
EMIFS_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Wrong Behavior on CS0<br />
Details: Due to incorrect decoding logic on CS0 (between internal peripherals and External NOR<br />
FLASH), NOR flash cannot be accessed on CS0 (32Mb).<br />
Workaround: There is no workaround. Do not map external memory on EMIFS Chip Select 0.<br />
TI is investigating whether this feature will be fixed on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
EMIFS_2<br />
Revision(s) Affected: B<br />
Program Fetch Prevents Sleep Entry<br />
Details: An address range centered on 0x0000_3C18 cannot be used while booting from EMIFS Chip<br />
Select 3. If the program enters this particular address range, a debug request is sent to the<br />
ARM processor which prevents <strong>OMAP5912</strong> from entering the idle mode.<br />
This behavior is intentional and is related to <strong>OMAP5912</strong> special features. This feature will not<br />
affect normal devices as the booting is done from the internal Boot ROM.<br />
Workaround: The software has to stay away from 0x0000_3C18 ± 10 x 32-bit addresses. This is needed to<br />
account for the ARM926 pipeline architecture.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
25
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
5.2 EMIF Fast (EMIFF) Advisories<br />
Advisory<br />
EMIFF_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Dual Data Rate (DDR) SDRAM Interface Does Not Support Dual Data Rate Speeds<br />
Details: Because of the way the EMIFF DDR interface is implemented internally on the <strong>OMAP5912</strong>,<br />
there are on-chip delays in the EMIFF data path that limit the rate at which DDR SDRAM<br />
memories can be accessed. DDR SDRAM will give no improvement in performance than<br />
single data rate SDRAM.<br />
Workaround: There is no workaround.<br />
TI does intend to correct this functionality on a future revision of <strong>OMAP5912</strong>.<br />
Advisory<br />
EMIFF_2<br />
Revision(s) Affected: B<br />
SDRAM Interface MRS/EMRS Command Issued Twice<br />
Details: When the ACCESS_FACTOR1 in the RHEA CNTL register is configured for values strictly<br />
greater than 1, unpredictable behavior occurs on the SDRAM bus and multiple MRS<br />
commands are issued by the Traffic Controller.<br />
Workaround: Make sure that the ACCESS_FACTOR1 (bit field 7:4) in the RHEA CNTL (0xFFFE:CA00) is<br />
set to 1 so that the strobe_1 period on the TIPB bus is equal to 1/2 the TIPB bridge clock<br />
period.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
26
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
EMIFF_3<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Glitch in DPLL Clock During Reset Assertion Affects EMIFF State Machine<br />
Details: When a reset to the DPLL is asserted, there is a glitch at the output of the DPLL due to the<br />
transition from DPLL core clock (high frequency) to the DPLL reference clock.<br />
When a warm reset (MPU reset) occurs, it does not reach the EMIFF. This may cause the<br />
EMIFF to not enter self-refresh mode. Because of this, data in EMIFF may get corrupt.<br />
When a power-on-reset (POR) is asserted, there is no functional failure as the entire<br />
<strong>OMAP5912</strong> device gets reset.<br />
Workaround: There is no software workaround if a warm reset (MPU reset) is asserted. A power-on-reset is<br />
the only way to recover the EMIFF state machine.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
27
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
5.3 Traffic Controller Advisories<br />
Advisory<br />
TC_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
<strong>OMAP5912</strong> Global Software Reset Affects Traffic Controller Frequency<br />
Details: At power-up reset, the traffic controller (TC) clock is the system clock (base frequency is<br />
19.2 MHz, 12 MHz, or 13 MHz) and in fully synchronous mode (ARM clock = DSP clock =<br />
TC clock). During boot, if the user decides to do the following:<br />
MODULE<br />
• Switch to synchronous scalable mode (ARM clock = DSP clock, TC clock = ARM clock/2)<br />
and enable the DPLL (system clock x 10 = 192-MHz clock if the base frequency is<br />
19.2 MHz),<br />
• Perform a global software reset by:<br />
− setting the SW_RST bit (bit 3 in the ARM_RSTCT1 register), or<br />
− setting the ARM RST bit (bit 0 in the ARM_RSTC1 register) and then clearing the<br />
DSP_EN bit (bit 1 in the ARM_RSTC1 register).<br />
Then, the DPLL is still enabled and <strong>OMAP5912</strong> is switched back automatically to fully<br />
synchronous mode (ARM_SYSST register is reset). This causes: ARM clock = DSP clock =<br />
TC Clock =192 MHz. 192 MHz is too high of a frequency for the TC to operate and can<br />
potentially cause incorrect data to be fetched. See Table 1.<br />
Table 1. Reset Sources for the Clock Module and the DPLL<br />
Cold Reset † Warm Reset ‡<br />
Global<br />
System<br />
Reset §<br />
ARM<br />
WD Reset<br />
EVENT<br />
DSP<br />
WD Reset<br />
MPU<br />
Software<br />
Reset<br />
DSP<br />
Software<br />
Reset <br />
DSP<br />
Software<br />
Reset #<br />
CLKM_1 Yes Yes Yes Yes No No No No<br />
CLKM_2 Yes Yes Yes Yes No No No No<br />
CLKM_3 Yes Yes Yes Yes No No No No<br />
DPLL_1 Yes Yes No No No No No No<br />
DPLL_2 Yes Yes No No No No No No<br />
† Power-up reset or on_noff<br />
‡ MPU_nreset, secure WD reset, or 32-kHz WD reset<br />
§ SW_RST (Bit 3 in ARM_RSTCT1) is written to 1, or set ARMRST (Bit 0 in ARM_RSTC1) and clear DSP_EN (Bit 1 in<br />
ARM_RSTC1)<br />
DSP_EN (Bit 1 in ARM_RSTC1) is written to 0<br />
# DSP_RST (Bit 2 in ARM_RSTC1) is written to 1<br />
28
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SPRZ209C<br />
<strong>OMAP5912</strong> Global Software Reset Affects Traffic Controller Frequency (Continued)<br />
Workaround: Before performing a Global Software Reset, it is recommended that the DPLL be bypassed so<br />
that after the clock module has reset to fully synchronous mode, the TC frequency is equal to<br />
the <strong>OMAP5912</strong> base frequency.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
29
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6 <strong>OMAP5912</strong> Peripheral Advisories<br />
6.1 Multimedia Card/Secure Digital (MMC/SD) Advisories<br />
Advisory<br />
MMC_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MMC/SDIO2 Clock is Not Fed Back to the Peripheral for Some I/O Configuration<br />
Details: MMC/SDIO input timings are referenced to the feedback input clock. The feedback input clock<br />
is wrapped around from the output clock, through a bidirectional I/O, and back to the feedback<br />
clock input port of the MMC/SDIO subchip/ports. For MMC/SDIO2, there are two pins that can<br />
provide this clock function, MCSI2.CLK (ZZG ball Y10; ZDY ball P8) and CAM.RSTZ (ZZG<br />
ball M19; ZDY ball K12). CAM.RSTZ is not getting wrapped back around and routed to the<br />
feedback clock port ADPFDBKCLKI.<br />
Workaround: Do not use remapping of MMC2.CLK on CAM.RSTZ (ZZG ball M19; ZDY ball K12). Instead,<br />
use MCSI2.CLK (ZZG ball Y10; ZDY ball P8).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
MMC_2<br />
Revision(s) Affected: B<br />
Emulation Mode is Intrusive to the MMC/SDIO<br />
Details: Using Code Composer Studio Integrated Development Environment (IDE), executed step by<br />
step, the following was observed:<br />
MMC_SDIO1_CON_16_0 = 0x803<br />
There is no effect in the Code Composer Studio memory window at the corresponding<br />
0xFFFB780C address. Moreover, if a direct Code Composer Studio read command tries to<br />
access this address, the same result occurs.<br />
Workaround: If you put back the PC pointer to the same instruction and run it to some latter point in the<br />
code (not step-by-step). The instruction is well executed and 0x803 is written to the register.<br />
TI does intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Code Composer Studio is a trademark of Texas Instruments.<br />
30
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
MMC_3<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
CMD12 Implementation in TI MMC/SDIO<br />
Details: The Multimedia Card System specification (Revision 3.2) states that while the CMD12 Stop<br />
Command is issued by the Host, valid data can still be received or sent (refer to Figures 28<br />
and 31 of the MMC card specification).<br />
The TI MMC/SDIO state machine will block any CMD12 stop command as soon as the receive<br />
FIFO is full to avoid the loss of a valid read data. Similarly, in case of a write sequence, the TI<br />
MMC/SDIO state machine will block any CMD12 stop command if the transmit FIFO is empty.<br />
Workaround: During a read sequence, make sure the receive FIFO is not full before issuing a CMD12 stop<br />
command. During a write sequence, make sure the transmit FIFO is not empty before issuing<br />
a CMD12 stop command.<br />
Advisory<br />
MMC_4<br />
Revision(s) Affected: B<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
MMC/SDIO CRC Error in CSD_STRUCTURE<br />
Details: In normal operations, the MMCSDIO controller reads the CSD_structure register of the<br />
external card. However, during CRC calculation, it does not account for the field related to the<br />
CSD_STRUCTURE register version 1.2 (bit 2 of the CSD_Structure). Consequently, a CRC<br />
error occurs.<br />
Workaround: If a CRC error occurs (MMC_STAT bit 8 is set and Data CRC Error is set), the software should<br />
do a CRC software computation on the 128 bits received during the read of the<br />
CSD_Structure to confirm if it was a valid CRC error.<br />
Advisory<br />
MMC_5<br />
Revision(s) Affected: B<br />
TI does intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
When Reset With MMC_CON Register Bit 11 (POW), MMC_STAT Does Not Reset<br />
Details: During power-off, MMC_STAT is supposed to be reset by setting the POW bit in the<br />
MMC_CON register; however, this does not occur.<br />
Workaround: Software workaround: write 0xFFFF to MMC_STAT after a POW reset.<br />
TI does intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
31
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
MMC_6<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MMC/SDIO CIRQ Interrupt Does Not Occur for SD-BT Response<br />
Details: An asynchronous interrupt on DAT [1] is not propagated to the MMC_STAT [CIRQ] when the<br />
MMCSDIO peripheral is in auto IDLE with its interface OCP clock turned off. Because the<br />
OCP clock is off, incoming events from the external MMC/SDIO card are not synchronized.<br />
Workaround: There are two ways to switch on the interface OCP clock when the module is in auto-idle<br />
state:<br />
Advisory<br />
MMC_7<br />
Revision(s) Affected: B<br />
• OCP accesses by the host: polling loop on the MMC_STAT register.<br />
• Set bit INAB = 1 in the MMC_CMD register after the BRS (Block received/sent) in the<br />
MMC_STAT register is set after completion of a command + data transfer. This will trigger<br />
an EOC (end-of-command) interrupt. During this EOC interrupt, if a CIRQ interrupt does<br />
not occur, read the MMC_STAT register and set bit INAB = 1 again, which will trigger<br />
another EOC, and so on, until CIRQ = 1, which will happen if DAT [1] is low (the time<br />
when DAT [1] goes low is not always predictable).<br />
MMC/SDIO Partial Reset<br />
Details: When setting the SRST bit in the MMC_SYSC register to perform a software reset, the RSTD<br />
bit in the MMC_SYSS register never gets set.<br />
Workaround: To perform a partial reset, the following sequence must be used:<br />
1. Set up the module as needed (with a POW=1)<br />
2. Clear the POW and the CKDIV bits<br />
3. Set the POW along with the CKDIV bits<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
MMC_8<br />
Revision(s) Affected: All revisions<br />
SPI Mode on the MMC/SD Peripheral is Not Supported<br />
Details: The SPI mode on the MMC/SD peripheral is not supported on this device.<br />
Workaround: This exception will not be fixed in future silicon revisions.<br />
32
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.2 MICROWIRE Advisories<br />
Advisory<br />
UWIRE_1<br />
Revision(s) Affected: B<br />
Details: See the table below and Figure 2 and Figure 3.<br />
CSx_EDGE_RD = 0<br />
CSx_EDGE_WR = 0<br />
SCLK Not Inverted Data read on falling edge of<br />
SCLK. Data write on falling<br />
edge of SCLK.<br />
Delay of 2 SCLK cycles<br />
between last bit transmitted<br />
on falling edge and first bit<br />
captured on falling edge.<br />
No issue.<br />
SCLK Inverted Data read on rising edge of<br />
SCLK. Data write on rising<br />
edge of SCLK.<br />
Delay of 2 SCLK cycles<br />
between last bit transmitted<br />
on rising edge and first bit<br />
captured on rising edge.<br />
No issue.<br />
CSx_EDGE_RD = 1<br />
CSx_EDGE_WR = 1<br />
Data read on rising edge of<br />
SCLK. Data write on rising<br />
edge of SCLK.<br />
Delay of 2 SCLK cycles<br />
between last bit transmitted<br />
on rising edge and first bit<br />
captured on rising edge.<br />
No issue.<br />
Data read on falling edge of<br />
SCLK. Data write on falling<br />
edge of SCLK.<br />
Delay of 2 SCLK cycles<br />
between last bit transmitted<br />
on falling edge and first bit<br />
captured on falling edge.<br />
No issue.<br />
MICROWIRE is a registered trademark of National Semiconductor Corporation.<br />
SPRZ209C<br />
MICROWIRE Interface RX Data Failures Possible<br />
CSx_EDGE_RD = 0<br />
CSx_EDGE_WR = 1<br />
Data read on falling edge of<br />
SCLK. Data write on rising<br />
edge of SCLK.<br />
Delay of 1.5 SCLK cycles<br />
between last bit transmitted<br />
on rising edge and first bit<br />
captured on falling edge.<br />
Issue found (see Figure 2):<br />
One extra bit is captured.<br />
Workaround:<br />
Ignore Bit 0 of the receive<br />
data register (shift right one<br />
bit). Note that this<br />
workaround does not work for<br />
a 16-bit data configuration<br />
(1 bit is lost).<br />
Data read on rising edge of<br />
SCLK. Data write on falling<br />
edge of SCLK.<br />
Delay of 1.5 SCLK cycles<br />
between last bit transmitted<br />
on falling edge and first bit<br />
captured on rising edge.<br />
Issue found:<br />
One extra bit is captured.<br />
Workaround:<br />
Ignore Bit 0 of the receive<br />
data register (shift right one<br />
bit). Note that this<br />
workaround does not work for<br />
a 16-bit data configuration<br />
(1 bit is lost).<br />
CSx_EDGE_RD = 1<br />
CSx_EDGE_WR = 0<br />
Data read on rising edge of<br />
SCLK. Data write on falling<br />
edge of SCLK.<br />
Delay of 2.5 SCLK cycles<br />
between last bit transmitted<br />
on falling edge and first bit<br />
captured on rising edge.<br />
Issue found (see Figure 3):<br />
First bit captured will start<br />
2.5 SCLK cycles after the last<br />
bit sent instead of 1.5 SCLK<br />
as defined in the specifications.<br />
Workaround:<br />
Do not use this configuration.<br />
Use one of the alternate<br />
configurations available for<br />
this module.<br />
Data read on falling edge of<br />
SCLK. Data write on rising<br />
edge of SCLK.<br />
Delay of 2.5 SCLK cycles<br />
between last bit transmitted<br />
on rising edge and first bit<br />
captured on falling edge.<br />
Issue found:<br />
First bit captured will start<br />
2.5 SCLK cycles after the last<br />
bit sent instead of 1.5 SCLK<br />
as defined in the specifications.<br />
Workaround:<br />
Do not use this configuration.<br />
33
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
SCLK<br />
DI_PG<br />
DO<br />
NCS0<br />
SPRZ209C<br />
MICROWIRE Interface RX Data Failures Possible (Continued)<br />
One Extra<br />
Read Occurs<br />
Figure 2. Write (4 Bits) on Rising/Read (4 Bits) on Falling (TX = 0xA, RX and 0x1F = 0x14)<br />
SCLK<br />
DI_PG<br />
DO<br />
NCS0<br />
No Read<br />
Occurs Here<br />
Figure 3. Write (4 Bits) on Falling/Read (4 Bits) on Rising (TX = 0xA, RX and 0xF = 0xA)<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
34
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.3 Inter-Integrated Circuit (I 2 C) Advisories<br />
Advisory<br />
I2C_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
I 2 C Interface Needs to Preload Data Before Transmitting<br />
Details: Software needs to enable the I 2 C peripheral in transmit mode before writing data to the FIFO.<br />
This does not apply for receive mode.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
35
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.4 Universal Serial Bus (USB) Advisories<br />
Advisory<br />
USB_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
W2FC USB Device’s Pullup Enable Wrong Polarity<br />
Details: The W2FC (USB device) pullup enable can be controlled by an output signal in the three<br />
different ways shown below. In each case, the polarity is the opposite of what is specified.<br />
1. ZZG ball W4 (ZDY ball P4), USB.PUEN (conf “000”), is active-low but should be high.<br />
2. ZZG ball W4 (ZDY ball P4), USB.PUDIS (conf “011”), is active-high but should be low.<br />
3. ZZG ball P9 (ZDY ball T2), USB.PUEN (conf “111”), is active-low but should be high.<br />
NOTE: The USB pullup can also be controlled elsewhere (e.g., in a UART/I 2 C/SPI-controlled<br />
USB OTG PHY). In these cases, this exception has no impact.<br />
Workaround: For each of the three cases above, possible software or hardware workaround are possible.<br />
Advisory<br />
USB_2<br />
Revision(s) Affected: B<br />
1. Software: Use case 2) instead<br />
2. Software: Use case 1) instead<br />
3. Hardware: Use a GPIO pin instead as pullup enable. GPIO should be set to 1 after the<br />
pullup is enabled in the W2FC, and to 0 before it is disabled.<br />
Hardware: Add external inverter or change pullup implementation.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
W2FC USB Does Not Work for Some <strong>OMAP5912</strong> I/O Settings<br />
Details: When mapped on OMAP Port2 (external PHY), USB Port0 works in the following PHY<br />
interface modes:<br />
• unidirectional<br />
• 6-pin or bidirectional 3-pin/4-pin<br />
USB Port 2 (external PHY) activity disrupts USB Port 0 inputs if that port is also used on the<br />
internal transceiver. This activity causes random reactions on USB Port 0, regardless of the<br />
PHY mode used on Port 2. Figure 4 shows USB implementation on <strong>OMAP5912</strong>. Note that<br />
other I/O multiplexing are implemented on <strong>OMAP5912</strong> USB Port2 (for instance, I/O of<br />
UART2).<br />
36
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
<strong>OMAP5912</strong><br />
USB<br />
OTG<br />
I 2 C<br />
UART<br />
0<br />
1<br />
2<br />
SPRZ209C<br />
W2FC USB Does Not Work for Some <strong>OMAP5912</strong> I/O Settings (Continued)<br />
Signals<br />
Muxing<br />
and<br />
Isolation<br />
Logic<br />
Config<br />
USB<br />
Port<br />
0<br />
D+<br />
D−<br />
USB USB<br />
D+<br />
Port<br />
Transceiver<br />
1<br />
IC D−<br />
USB<br />
Port<br />
0,2<br />
Integrated<br />
USB Lines<br />
Transceiver<br />
USB<br />
Transceiver<br />
IC<br />
Figure 4. USB Implementation on <strong>OMAP5912</strong><br />
Workaround: Do not use USB port 0 (with internal transceivers) and USB port 2 simultaneously.<br />
System-level configuration bit USB_TRANSCEIVER_CTRL.CONF_USB2_UNI_R must be set<br />
to 1 (default value is 0 after reset).<br />
This bit configures USB port 2 interface with external USB transceiver.<br />
• 0: bidirectional mode<br />
• 1: unidirectional mode<br />
This setting is required to avoid any corruption on USB Port #0 while using UART2 on ZZG<br />
balls V6 and W5 (ZDY balls R4 and T4).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
D+<br />
D−<br />
37
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.5 32k Timer Advisories<br />
Advisory<br />
TIMER_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Timer32K Reload TRB Bit Does Not Work Correctly<br />
Details: The Timer32K reload bit (TRB) is used to load the TCR register with the value contained in the<br />
TVR register. Once the TCR is loaded, the TRB bit should be automatically reset to ‘0’. The<br />
user should be able to use the TRB bit (by polling) to know when to load a new value in the<br />
TVR.<br />
However (see Figure 5), the TRB bit is reset to zero by the falling edge of 32-kHz clock only<br />
after a maximum of 1.5 x 32-kHz clock period (or minimum 0.5 x 32-kHz clock period) after the<br />
TRB bit is set. The TCR register is loaded after a maximum of 2 x 32-kHz clock periods (or<br />
minimum of 1 x 32-kHz clock period) on the rising edge of the 32-kHz clock. After the TRB is<br />
reset, there is a one 32-kHz clock period where a new TRB setting will not be taken into<br />
account by the module. If the user programs the TVR and updates the TRB bit within this<br />
32-kHz clock period, the new TVR will not be loaded correctly into the TCR.<br />
32-kHz Clock<br />
TVR Register<br />
TRB Bit<br />
(CR Register)<br />
TCR Register<br />
Value A Value B<br />
Period for Which the TRB Bit<br />
is Permanently Reset to “0”<br />
No TRB Bit Write is Taken<br />
into Account<br />
Set Bit TRB in the CR Register<br />
Write Value_A in the TVR Register<br />
Value A Value B<br />
Figure 5. Latching of TVR Register Onto the TCR Register<br />
Workaround: The safe way to load a new value in the TCR is to poll the TRB bit. When the TRB is equal to<br />
‘0’ (signaling that the previous value has been loaded), the user has to wait for an additional<br />
one 32-kHz clock period before loading a new value in the TVR and setting the TRB bit to ‘1’.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
38
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.6 Microprocessor Unit I/O (MPUIO) Advisories<br />
Advisory<br />
MPUIO_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MPUIO INPUT_LATCH Register Latch is Disabled During TIPB Read Access to it<br />
Details: A continuous polling on the MPUIO INPUT_LATCH register does not work correctly.<br />
The MPUIO_INPUT_LATCH register is implemented with a latch that has the following<br />
functionality:<br />
• Enabled when there is no TIPB read access to the MPUIO INPUT_LATCH register. The<br />
register is directly updated by the MPUIO inputs.<br />
• Disabled when there is a TIPB read access to the MPUIO INPUT_LATCH register. The<br />
register holds its last value until the latch is enabled.<br />
Except in the MPUIO peripheral, the TIPB STROBE is not used to validate a TIPB read<br />
access. Consequently, as long as an MPUIO INPUT_LATCH register address is present on<br />
the TIPB bus, the corresponding MPUIO INPUT_LATCH register latch is selected and<br />
therefore disabled.<br />
Workaround: In order to avoid this behavior, during the MPUIO INPUT_LATCH register polling, a dummy<br />
TIPB access (the only condition is to do this access to another TIPB address) has to occur<br />
after the MPUIO INPUT_LATCH register read.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
39
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
MPUIO_2<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
MPUIO GPIO_INT is Not Generated<br />
Details: The reset of the MPUIO GPIO Interrupt is done asynchronously when a GPIO_INT register<br />
read occurs. The release of this reset is done synchronously with the 32 kHz clock to avoid<br />
any reset recovery time violation. A read of the GPIO_INT register while the 32k clock is low or<br />
transitioning can result in a deadlock of the interrupt state machine that causes all further<br />
interrupts on the subject MPUIO pin to be ignored.<br />
Workaround: After receiving the MPUIO GPIO_INT, the MPU should observe the 32-kHz system clock and<br />
then read the GPIO_INT register only after a ‘0’ to ‘1’ transition.<br />
There are different ways to detect a ‘0’ to ‘1’ transition on the 32-kHz system clock:<br />
• Polling the timer 32k counter until there is an increment (see the waveforms in Figure 6,<br />
which describe the procedure):<br />
32K<br />
INT<br />
Timer 32K<br />
Counter<br />
n n−1 n−2<br />
Polling of Timer 32K<br />
After Reception of the<br />
GPIO_INT and Wait for Increment<br />
Read GPIO_INT Register<br />
Figure 6. Read of GPIO Register While 32k Clock is Low<br />
• Loop-back the CLK32K_OUT output on one available MPUIO, GPIO or KB.R input, and<br />
polling the corresponding register.<br />
Note that the maximum delay inserted by this workaround, before the interrupt clears, is<br />
31 µSec (32K 1 clock period).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
40
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.7 Pulse-Width Tone (PWT) Advisories<br />
Advisory<br />
PWT_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Write Followed by Immediate Read not Supported on<br />
the PWT Peripheral<br />
Details: A write followed by an immediate read does not work on the ARM address space defined<br />
below. If a read occurs immediately after the write to the same address, then the read will not<br />
be the data that was written. The affected address spaces are:<br />
• PWT peripheral: Address space FFFB:6000 to End Address FFFB:67FF<br />
Workaround: When an immediate read is required after a write to any register in the above address space,<br />
make two consecutive writes to the same address prior to the read. Using this procedure<br />
ensures that the first write completes and the read data will be correct.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
41
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.8 Camera Interface Advisories<br />
Advisory<br />
CAM_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Interrupt Observability on Camera Port<br />
Details: The active-high arm_obs_int signal, which appears on the CAM.D[4] pin when the camera<br />
interface is in observability mode, is an inverted copy of the ITR register. The<br />
CONF_ARM_INT_SEL_R bits of the FUNC_MUX_CTRL_2 register are used to select the<br />
ARM level 2 interrupt to be observed.<br />
Workaround: There is no workaround. The interrupt observed is inactive-low and active-high.<br />
Advisory<br />
CAM_2<br />
Revision(s) Affected: B<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Camera Interface PEAK_COUNTER May be Wrong<br />
Details: The PEAK_COUNTER may generate a wrong value. This occurs because the clock to the<br />
register is gated, preventing the register update.<br />
Workaround: Software workaround: Make sure that MCLK_EN, bit 5 of the Clock Control Register<br />
(CTRLCLOCK), is set to 1.<br />
Advisory<br />
CAM_3<br />
Revision(s) Affected: B<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Camera Interface RAZ FIFO<br />
Details: The camera interface uses 4-byte-wide receive registers which latch the data from the data<br />
pins. When all four registers get valid data in them, the data is transferred into the FIFO.<br />
Unfortunately, if the user wants to begin a new frame of data, there is no way of manually<br />
resetting these registers to begin clean.<br />
Workaround: The only way to clear these registers is to allow the camera interface to be clocked with the<br />
LCLK signal while the VSYNC or HSYNC signals are inactive. Note: this solution will not<br />
work for designs which require the LCLK to be qualified (gated) to accommodate<br />
imagers that provide image decimation.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
42
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
CAM_4<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Shutdown of Camera Interface<br />
Details: The camera interface logic generates CAM.EXCLK frequencies based on either the 12-MHz<br />
system clock or by a 48-MHz clock provided by the DPLL in the ULPD peripheral. The 12-MHz<br />
clock is enabled by setting bit 5 (MCLK_EN) of the camera interface CTRLCLOCK register.<br />
The 48-MHz clock is enabled either by setting bit 6 (DPLL_EN) or by selecting a clock mode<br />
where bit 2 is 1 (this is the MSB of the FOSCMODE field).<br />
To enter Deep Sleep mode, it is necessary to eliminate the camera module requests for both<br />
the 12-MHz and 48-MHz clocks. However, to eliminate the 48-MHz clock request, the 12-MHz<br />
clock must be running (i.e., these two clocks cannot be stopped simultaneously).<br />
Workaround: To completely shut down the camera module, two separate writes to the CTRLCLOCK register<br />
is required.<br />
1. The first write must clear DPLL_EN (bit 6 = 0) and select an FOSCMODE where bit 2 is 0.<br />
During this same write, other register bits may also be changed, but MCLK_EN must still<br />
be 1. This keeps the 12-MHz clock running.<br />
2. The second write must clear MCLK_EN (bit 5 = 0).<br />
This workaround is not necessary if neither bit 6 nor bit 2 was enabled. There are no other<br />
restrictions on these consecutive writes (i.e., they can be consecutive operations).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
CAM_5<br />
Revision(s) Affected: B<br />
Wrong Interrupt Behavior for Camera Interface<br />
Details: When the word number in the FIFO reaches 128, the FIFO becomes full. The counter inside<br />
the FIFO considers this word number as a negative value, which causes the status bit (bit 5)<br />
to be cleared. The status bit (bit 5) indicates that the threshold value has been reached, and<br />
clearing it deactivates the interrupt line without any status read access.<br />
Workaround: Read the FIFO before it is full (128 words) or set the threshold field (in MODE register) at 126<br />
instead of 127.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
43
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.9 Infrared Data Adapter (IrDA) Advisories<br />
Advisory<br />
IRDA_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
NIRQ can Stay Low for a Few OCP Clock Cycles After an Interrupt is Serviced<br />
Details: This problem concerns the service of interrupts by reading from/writing to a register in the<br />
functional clock domain:<br />
After an access to the register is finished (falling edge of SCMDACCEPT), the NIRQ line can<br />
stay low for a few OCP clock cycles before it is deasserted. The actual delay depends on the<br />
clock ratio between the functional clock and the OCP clock.<br />
There may be potential problems with interrupts serviced twice when slower OCP Clocks are<br />
used, since some IRQ controllers are programmed to be level-sensitive.<br />
Workaround: Whenever an interrupt is processed:<br />
• In UART Mode, the user needs to read the Interrupt Identification Register (IIR). If the<br />
IT_Pending is cleared, no interrupt as defined by IT_type is actually pending and the<br />
software should immediately exit the interrupt handler.<br />
• In IrDA mode, the user needs to read the Interrupt Identification Register (IIR). If the<br />
returned value is 0x00, no interrupt is actually pending and the software should<br />
immediately exit the interrupt handler.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
44
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
IRDA_3<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
UART IrDA (MIR Mode) Sends an Additional Bit<br />
Details: In MIR mode, an additional pulse is added at the end of the transmit frame after the Stop Flag.<br />
The MIR protocol makes sure that this additional bit is not interpreted as a start bit of a<br />
subsequent transmit frame.<br />
Start Flags Frame Data CRC-16 Stop Flag<br />
Workaround: No workaround required.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
IRDA_4<br />
Revision(s) Affected: B<br />
When the UART is in Sleep Mode, a Write to THR Wakes Up the UART and Causes FIFO<br />
Synchronization Errors<br />
Details: When the UART enters sleep mode, a write to the transmit Holding Register (THR) is meant to<br />
wake up the device and to trigger a transmission of the packet written into the THR. However,<br />
the FIFO still thinks it is empty so no data gets transmitted. If a second byte is written into<br />
THR, the FIFO begins transmitting the first data but does not send the second one. If a third<br />
data is written into the THR, the FIFO will send the second data. Ultimately, the sequence is<br />
preserved and there is no loss of data.<br />
Workaround: The software should not use Sleep mode and should not configure Sleep mode in the Interrupt<br />
Enable Register (IER) (bit 4 of IER Register) in UART Mode.<br />
The software should not use Sleep mode and should not configure the Sleep mode in the<br />
Mode Definition Register1 (MDR1) (bit 3 of MDR1 Register) in IrDA Mode.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
45
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
IRDA_5<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Rx Overrun and TX_FIFO_FULL Bit Not Operational When FIFO is Disabled<br />
Details: If the user sets the FIFO depth to 1, bit 0 (FIFO_EN) of the FIFO Control Register (FCR) is<br />
cleared to 0, and the following occurs:<br />
• If an overrun condition occurs, it is not flagged.<br />
• TX_FIFO_FULL [bit 0 of Supplementary Status Register (SSR)] is always 0 whether or not<br />
the FIFO (1 byte in this case) is FULL.<br />
Workaround: Avoid overrun conditions by setting the FIFO depth to 64 (corresponding to 1 for FIFO_EN).<br />
For the case where an overrun condition is unlikely:<br />
• In UART mode, use TX_FIFO_E mapped as bit 5 of the Line Status Register (LSR) to<br />
detect whether or not a byte is present in the FIFO.<br />
• In IrDA mode, use THR_EMPTY mapped as bit 7 of the Line Status Register (LSR) to<br />
detect whether or not a byte is present in the FIFO.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
46
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.10 Universal Asynchronous Receiver/Transmitter (UART) Advisories<br />
Advisory<br />
UART_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Falling Edge on UART2.RX May Cause a Wake-up Event on <strong>OMAP5912</strong><br />
Details: A falling edge on UART2.RX may cause a wake-up event on <strong>OMAP5912</strong>. In order to prevent<br />
this wakeup, it is recommended that UART2.RX be set to high.<br />
Workaround: Use DIS_PERIPH_NREQ in ULPD SOFT_DISABLE_REQ_REG[3] to disable an unwanted<br />
request caused by a falling edge on UART2.RX (ZZG ball R9; ZDY ball U4). To enable or<br />
disable wake-up completely, set SYSC[2] to 1 or 0, respectively. This will enable or disable<br />
any method of wake-up.<br />
To enable or disable individual methods when SYSC[2] is 1, set the WER[0:6] register to 1 to<br />
enable the specific event and 0 to disable the specific event.<br />
The events are:<br />
• CTS activity bit 0<br />
• DSR activity<br />
• RI activity<br />
• DCD activity<br />
• RX/IRRX activity<br />
• RHR interrupt<br />
• Receive Line Status interrupt bit 6<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
47
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
UART_2<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Disabled UART’s FIFO Interrupts DMA Channel<br />
Details: When the UART is disabled (MDR1 = 0x7), its FIFO can interrupt the DMA channel upon<br />
setting register bits[2:0] in the Supplementary Control Register (SCR). This can cause<br />
problems if the SCR[2:0] bits are set prior to setting the trigger thresholds.<br />
Workaround: Set the DMA just before setting the Mode Select in the MDR1 register to avoid filling the FIFO<br />
in the UART.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
UART_4<br />
Revision(s) Affected: B<br />
Receive Overrun Not Reset on an Early Read of LSR<br />
Details: During receive overrun (LSR[1] = RX_OE), if a read of the Line Status Register (LSR) is done<br />
within one baud clock period after the overrun happens, the LSR is not cleared and the<br />
Overrun Interrupt remains asserted while any read of the LSR done after one baud clock<br />
period following the overrun event will clear the LSR and deassert the Overrun Interrupt.<br />
Workaround: During the interrupt sequence, one should loop for at least one baud clock period before<br />
reading the Line Status Register (LSR).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
48
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.11 Emulation Advisories<br />
Advisory<br />
EMU_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
32-bit Peripheral Register Access Through the Debugger Between Two 16-Bit Application<br />
Reads May Corrupt the On-going Application<br />
Details: Getting visibility of 32-bit peripheral registers from the debugger may corrupt the on-going<br />
application read sequence if the debugger access takes place between two 16-bit application<br />
reads.<br />
Workaround: There is no workaround. Ensure no debugger access is performed to such 32-bit peripheral<br />
registers between the 16-bit application accesses.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
EMU_2<br />
Revision(s) Affected: B<br />
GDD Does Not Support Execution Suspension in Case of CPU<br />
SUSPEND and FREE Bit = 0<br />
Details: The GDD continues running even if suspended by the processor for both FREE = 0 and<br />
FREE = 1.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
EMU_3<br />
Revision(s) Affected: B<br />
Emulation Access to IT_STATUS_REG Clears Bits<br />
Details: Debugger read access to IT_STATUS_REG (offset 0x14) clears status bits 2,1, and 0. The<br />
ULPD peripheral does not detect the initiator of the read access. This results in a debugger<br />
read access which impacts the register content in the same manner as in a normal application<br />
context.<br />
Workaround: Emulation reads must preserve the application state.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
49
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
EMU_4<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Default TDO State During Reset is Unpredictable<br />
Details: Some flip flops which control the enable of the TDO do not initialize properly if there is no<br />
rising edge on TRST. This can be an issue if several JTAG ports are daisy-chained in a design<br />
and TDO is left floating.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
50
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.12 Specially Optimized Screen Interface (SoSSI) Advisories<br />
Advisory<br />
SOSSI_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
SoSSI Match Interrupt<br />
Details: The SoSSI match output is not registered, which causes the MPU interrupt handler to capture<br />
glitches regardless of the interrupt sensitivity configuration.<br />
Workaround: There is no software workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
SOSSI_2<br />
Revision(s) Affected: B<br />
SoSSI CPriority<br />
Details: With the Double_FIFO feature, the SoSSI does allow two data transfers with independent<br />
parameters (display data type, byte count, and reordering) to be performed.<br />
If one FIFO pixel data transfer is on-going and the Double_FIFO feature is enabled, the<br />
command data transfer to another FIFO is allowed to override the pixel data transfer<br />
depending of the CPriority bit value in DIF003_INIT2 register.<br />
If the CPriority bit is set to 1 and command (A0 = 0) is sent during the pixel data transfer, the<br />
pixel data transfer should be aborted and the command should be sent to display. However,<br />
due to a problem with the SoSSI peripheral, the command will be sent but the pixel data<br />
transfer is not aborted. The rest of the pixel data is sent after the command. After the pixel<br />
data transfer is completed, the SoSSI will lock up.<br />
If the CPriority bit is set to 0 and command (A0 = 0) is sent during the pixel data transfer, the<br />
pixel data transfer should be completed and the command should be sent to display after that.<br />
However, due to a problem with SoSSI peripheral, the command will be sent immediately and<br />
after which, undefined amount 0x00 data will be sent.<br />
Workaround: Software has to ensure that the pixel data transfer in one FIFO is completed before initiating<br />
command transfer to another FIFO.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
51
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.13 Compact Camera Port (CCP) Advisories<br />
Advisory<br />
CCP_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Compact Camera Port Software Reset Does Not Reset Attn-Signal Registers<br />
Details: The Compact Camera Port (CCP) includes an Attn status output signal,which is used as a<br />
DMA request. If the Attn signal is enabled, it gets asserted when the CCP FIFO receives a 4 x<br />
32-bit of data. The Attn signal stays active until the 4 x 32-bit data is read from the FIFO. If the<br />
FIFO after reads contain another 4 x 32-bit block of data, the Attn signal gets asserted again.<br />
When CCP software reset (partial reset, not intended to reset the whole CCP) is applied, the<br />
registers defining Attn-signal state should be reset, but they are not.<br />
If software reset is applied when Attn signal is active, it will stay active after software reset is<br />
completed. As a result, it is possible for the buffer to be configured as an input and ignore the<br />
gating event.<br />
Workaround: The software needs to read the CCP FIFO four times after every software reset. This will<br />
disable the Attn signal. Even if Attn signal is not active, this can be done without disturbing the<br />
functionality of the CCP.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
CCP_2<br />
Revision(s) Affected: B<br />
CCP DMA Does Not Operate as Expected<br />
Details: The CCP peripheral has an internal status output signal, which in <strong>OMAP5912</strong>, is used as a<br />
DMA request. This signal should be asserted when the CCP internal FIFO has received<br />
4 x 32-bit data. The signal stays active until all 4 x 32-bit data has been read from the FIFO.<br />
However, in <strong>OMAP5912</strong>, a false status signal comes after the final (fourth word) read if<br />
3 words remain in the CCP FIFO. The false status does not occur when 0, 1, or 2 words<br />
remain in the CCP FIFO after the fourth word is read.<br />
This false behavior can be hidden, if new data from the camera arrives before the DMA reads<br />
the fourth word. If new data has not arrived, then the DMA will read 3 words and 1 word of<br />
zeros.<br />
Workaround(s): 1. If the data format does not contain zero-words, then corrupt data can be removed by<br />
software if the reduced bandwidth is acceptable.<br />
2. Implement a check of data size between received data from the camera and data written<br />
to memory. If the sizes do not match, then the false status has occurred and the picture<br />
has become corrupted.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
52
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.14 32-kHz Oscillator Advisories<br />
Advisory<br />
OSC_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
32-kHz Oscillator Does Not Power Down in Deep Sleep Mode<br />
Details: The 32-kHz oscillator is always powered up regardless of the Reset_Mode value. In particular,<br />
if an external 32-kHz clock is provided to <strong>OMAP5912</strong>, the power down of the oscillator is not<br />
configured so that active circuitry in the oscillator would be cut off. This behavior is noticeable<br />
in deep sleep mode as the oscillator current consumption is in the range of 5 µA. See<br />
Figure 7.<br />
PWRDN<br />
VOLTAGE<br />
ON XI<br />
VOLTAGE<br />
ON XO<br />
APPROXIMATE<br />
WORST-CASE<br />
CURRENT<br />
MAGNITUDE<br />
ON XI<br />
APPROXIMATE<br />
WORST-CASE<br />
CURRENT<br />
MAGNITUDE<br />
ON XO<br />
TOTAL<br />
CURRENT<br />
CONSUMPTION<br />
L VSS VSS 50 nA 5 µA 5 µA H<br />
L VDD VSS 50 nA 5 µA 5 µA H<br />
L VSS VDD 50 nA 100 µA 100 µA L<br />
L VDD VDD 50 nA 100 µA 100 µA L<br />
H VSS VSS 1 nA 1 nA 1 nA L<br />
H VDD VSS 1 nA 1 nA 2 nA H<br />
H VSS VDD 1 nA 100 µA 100 µA L<br />
H VDD VDD 1 nA 100 µA 100 µA H<br />
Figure 7. Oscillator Current Consumption<br />
Workaround: Make sure that if the 32-kHz oscillator is not required, the OSC32K_PWRDN bit is set to one<br />
in the RTC Oscillator Register (RTC_OSC_REG).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Y<br />
53
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
OSC_2<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
32-kHz Oscillator Does Not Work Properly in <strong>OMAP5912</strong><br />
Details: Coupling between the CLK32K_OUT (ZZG ball R13; ZDY ball U12) signal and oscillator XI<br />
creates a parasitic oscillation mode, preventing the oscillator from working properly.<br />
Workaround: Connect an external CMOS 32-kHz clock onto CLK32K_IN (ZZG ball P13; ZDY ball T11)<br />
instead of using the on-chip 32-kHz oscillator.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
54
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.15 Serial Peripheral Interface (SPI) Advisories<br />
Advisory<br />
SPI_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
SPI Slave Not Supported on SPIF.DOUT on ZZG Ball R18 (ZDY Ball N17)<br />
Details: The 3-state control for SPIF.DOUT on ZZG ball R18 (ZDY ball N17) (Mode 011) is tied<br />
active-low when the SPIF.DOUT is chosen in the pin-multiplexing. In addition, the input buffer<br />
on ZZG ball R18 (ZDY ball N17) is not routed to the SPI, which prevents slave operation.<br />
Workaround: Possible workaround for the SPI in Slave mode is to use SPIF.DOUT on ZZG ball W21 (ZDY<br />
ball R15).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
SPI_2<br />
Revision(s) Affected: B<br />
SPI Not Able to Receive the First Data While Waking up From Sleep Mode<br />
Details: While waking up from sleep mode by a data sent to the SPI (GPIO wake-up), the functional<br />
clock of the SPI is available far after the end of the data transmission, resulting in the data not<br />
being latched by the SPI.<br />
Workaround: Resend the data after the functional clock is available at the SPI module.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
SPI_3<br />
Revision(s) Affected: B<br />
SPI Outputs are not Controlled Correctly<br />
Details: The SPI output buffer’s direction (GZ) is connected to the SPI’s output MODE [or inv(MODE)]<br />
for the SPIF.DIN pin. This signal is static and it defines master/slave operations in the<br />
<strong>OMAP5912</strong> SPI peripheral. Because this signal is static and is directly connected to GZ’s SPI<br />
outputs, the SPI peripheral will not release the bus correctly. Multi-point connections on the<br />
SPI peripheral are then limited.<br />
The correction is to use the dynamic signal (TSPDOEN) provided by the SPI module as<br />
direction control for the SPI output buffer. TSPDOEN places the output buffer in high<br />
impedance while no shifting operation is in progress.<br />
Workaround: If <strong>OMAP5912</strong>’s SPI peripheral is to act as a master, make sure there are no other master SPIs<br />
in the system in order to avoid bus contentions.<br />
TI does intend to correct this functionality on a future revision of <strong>OMAP5912</strong>.<br />
55
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
SPI_4<br />
Revision(s) Affected: B<br />
Details: The SPI peripheral does not support 8-bit accesses.<br />
SPRZ209C<br />
SPI Module Does Not Support 8-Bit Accesses<br />
Workaround: If 8 bits of data must be transferred, the data must be packed in a16-bit structure.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
56
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.16 Ultra Low-Power Device (ULPD) Advisories<br />
Advisory<br />
ULPD_1<br />
Revision(s) Affected: B<br />
Details: ULPD has the following reset scheme:<br />
SPRZ209C<br />
ULPD Analog Cell Configuration are Reset After a MPU Peripheral Reset<br />
• Internal Registers are reset by ULPD power-up reset.<br />
• ARM registers are reset by ULPD MPU Peripheral Reset.<br />
As the ULPD is responsible for OMAP3.2 reset generation (including the MPU peripheral<br />
reset), if the MPU warm reset or any of the watchdog resets (32 kHz or secure watchdog) is<br />
active, the MPU peripheral reset is activated and the analog set-up time registers are reset.<br />
Therefore, when the FSM goes out of Deep Sleep, the set-up counters are loaded with the<br />
reset value of the analog set-up time registers instead of the optimized value previously<br />
programmed by the user, this causes wake-up latency penalty.<br />
Note that PWR_CTRL_REG[12] (DSP isolation control) and RESET_STATUS[3:0] are not<br />
affected by this behavior.<br />
Workaround: Software should account for the analog set-up time cell latencies.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
57
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.17 Multichannel Serial Interface (MCSI) Advisories<br />
Advisory<br />
MCSI_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Late Generation of TX DMA Request in the MCSI<br />
Details: Multiple DSP-based DMA mode transmits and receives on the MCSI peripherals do not work<br />
properly. The MCSI peripheral is re-transmitting the last word of data that it had transmitted in<br />
the previous DMA Frame.<br />
On the first DMA frame that the MCSI transmits, the MCSI peripheral generates a tx_dma_req<br />
just prior to asserting the frame sync signal. It then generates the proper binary stream.<br />
On the second and subsequent DMA frames transmitted, the MCSI does not generate a<br />
tx_dma_req prior to asserting the frame sync signal and the last data from the previous DMA<br />
frame is re-transmitted by the MCSI. Then, a tx_dma_req is asserted and the character that<br />
was supposed to be first transmitted is loaded and shifted through the MCSI.<br />
Subsequently, the first dma request results in the transmission of the second character by the<br />
MCSI. The proper number of tx DMA requests is generated. When the last DMA request is<br />
generated, the MCSI loads the transmit buffer but does not transmit this character until the<br />
next DMA frame when the same incorrect sequence of data retrieval and transmission by the<br />
MCSI TX DMA process is repeated.<br />
Workaround: Write the first data under DSP CPU control to the TX register before the DMA transfer. This is<br />
to ensure that the correct data is sent. Next, the DMA must be programmed to send the<br />
remaining elements 2 through N after that.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
58
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.18 Multichannel Buffered Serial Port (McBSP) Advisories<br />
Advisory<br />
MCBSP_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
McBSP3 3-Pin Operation Versus 4-Pin Operation Configuration<br />
Details: Two <strong>OMAP5912</strong> configuration bits in Module Configuration Register 0 (MOD_CONF_CTRL_0)<br />
are used for setting up McBSP3, as shown below:<br />
• MOD_CONF_CTRL_0[28] should control the McBSP3 FSYNC output mode (McBSP3 in<br />
3-pin or 4-pin mode)<br />
− 3-pin mode: FXOUT is connected to FSRIN. FSXIN is tied low.<br />
− 4-pin mode: FSRIN = FSXIN is connected to FSXOUT high-impedance output buffer.<br />
• MOD_CONF_CTRL_0[19] should control the source for McBSP3 CLKS (either DSPXOR<br />
or DSPPER)<br />
In <strong>OMAP5912</strong>, MOD_CONF_CTRL_0[28] does not work and MOD_CONF_CTRL_0[19]<br />
controls both McBSP3 modes and OCP input clock (McBSP interface clock).<br />
• MOD_CONF_CTRL_0[19] = 0:<br />
− McBSP3 is in 3-pin mode<br />
− Interface clock: DSPXOR<br />
• MOD_CONF_CTRL_0[19] = 1:<br />
− McBSP3 is in 4-pin mode<br />
− Interface clock: DSPPER<br />
Note that the access time to the peripheral will change depending on 3-pin or 4-pin usage.<br />
If McBSP3 is configured with CLKSM = 1 and CLKME = 0, the input clock of the sample rate<br />
generator (SRG) will be either the DSPXOR_CK (system clock) or DSPPER_CK<br />
(programmable) depending on MOD_CONF_CTRL_0[19]. This means the dividers in the SRG<br />
must be configured differently to achieve the same frequency in 3-pin versus 4-pin mode.<br />
Workaround: When configuring the McBSP3 in 3-pin or 4-pin mode, make sure the correct access time to<br />
the peripheral is accounted for.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
59
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
6.19 Dual-Mode Timers Advisories<br />
Advisory<br />
DM_TIMER_1<br />
Revision(s) Affected: All revisions<br />
SPRZ209C<br />
Dual-Mode Timer Peripherals May Not Detect Incoming Events<br />
Details: Due to internal metastability issues, the dual-mode timer peripherals, when used in<br />
event-capture mode, may not detect incoming events.<br />
Workaround: There is no workaround.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
60
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
7 <strong>OMAP5912</strong> Device/System Level Advisories<br />
7.1 System Advisories<br />
Advisory<br />
SYS_1<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Pulldown on the UWIRE.SDI Pin Needs to be Disabled by Software to Save Power<br />
Details: On the UWIRE.SDI pin, there is a pulldown active by default. The inactive level of the signal is<br />
high. Therefore, the pulldown needs to be disabled in software in order to save power.<br />
Workaround: Write 0x0000EAEFh to the COMP_MODE_CTRL_0 register (base address: FFFE:1000 +<br />
offset 0x0C).<br />
Set bit 18 (CONF_PDEN_WIRE_SDI_R) of the PULL_DWN_CTRL_1 register (offset:<br />
FFFE:1000 + offset 0x44) to 1.<br />
TI does not plan to correct this functionality on all <strong>OMAP5912</strong> revisions.<br />
Advisory<br />
SYS_2<br />
Revision(s) Affected: B<br />
When Disabled, the OMAP Peripheral Clock Prevents the <strong>OMAP5912</strong> From Going Into<br />
Deep Sleep<br />
Details: If the peripheral clock is disabled, <strong>OMAP5912</strong> cannot go into deep sleep when executing the<br />
Arm Idle instruction because the TC1_IDLEACK do not rise since it is synchronous to the<br />
peripheral clock. The Idle request is not acknowledged.<br />
If the peripheral clock is enabled prior to the execution of the Arm Idle instruction, the chip<br />
goes correctly in deep sleep.<br />
Workaround: If the peripheral clock is enabled (via EN_PERCK of ARM_IDLECT2) prior to the execution of<br />
the Arm Idle instruction, the chip goes correctly in deep sleep.<br />
TI does not plan to correct this functionality on all <strong>OMAP5912</strong> revisions.<br />
61
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
SYS_3<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
<strong>OMAP5912</strong> Gated Outputs Forced to 0<br />
Details: Some outputs can be forced to 0 in the case of battery failure or external event (falling edge)<br />
on GPIO9 or MPUIO3. The outputs that exhibit this feature are listed in the <strong>OMAP5912</strong><br />
<strong>Applications</strong> <strong>Processor</strong> Data Manual (literature number SPRS231) and are classified as either<br />
“gated1” or “gated2” outputs. As a gating is defined to tie pins to the fixed value 0 regardless<br />
of the mode for which they are configured, gating also controls the 3-state buffer output<br />
enable. As a result, the buffer can be configured as an input, which causes it to ignore the<br />
gating event.<br />
Workaround: When configuring <strong>OMAP5912</strong> inputs/outputs, the user should make sure that the I/O which<br />
should be forced to 0 in case of battery failure or event on GPIO9/MPUIO3 has been<br />
configured before as output.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
Advisory<br />
SYS_4<br />
Revision(s) Affected: B<br />
If BVLZ is Not Configured, the Corresponding Interrupt Must be Masked<br />
Details: On <strong>OMAP5912</strong>, the UART3.CTS, UART1.DSR, and the MMC/SDIO2’s MMC.DATDIR1<br />
signals have been multiplexed with BVLZ (battery low-level external interrupt).<br />
If BVLZ is not used, the user has to make sure that the corresponding interrupt mask is set<br />
(MPU Level 1 Interrupt Mapping, IRQ_3) and that bit 3 of the ULPD’s POWER_CTRL_REG,<br />
which controls RST_HOST_OUT of the ULPD, is cleared to 0.<br />
Workaround: Mask SCV3OMAP3/PIIRQINPUTN 3 and clear bit 3 of the ULPD’s POWER_CTRL_REG to 0<br />
(default value at reset is 1).<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
62
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
Advisory<br />
SYS_5<br />
Revision(s) Affected: B<br />
SPRZ209C<br />
Configuration Registers FUNC_MUX_CTRL_10[8:3] and FUNC_MUX_CTRL_9[11:9]<br />
Reset Values Do Not Reflect M8, L3, AA20 Configuration in Reset Mode 1<br />
Details: The following changes have been implemented in <strong>OMAP5912</strong>:<br />
• Reset values in reset_mode1 of ZZG balls M8, L3, AA20 (ZDY balls K2, J1, and N12,<br />
respectively) have been changed inside the configuration block.<br />
Default muxing mode is now 7 (0111 in binary) for the 3 balls below:<br />
• ZZG ball M8 (ZDY ball K2): configured as GPIO_60 instead of NFBE_1<br />
• ZZG ball L3 (ZDY ball J1): configured as GPIO_59 instead of NFBE_0<br />
• ZZG ball AA20 (ZDY ball N12): configured as GPIO_41 instead of NRESETOUT<br />
This is not reflected inside FUNC_MUX_CTRL_10[8:3] and FUNC_MUX_CTRL_9 [11:9] (with<br />
reset values of 000000 and 000, respectively, instead of 111111 and 111).<br />
Workaround: Special care must be taken while reprogramming the pads’ configuration when using reset<br />
mode 1. In reset mode 1, FUNC_MUX_CTRL_10[8:3] needs to be programmed to 111111 and<br />
FUNC_MUX_CTRL_9 [11:9] to 111 in order to keep their intended reset value before new pad<br />
configurations.<br />
TI does not intend to correct this functionality on future revisions of <strong>OMAP5912</strong>.<br />
63
<strong>OMAP5912</strong> <strong>Silicon</strong> <strong>Errata</strong><br />
8 Documentation Support<br />
For device-specific data sheets and related documentation, visit the TI web site at: http://www.ti.com<br />
For further information regarding the <strong>OMAP5912</strong>, please refer to:<br />
• <strong>OMAP5912</strong> <strong>Applications</strong> <strong>Processor</strong> Data Manual (literature number SPRS231)<br />
For additional information, see the latest versions of:<br />
• TMS320C55x DSP Functional Overview (literature number SPRU312)<br />
• TMS320C55x DSP CPU Reference Guide (literature number SPRU371)<br />
• TMS320C55x DSP Mnemonic Instruction Set Reference Guide (literature number SPRU374)<br />
• TMS320C55x DSP Algebraic Instruction Set Reference Guide (literature number SPRU375)<br />
• TMS320C55x DSP CPU Programmer’s Reference Supplement (literature number SPRU652)<br />
SPRZ209C<br />
64
IMPORTANT NOTICE<br />
Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications,<br />
enhancements, improvements, and other changes to its products and services at any time and to discontinue<br />
any product or service without notice. Customers should obtain the latest relevant information before placing<br />
orders and should verify that such information is current and complete. All products are sold subject to TI’s terms<br />
and conditions of sale supplied at the time of order acknowledgment.<br />
TI warrants performance of its hardware products to the specifications applicable at the time of sale in<br />
accordance with TI’s standard warranty. Testing and other quality control techniques are used to the extent TI<br />
deems necessary to support this warranty. Except where mandated by government requirements, testing of all<br />
parameters of each product is not necessarily performed.<br />
TI assumes no liability for applications assistance or customer product design. Customers are responsible for<br />
their products and applications using TI components. To minimize the risks associated with customer products<br />
and applications, customers should provide adequate design and operating safeguards.<br />
TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right,<br />
copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process<br />
in which TI products or services are used. Information published by TI regarding third-party products or services<br />
does not constitute a license from TI to use such products or services or a warranty or endorsement thereof.<br />
Use of such information may require a license from a third party under the patents or other intellectual property<br />
of the third party, or a license from TI under the patents or other intellectual property of TI.<br />
Reproduction of information in TI data books or data sheets is permissible only if reproduction is without<br />
alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction<br />
of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for<br />
such altered documentation.<br />
Resale of TI products or services with statements different from or beyond the parameters stated by TI for that<br />
product or service voids all express and any implied warranties for the associated TI product or service and<br />
is an unfair and deceptive business practice. TI is not responsible or liable for any such statements.<br />
Following are URLs where you can obtain information on other Texas Instruments products and application<br />
solutions:<br />
Products <strong>Applications</strong><br />
Amplifiers amplifier.ti.com Audio www.ti.com/audio<br />
Data Converters dataconverter.ti.com Automotive www.ti.com/automotive<br />
DSP dsp.ti.com Broadband www.ti.com/broadband<br />
Interface interface.ti.com Digital Control www.ti.com/digitalcontrol<br />
Logic logic.ti.com Military www.ti.com/military<br />
Power Mgmt power.ti.com Optical Networking www.ti.com/opticalnetwork<br />
Microcontrollers microcontroller.ti.com Security www.ti.com/security<br />
Telephony www.ti.com/telephony<br />
Video & Imaging www.ti.com/video<br />
Wireless www.ti.com/wireless<br />
Mailing Address: Texas Instruments<br />
Post Office Box 655303 Dallas, Texas 75265<br />
Copyright © 2004, Texas Instruments Incorporated