RMP
TMS320C40 SILICON ERRATA
Rev 3.x Silicon (Document Revision 3.2)
Last Modified:01/23/95
The following problems exist in the 320C40 rev.3x 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.
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.
New in this document: Problem 3.0.10
-------------------- Problem 3.0.11
Bug listing: Fixed Silicon.rev
----------- that fixed it
(or will be)
(Note 1)
PROBLEM 3.0.1 Bootloader bug yes 3.1
PROBLEM 3.0.3 RETIUD instruction yes 3.3
PROBLEM 3.0.4 Cache Update Logic yes 3.3
PROBLEM 3.0.9 DMA interrupts during autoinitization no 3.4
PROBLEM 3.0.10 BK register ready pipeline conflict no 3.4
PROBLEM 3.0.11 Cache logic no 3.4
Note 1: Silicon bug present in any device with silicon revision lower than
this silicon version. It will not be present in any silicon revision
number greater than or equal to this silicon revision.
============================================================================
PROBLEM 3.0.1 Boot loader bug
The following lot numbers had problems with boot loader. However, it will nor
produce erratic results (it will not boot-up at all)
2064070
2064071
2151191
2152265
2160979
2196891
===============================================================================
PROBLEM 3.0.3 RETIUD instruction
A problem occurs when a register ready conflict occurs the cycle after a
delayed RETID. The RETID executes but the stack pointer is not decremented.
WORK ARROUND:
Eliminating the register conflict that occurs the cycle after the RETID
instruction, eliminates the problem. These sequences need to be changed:
These sequences need to be changed | Fix Fix
---------------------------------------------------------------------------
RETIUD | RETIUD RETIUD
STI ARn,*AR1 ;store auxreg(n) | NOP STI AR2,*AR1
STI AR0,*ARn ;auxreg(n) used as address| STI AR2,*AR1 NOP
NOP | STI AR0,*AR2 STI AR0,*AR2
|
|
RETIUD | RETIUD RETIUD
LDI R0,ARn ;load auxreg(n) | NOP LDI R0,AR2
STI AR0,*ARn ;auxreg(n) used as address| LDI R0,AR2 NOP
NOP | STI AR0,*AR2 STI AR0,*AR2
|
|
RETIUD | RETIUD RETIUD
STI DP,*AR1 ;store data page pointer | NOP STI DP,*AR1
LDI @data,R0 ;DP used in address | STI DP,*AR1 NOP
NOP | LDI @data,R0 LDI @data,R0
|
|
RETIUD | RETIUD RETIUD
LDI R0,DP ;load data page pointer | NOP LDI R0,DP
LDI @data,R0 ;DP used in address | LDI R0,DP NOP
NOP | LDI @data,R0 LDI @data,R0
|
|
RETIUD | RETIUD RETIUD
LDI 1, IR0 ;load IR0 | NOP LDI 1, IR0
STI R7, *AR2(IR0) ;IR0 used in address | LDI 1,IR0 NOP
NOP | STI R7,*AR2(IR0) STI R7,*AR2(IR0)
|
|
RETIUD | RETIUD RETIUD
STI IR0,*AR1 ;store IR0 | NOP STI IR0,*AR1
STI R7, *AR2(IR0) ;IR0 used in address | STI IR0,*AR1 NOP
NOP | STI R7,*AR2(IR0) STI R7,*AR2(IR0)
|
|
RETIUD | RETIUD RETIUD
LDI 100, BK ;load BK | NOP LDI 100, BK
STI R7, *++AR2% ;BK used in address | LDI 100,BK NOP
NOP | STI R7,*++AR2% STI R7,*++AR2%
|
|
RETIUD | RETIUD RETIUD
STI BK,*AR1 ;store BK | NOP STI BK,*AR1
STI R7, *++AR2% ;BK used in address | STI BK,*AR1 NOP
NOP | STI R7,++*AR2% STI R7,*++AR2%
============================================================================
PROBLEM 3.0.4 Cache Update Logic
In a very special condition, TMS320C40 device will execute an incorrect opcode
due to a bug in the cache update logic. This bug exists on PG 3.2 and earlier
version C40 silicons only. It will be fixed in the later version C40 silicon.
When C40 cache is enabled, the cache freeze bit, CF, in the status register,
ST, is used to freeze (CF = 1) and unfreeze (CF =0) the cache update. This
cache problem will occur under the following conditions:
1. The value of CF bit goes through 1-0-1 sequence, and
2. During CF = 0 period, no instruction fetch is started and a
multi-cycle instruction fetch is in progress (single cycle program
fetch will not have problem).
When the above conditions are met, the opcode of the multi-cycle fetch
instruction will be put into the cache without updating the cache segment
address register. Therefore, if this corrupted cache segment is executed again
before it gets update with other address instruction, the incorrect opcode will
be executed.
An interrupt service routine (ISR) is the most likely place to find this
problem. Usually, the ST value is saved on the stack in the beginning of ISR
function and restored before the RETI or RETID instruction. Therefore, if there
is an interrupt pending before returning from the ISR and the instruction after
returning from ISR is a multi-cycle fetch instruction, the above condition can
occur. If somehow this corrupted cache is executed again before it gets update
with other address, for instant - cache is frozen (CF = 1), the system will run
into an unexpected situation. An example that might cause a problem is shown
below:
: :
: : ; CF = 0
Interrupt occurs ; CF set to 1 and PCF set to 0
PUSH ST
: :
ANDN 0400H,ST ; CF = 0
: : ; 4 segment cache filled
: : ; with these instructions
: :
POP ST ; CF set to 1 and PCF set to 0
RETI ; CF set to 0
Interrupt occurs again ; CF set to 1 and PCF set to 0
Repeat above sequence
Although the cache is unfrozen in the above interrupt routine program, it does
not mean the problem won't occur if the cache remain frozen in the ISR. However,
the device will be less likely to run the corrupted cache program again before
the faulty cache segment address gets update if the cache is frozen in the ISR.
Normally after the next RETI, instructions will be fetched and the cache error
is cleared.
WORKAROUND:
The workaround of this problem is to force the CF value equal to PCF value
before saving ST register or RETI/RETID. Examples are shown below:
Example 1:
: :
: : ; CF = 0
Interrupt occurs ; CF set to 1 and PCF set to 0
ANDN 0800H,ST ; Set CF = 0 (PCF = 0)
PUSH ST ; Save the ST value
: :
ANDN 0800H,ST ; CF = 0
: :
: :
: :
POP ST ; CF set to 0 and PCF set to 0
RETI ; CF set to 0
Example 2:
: :
: : ; CF = 0
Interrupt occurs ; CF set to 1 and PCF set to 0
PUSH ST
: :
ANDN 0800H,ST ; CF = 0
: :
: :
: :
POP ST ; CF set to 1 and PCF set to 0
ANDN 0800H,ST ; Set CF = 0 (PCF = 0)
RETI ; CF set to 0
============================================================================
PROBLEM 3.0.9 DMA missing interrupts during autoinitialization:
The C40 DMA misses interrupts that are received during the autoinitialization
process and that are not present when the autoinitialization process finishes.
Interrupts affected could include edge or level-triggered external
interrupts and timer interrupts. Comm ports interrupts are not affected
because they continue being present after the autoinitialization sequence
finishes.
============================================================================
PROBLEM 3.0.10 BK register ready pipeline conflict
If the BK register is loaded and one of the next 2 instructions uses
circular addressing that generates an address outside the block size
boundary, the wrong circular address may be generated.
The problem is present only when the instruction using circular addressing
is a 3-operand or a parallel instruction. Following is an example illustrating
the problem.
ldi 16,bk
ldi 15,rc
rptb again
ldi 8,bk
again mpyf *ar3++%,*ar2++,r0 ; bug
|| addf r0,r2
When the problem occurs, the circular address is generated based on the previous
value of the BK register (BK=16) instead of with the new value (BK=8).
This results in a wrong circular addressing being generated.
WORKAROUNDS:
There are several workarounds for this problem:
1) add 2 NOPS after the loading of the BK register. This solution always
works.
ldi 16,bk
ldi 15,rc
rptb again
ldi 8,bk
nop
nop
again mpyf *ar3++%,*ar2++,r0 ; no bug
|| addf r0,r2
2) In some cases the problem is limited to auxiliar registers AR0 to AR5.
When AR6 or AR7 is used for circular addressing generation the problem
doesn't exist. For example, in the example above, if AR3 is replaced by AR6 or
AR7, the problem disappears.
3) For some instructions, reversing the order of the operand will solve the
problem. An example is shown below:
ldi 16,bk
ldi 15,rc
rptb again
ldi 8,bk
again mpyf *ar2++,*ar3++%,r0 ; no bug
|| addf r0,r2
============================================================================
PROBLEM 3.0.11 Cache logic
In a very special condition, the C4x will execute an incorrect opcode
due to a bug in the cache logic.
For this cache problem to occur, all the following conditions should be met:
1. Cache is enabled.
2. Program is being fetch from external memory and shared memory scheme
is used with DE_ and AE_ signals
3. An interrupt occurs during the fetch phase of an instruction.
4. The following sequence should occur after the interrupt is recognized:
RDY_ goes high, address and data buses get tristated and
the data bus changes within 2 cycles after RDY_ goes high.
This causes the wrong instruction opcode to be stored in the cache.
Therefore upon returning from the interrupt service routine, the correct
instruction is never executed.
WORK AROUND:
There are 2 workarounds for this problem:
1) Clear the cache inside the interrupt service routine. An example is shown
below:
Example 1:
ISR:
PUSH r10 ; Save the register value (could be any reg)
LDHI 1, r10
OR r10,st ; CC=1
: :
: :
: :
: :
POP r10 ; Recover the register value
RETI
2) After taking RDY_ high, wait 2 cycles to tristate the address and data
buses
| Device: TMS320C4x Category: Device Information |
Title: C4x Silicon Errata Source: TI Apps Date: 1/4/98 GenId: c40r34se |