| PROBLEM 4.0.1 Cache bug Conditions
necessary to cause problem on the 320C30:
If all of the following conditions are true, there is a
possibility that a multi-cycle program fetch will be
truncated to one cycle. If any one of these conditions is
not met, there will not be a problem.
- The cache is enabled.
- The program fetches are multi-cycle fetches
from the primary port. Single cycle program
fetches are not a problem.
- The hold pin is used to tri-state the primary
port.
- The instruction after a branch type
instruction (branch, trap, call, return, RPTB,
RPTS) may be truncated to one cycle. Delayed
branches are not a problem.
- Either of the 2 instructions before a branch
does a multi-cycle fetch from the expansion port,
or a store to a peripheral or the expansion port
and the expansion port is not ready. Or the
instruction before the branch does a fetch from a
peripheral or the expansion port and the
expansion port is not ready.
- The timing of the hold pin going low, the
timing of the hold pin going high, and the timing
of the expansion port becoming ready, all have to
happen at specific times to cause this problem.
These timing may be hard to control.
Fixes for the above problem.
- If condition 5 occurs insert nop's or another
type instruction to avoid this problem.
- Or use single cycle memory for program
fetches.
The C31 does not have a problem since it does not
have a expansion port.
Device:
TMS320C32
The following problems exist
in the TMX320C32 rev.1x 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 (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.)
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.
|
|
