
                TMS320C5xPQ SILICON ERRATA
		Rev 1.x Silicon (Document Revision 1.2)
                Last Modified:06/08/92

 The following problems exist in the TMS320C50PQ, the
 TMS320C51PQ, and the TMS320C53PQ (The PQ is the Plastic
 Quad Flat Pack package and should be distinguished from the
 ceramic HQ package).  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.

 PROBLEM 1:
 The underflow and overrun error flags on serial port #1 and
 serial port #2 (TDM and non-TDM mode), XSREMPTY and RSRFULL,
 are non-functional. These flags should not be used to detect
 any error condition.

 On the receive side of the serial port #1 (and the serial
 port #2 in non-TDM mode), RSR (TRSR) register contents are
 copied to DRR (TDRR) register each time RSR (or TRSR) has
 shifted in a full word (or byte) and the previous contents
 of DRR (or TDRR) have already been read. This is normal
 device operation. However, if the current DRR (or TDRR)
 contents have not been read and RSR (or TRSR) has received
 new word then RSR (or TRSR) to DRR (TDRR) transfer will
 still take place if external FSR line strobes, thus
 overwriting DRR.  The receive interrupt would also be
 generated at the same time. According to the serial port
 specs, RSR (or TRSR) to DRR (or TDRR) transfer should not
 have taken place in this receive over-run condition.

 On the transmit side the operation of the serial port is
 according to spec except for the non-functionality of the
 XSREMPTY flag.

 For the Continuous Mode, both receive and transmit sides,
 the silicon behaves as described above.


 WORK AROUND 1:
 Note that both the serial ports (TDM or non-TDM) behave
 according to the specs except under receive over-run and
 transmit under-flow conditions. The user should either avoid
 these conditions or understand the ramifications of it.

 WILL FIX IN SILICON REVISION 2.x


 PROBLEM 2:
 A RPT instruction located within two words of the end of a
 repeat block will cause the block repeat counter BRCR and
 the repeat counter RPTC to be corrupted.

                RPTB END_LOOP-1
                 .
                 .
                RPT  TIMES
                NOP       ;Any repeatable C5X instruction
                NOP       ;Any valid C5X instruction
      END_LOOP



 WORK AROUND 2:
 Place a NOP between the repeated instruction and the end of
 the repeat block.

                RPTB END_LOOP-1
                 .
                 .
                RPT  TIMES
                NOP            ; Any repeatable instruction
                NOP            ; Any valid C5X instruction
                NOP            ; Added as bug workaround
      END_LOOP

      WILL FIX IN SILICON REVISION 2.x.


 PROBLEM 3:
 An XC instruction located at the end of a repeat block with
 k=2 will cause the block repeat counter BRCR to not
 decrement if the condition is false.

                RPTB END_LOOP-1
                 .
                 .
                XC  2, cond
                NOP            ; Could be 1 2-word or 2
                NOP            ; 1-word C5X instructions.
      END_LOOP

 WORK AROUND 3:
 Place a NOP between the  instruction and the end of the
 repeat block.
                RPTB END_LOOP-1
                 .
                 .
                XC   2, cond
                NOP                 ; Could be 1 2-word or 2
                NOP                 ; 1-word C5X instructions
                NOP                 ; Added as bug workaround
      END_LOOP

      WILL FIX IN SILICON REVISION 2.x.

 PROBLEM 4:

 When coming out of HOLD (HOLDA_ goes high) if the first
 action is an external memory write, the STRB_ signal will go
 active one cycle early for that write.  There is no problem
 in this situation with the first read or any subsequent
 accesses.  This problem does not affect any of the other
 memory interface signals.


 WORK AROUND 4:

 This is a hardware bug and has no software workarounds.
 Even though STRB_ becomes active one cycle early, WE_ only
 becomes active as specified and data will be valid on the
 bus when WE_ is active.  If WE_ is used to write data into
 the target devices (memory or I/O), then correct data would
 be written.

 WILL FIX IN SILICON REVISION 2.x.

 PROBLEM 5:

 The I/O space addresses from 20h to 4Fh and from 80h to FFh
 are not decoded.  Thus instructions using these port
 addresses will not function properly.  There is no problem
 with the sixteen memory-mapped port addresses in the range
 50h to 5Fh.  The following map identifies the problem
 addresses in I/O space.

                        I/O
                0000h _________
                     |         |
                     | Valid   |
                001Fh|         |
                0020h|---------|
                     | Invalid |
                004Fh|---------|
                0050h|         |
                     | Valid   |
                007Fh|         |
                0080h|---------|
                     | Invalid |
                00FFh|---------|
                0100h|         |
                     | Valid   |
                     |         |
                FFFFh|_________|

                  C5X I/O Space Map


 WORK AROUND 5:

 Avoid using the I/O space port addresses cautioned above.

 WILL FIX IN SILICON REVISION 2.x.


 COMPATIBILITY NOTE:
 The frame synchronization pulse of the C5X is an active high
 signal that marks the beginning of a serial port transfer.
 Thus when coming out of serial port or device reset, the FSX
 pin (if configured as an input) should be low.  The
 following problem is discussed because of compatibility
 issues with certain parts such as the TLC320XX Analog
 Interface Chip (AIC).


 PROBLEM 6:
 If the transmit frame sync (FSX or TFSX) pin is configured
 as input on serial port #1 (or serial port #2 in non-TDM
 mode) and it is kept high when serial port is taken out of
 reset then the first word shifted out on DX (or TDX) line
 may be random. This may happen because the DXR to XSR (or
 TDXR to TXSR) transfer does not take place under this
 condition when the serial port is taken out of reset and the
 uninitialized contents of XSR (or TXSR) are shifted out at
 the falling edge of FSX (or TFSX). Note that in this case,
 the first word written to DXR (or TDXR) by the user's code
 will be transmitted as the second word on DX (or TDX) line.

 WORK AROUND 6:

 In most serial port interfaces, transmit frame sync input is
 kept low (or inactive) until the serial port is initialized.
 For such cases, the above problem will not be relevant.
 However, in case of AIC (TLC320xx) interface, FSX (or TFSX)
 will be driven high by AIC during periods of inactivity.  If
 a power-up reset is used on AIC then it is likely that the
 FSX (or TFSX) line will be high when the serial port is
 taken out of reset.  Since a random data transfer from 'C5x
 to the AIC can potentially modify AIC's mode of operation,
 it is recommended that the 'C5x has control over the AIC reset
 line.	The following code illustrates the AIC initialization
 using XF to control AIC reset line:
	.
	.
	.
 * initialize serial port
 *
	lacc #0000000000001000b  ; initialize serial port
	sacl spc
	lacc #0000000011001000b  ; take it out of reset
	sacl spc
	zac
	sacl dxr		 ; clear first int

	rpt #100		 ; wait a few cycles
	nop

	clrc xf 		 ; put AIC in reset
	rpt #N			 ; N depends on min AIC reset
	nop			 ;   pulse width
	setc xf 		 ; take AIC out of reset
	splk #020h,imr		 ; enable xint for aic init
	splk #0ffffh,ifr
	clrc intm		 ; enable interrupts
	.
	.
	.

 WILL MODIFY (MAKE NON-RANDOM) IN SILICON REVISION 2.x

