 TMS320C32 Silicon
Errata
Rev 1.x Silicon (Document Revision 1.9)
Last Modified: 6/15/97
The following problems exist in the TMS320C32 silicon
(all speeds included) known by TI as of the date given
above. Each problem is described and an appropriate work
around is presented. In addition, the revision in which
the problem is fixed or will be fixed is included.
Production release for the TMS320C32 is revision 1.2
silicon.
TI creates a new document revision when a new silicon
bug is discovered. However, TI will NOT update previously
edited files. For example, if you have silicon rev 2.2,
you should take a look at the last document revision for
2.x silicon AND to the latest document revisions for
newer silicon (i.e. 3.x, 4.x, ... document revisions)
because unless specifically specified, old silicon has
the bugs that have been discovered in newer silicon.
Device:
TMX Bug listing
- DMA priority bits swapping error
- Problem fixed
in silicon 1.1
- The bit 12 &
13 (DMA PRI) of the DMA control register
has been swapped. See the table below for
the functionality description:
Correct mode | | Rev 1.0 silicon mode
Bit 13 - 12 | Function Description | Bit 13 - 12
-------------+------------------------------------+-----------------------
0 0 | CPU has higher priority over DMA | 0 0
0 1 | CPU/DMA rotate priority | 1 0
1 0 | Reserved | 0 1
1 1 | DMA has higher priority over CPU | 1 1
-------------+------------------------------------+-----------------------
- 8-Bit data sign-extended mode
error
- Problem fixed
in silicon 1.1
- The sign bit of
the 8 bit data does not have enough power
to drive the internal data low. The
problem is occuring on upper 16 bit data
bus and 8-bit positive sign-extended data
only. The example below shows the
problem:
The memory configuration is 32-bit memory width and 8-bit data type.
If the data is 012345678h in the 32 bit memory, in sign-extended mode, the
data will be as described in the following four situations:
Correct Error
condition condition
Lowest LSBs 012345678h ---> 00000078h (no problem)
2nd Byte 012345678h ---> 00000056h (no problem)
3rd Byte 012345678h ---> 00000034h or FFFFFFB4h
4th Byte 012345678h ---> FFFFFF92h (always problem)
- 8-Bit data sign-extended mode
error
- Problem fixed
in silicon 1.2
- The sign bit of
the 8 bit data does not have enough power
to drive the internal data low. The
problem is occuring on upper 16 bit data
bus and 8-bit positive sign-extended data
only. The example below shows the
problem:
The memory configuration is 32-bit memory width and 8-bit data type.
If the data is 012345678h in the 32 bit memory, in sign-extended mode, the
data will be as described in the following four situations:
Correct Error
condition condition
Lowest LSBs 012345678h ---> 00000078h (no problem)
2nd Byte 012345678h ---> 00000056h (no problem)
3rd Byte 012345678h ---> 00000034h or FFFFFFB4h
4th Byte 012345678h ---> FFFFFF92h (always problem)
- Address pin glitches
- Problem fixed
in silicon 1.2
- Address pins
generate glitches/pulses whenever the
address changes on the rising edge of H1.
This only occurs at the end of every
external port write cycle:
(write-write and write-read).
^ ^
| |
glitch glitch
This might
impact the address ready timing.
- Address pin glitches
- Problem fixed
in silicon 1.2
- The data bus does
not tristate if HOLD is asserted just
before a store to STRB0, STRB1 or IOSTRB
cycle. In other words the data bus may be
driven by the C32 even when the HOLDA
signal is asserted.
- IOSTRB cycles may be missed
after HOLDA
- Problem fixed
in silicon 1.2
- If HOLD is
asserted just before IOSTRB write cycle,
the IOSTRB signal may never go low at the
completion of HOLD condition.
- TMX Parameter relaxation
- Problem fixed
in silicon 1.2
- The following
relaxations were made for testing the
TMX320C32 parts revision 1.1. These
relaxations do not apply silicon revision
1.2.
- 50MHz:
- Data
Bus setup time (parameter
15) moved from 10ns to
12ns.
- Data
Bus High Level Input
Voltage (VIH) moved from
2.0v to 3.0v.
- Address
Bus valid after a write
(parameter 22) moved from
9ns to 19ns.
- MCBL/MP_
Low Level Input Voltage
(VIL) moved from 0.8v to
0.2v.
- 40MHz:
- Data
Bus High Level Input
Voltage (VIH) moved from
2.0v to 3.0v.
- Address
Bus valid after a write
(parameter 22) moved from
11ns to 21ns.
- MCBL/MP_
Low Level Input Voltage
(VIL) moved from 0.8v to
0.2v.
Device:
TMS Bug listing
- Back-to-Back DMA transfers
between two DMA channels to/from external memory
- Problem fixed
in silicon 2.0
- When one DMA
channel READS a value from external
memory and immediately after the other
DMA channel READS or WRITES a value from
or to the internal memory (or memory map
registers), then, the DMA channels may
transfer corrupted data. The problem may
occur in the following sequences:
- cycle 1 -
DMA0 reads from external memory
- cycle 2 -
internal register cycle
- cycle 3 -
DMA1 writes to internal memory
Value read by
DMA0 is corrupted with value written by
DMA1.
or
- cycle 1 -
DMA0 reads from external memory
- cycle 2 -
internal register cycle
- cycle 3 -
DMA1 reads from internal memory
Value read by
DMA0 is corrupted with value read by
DMA1.
This problem
does NOT occur if the write from one
channel does NOT happen immediately after
the read from the other channel. For
example, the DMAs transfer data
succesfully in the following sequence:
- cycle 1 -
DMA0 reads from external memory
- cycle 2 -
internal register cycle
- cycle 3 -
CPU fetches instruction
- cycle 4 -
DMA1 writes to internal memory
To avoid this
problem prevent two different DMA
channels from having a back-to-back read
external followed by a write internal
operation or a back-to-back read external
followed by a read internal. If the DMAs
are synchronized to interrupts, generate
a CPU interrupt that triggers the DMA by
writing to the interrupt flag instead of
triggering the DMA directly. This would
add a few cycles between DMA operations.
- Back-to-Back IOSTRB read and
STRB0 or STRB1 read when these are not configured
for 32-bit data and 32-bit wide memory
- Problem fixed in
silicon 2.0
- The 'C32 CPU or
DMA may READ incorrect data from external
IOSTRB memory if it is immediately
followed by an external STRB0 or STRB1
memory READ when the external memory bus
is NOT configured to 32 bit data and 32
bit wide memory. The problem may occur in
the following sequences:
- cycle 1 -
DMA0 reads from external memory
(IOSTRB space)
- cycle 2 -
CPU reads data from external
memory (STRB1 space) that is
configured for 16 bit data in 32
bit wide memory
or
- cycle 1 -
CPU reads from external memory
(IOSTRB space)
- cycle 2 -
CPU reads data from external
memory (STRB0 space) that is
configured for 32 bit data in 16
bit wide memory
The problem
does NOT occur on WRITES nor on
READ-WRITE operation. The IOSTRB data may
be corrupted, while the STRB0 or STRB1
data is read correctly. To avoid this
problem, prevent back-to-back reads from
IOSTRB and STRB0 or STRB1.
- Boot loading from and into the
same memory strobe with different memory widths
- Problem fixed in
silicon 2.0
- If the boot source
resides in the same strobe (STRB0 or
STRB1) as the destination of the boot
source and if this write to this
destiantion address requires a multicycle
write (due to 8-bit or 16-bit wide memory
or wait states), the data might NOT be
transfered correctly.
Due to the configurable
nature of the C32 memory interface, the
boot loader constantly sets the STRBx
Control Register whenever it reads or
writes to external memory, as in the
following code:
*====================================================================*
* Transfer one block of data or program
*====================================================================*
RPTB loop4
CALLU AR1 ; read data/prg
STI R4,*AR4 ; set write strobe
NOP ; pipeline
loop4 STI R1,*AR5++ ; write data/prg <= Area of
|| STI R2,*AR2 ; set read strobe <= interest
BU block ;*******; process next block
The STI || STI
instruction writes out the boot load
value to memory and at the same time sets
the STRBx Control Register memory width
for the next read (32 bits wide).
However, if this write is a multicycle
write (due to 8-bit or 16-bit wide memory
or wait states) and at the same time the
STRBx Control Register (of this same STRB
were the write occurs) is changed, the
data might NOT be transfered correctly.
This is due to a constraint in that the
STRB Control Registers are statically
accessed by the Memory Port during every
cycle of the write operation. Hence, if
the STRB Control Register is changed
during or on the previous cycle of a
write, the data might NOT be transferred
correctly. Since the 'C32 is boot
loading, the write operation can have
innumerable numbers of cycles due to
external hardware ready generation. To
mimize this problem the setting of the
STRB Control Register was moved just
prior to the next read operation. This
gives the greatest amount of time for the
write operation.
The new boot
loader new routines are:
*====================================================================*
* Transfer one block of data or program
*====================================================================*
RPTB loop4
CALLU AR1 ; read data/prg
STI R4,*AR4 ; set write strobe
NOP ; pipeline
loop4 STI R1,*AR5++ ; write data/prg <= Removed STRB setting
BU block ;*******; process next block
;;;
*====================================================================*
* Read next word from boot table
*====================================================================*
read_m TSTB 2,IOF ; handshake mode enabled ?
STI R2,*AR2 ; set read strobe <==== NEW
BNZ loop5 ; yes, jump over
LDI *AR3++,R6 ; no, just read memory & return
RETSU
Note that this
problem does not occur when boot loading
from one strobe into a different strobe
(i.e. STRB0 -> STRB1, STRB1 ->
STRB0, IOSTRB -> STRB0, etc.)
- IOSTRB access followed by a
IOSTRB read back-to-back with and on-chip access
- Problem fixed
in silicon 2.3
- When an IOSTRB
access is later followed (not necessarily
back-to-back) with another IOSTRB read
with an on-chip access, then the IOSTRB
read will read data in the following
half-cycle after IOSTRB terminated. In
other words, IOSTRB performs a two and a
half cycle read instead of the expected
two cycle read. Due to capacitive
holding, this problem might not be
experienced unless the data lines were
pulled high and the device was running
very slow (LOPOWER mode or slow CLKIN).
Device:
TMS Additional Features
- 'C32 Silicon version 2.0 or
greater has all the parallel instructions
augmented with new operand combinations.
Device:
TMS Data Sheet Corrections
- LOPOWER mode CLKIN to H1/H3
delay
- The maximum delay
from CLKIN to H1/H3 in low power mode
(LOPOWER) may be about 3-4 ns longer.
This is not specified in the data sheet.
- LOPOWER mode CLKIN to H1/H3
delayInterrupt setup time in IDLE2
- The Interrupt
setup time is 6-7 ns longer in IDLE2
mode. This is not specified in the data
sheet.
- Corrected Reset Timing
- The reset timing
in the data sheet dated prior to May 1995
is incorrect. Corrected Reset timing is
provided in the TMS320C32 Data Sheet
Errata or Data Sheets dated after August
1995
- Corrected Reset Timing Address
Bus Vol parameter relaxation
- The Low Level
Output Voltage (Vol) maximun for the
Address Bus (A0-A23) is 0.7 v
- CLKIN low min pulse width
(parameter 3) relaxation
- The CLKIN low
minimum pulse width high [parameter 3 -
tw(CIH)] for C32-50 MHz is 8 ns.
- CLKIN low max pulse width
(parameter 3) relaxation
- The CLKIN low
maximum pulse width high [parameter 3 -
tw(CIH)] for C32-40 and C32-50 operating
at 3.3 MHz is 10 ns.
- Note added in parameter 95, hold
time for general purpose output to input after H1
high
- Add note to
Parameter 95 [th(H1H)] - Hold time for
peripheral pin changing from
general-purpose output to input mode
after H1 is high that states it is
assured by design but not tested.
- Deletion of enable time /SHZ
high to all pins active, parameter 105
- Parameter 105
[ten(SHZ)] - Enable time for all output
and I/O pins once /SHZ signal goes high
has been deleted.
|