SPRZ507D January   2023  – November 2024 TMS320F2800152-Q1 , TMS320F2800153-Q1 , TMS320F2800154-Q1 , TMS320F2800155 , TMS320F2800155-Q1 , TMS320F2800156-Q1 , TMS320F2800157 , TMS320F2800157-Q1

 

  1.   1
  2.   TMS320F28003x Real-Time MCUs Silicon ErrataSilicon Revision 0
  3. 1Usage Notes and Advisories Matrices
    1. 1.1 Usage Notes Matrix
    2. 1.2 Advisories Matrix
  4. 2Nomenclature, Package Symbolization, and Revision Identification
    1. 2.1 Device and Development-Support Tool Nomenclature
    2. 2.2 Devices Supported
    3. 2.3 Package Symbolization and Revision Identification
  5. 3Silicon Revision B Usage Notes and Advisories
    1. 3.1 Silicon Revision B Usage Notes
      1. 3.1.1 PIE: Spurious Nested Interrupt After Back-to-Back PIEACK Write and Manual CPU Interrupt Mask Clear
      2. 3.1.2 Caution While Using Nested Interrupts
      3. 3.1.3 Security: The primary layer of defense is securing the boundary of the chip, which begins with enabling JTAGLOCK and Zero-pin Boot to Flash feature
    2. 3.2 Silicon Revision B Advisories
      1.      Advisory
      2.      Advisory
      3.      Advisory
      4.      Advisory
      5.      Advisory
      6.      Advisory
      7. 3.2.1 Advisory
      8.      Advisory
      9. 3.2.2 Advisory
      10.      Advisory
      11. 3.2.3 Advisory
      12.      Advisory
      13.      Advisory
      14.      Advisory
      15. 3.2.4 Advisory
      16. 3.2.5 Advisory
      17.      Advisory
      18.      Advisory
      19. 3.2.6 Advisory
      20.      Advisory
  6. 4Silicon Revision A Usage Notes and Advisories
    1. 4.1 Silicon Revision A Usage Notes
    2. 4.2 Silicon Revision A Advisories
      1. 4.2.1 Advisory
  7. 5Silicon Revision 0 Usage Notes and Advisories
    1. 5.1 Silicon Revision 0 Usage Notes
    2. 5.2 Silicon Revision 0 Advisories
  8. 6Documentation Support
  9. 7Trademarks
  10. 8Revision History

3.2.5 Advisory

LIN: Inconsistent Sync Field Error (ISFE) Flag/Interrupt Not Set When Sync Field is Erroneous

Revisions Affected

0, A, B

Details

During LIN communications, if the Sync field received (on RX) is erroneous (that is, if the Sync field receives any value other than 0x55), the LIN does not set the ISFE Flag in the SCIFLR.ISFE register or trigger the ISFE interrupt. Communication gets terminated without data being received or the RX receive interrupt being set. There is no way for an application to detect an error in the Sync field. The application can detect if the Sync field is completely blank or if the Sync field is not received within the given tolerances (as explained in the TMS320F280015x Real-Time Microcontrollers Technical Reference Manual), but the application cannot detect any error in the value of Sync field.

Workarounds

Method 1: Keep polling the SCIFLR.RXRDY flag and time out if it is not set within a certain amount of time.

Use the following steps as a guideline:

  1. Poll for the SCIFLR.BUSY flag to set.
  2. Once the BUSY flag goes high, poll for the SCIFLR.RXRDY flag. Concurrently within this loop, also have a SW timeout, which times out and exits the loop if the RXRDY flag is not set within a user-defined time interval.

Method 2: Configure the CPU timer to interrupt if the RX interrupt is not triggered. This method does not use CPU bandwidth.

Use the following steps as a guideline:

  1. Configure XINT to trigger an ISR when the LINRX goes from high to low (indicating LIN is busy).
  2. Inside the XINT ISR, configure the CPU timer, which starts timing the frame completion.
  3. If the frame is received correctly with the correct Sync field, it should trigger the LIN RX ISR, inside which you can turn off the timer so that you do not get a false timeout.
  4. If the frame is not received correctly, it does not trigger the LIN RX ISR but triggers the CPU timer ISR (timeout occurred), which indicates an error in the Sync field.