SPRZ439H January   2017  – February 2024 TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1

 

  1.   1
  2.   TMS320F28004x Real-Time MCUs Silicon Errata (Silicon Revisions B, A, 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 FPU32 and VCU Back-to-Back Memory Accesses
      3. 3.1.3 Caution While Using Nested Interrupts
      4. 3.1.4 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.      Advisory
      8.      Advisory
      9.      Advisory
      10.      Advisory
      11.      Advisory
      12.      Advisory
      13.      Advisory
      14.      Advisory
      15.      Advisory
      16.      Advisory
      17. 3.2.1 Advisory
      18.      Advisory
      19.      Advisory
      20.      Advisory
      21.      Advisory
      22. 3.2.2 Advisory
      23.      Advisory
      24.      Advisory
      25.      Advisory
      26.      Advisory
      27.      Advisory
      28. 3.2.3 Advisory
      29.      Advisory
      30.      Advisory
      31. 3.2.4 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.      Advisory
      2.      Advisory
      3.      Advisory
      4.      Advisory
      5.      Advisory
      6.      Advisory
  7. 5Silicon Revision 0 Usage Notes and Advisories
    1. 5.1 Silicon Revision 0 Usage Notes
    2. 5.2 Silicon Revision 0 Advisories
      1.      Advisory
      2.      Advisory
      3.      Advisory
  8. 6Documentation Support
  9. 7Trademarks
  10. 8Revision History

3.2.4 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 TMS320F28004x 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.