AnsweredAssumed Answered

SPC560xB Unexpected LIN timeout in slave mode

Question asked by Anders Lindén on May 4, 2015
Latest reply on May 6, 2015 by Lukas Zadrapa

I think SPC560xB is replaced with MPC560xB.
The MCU does sporadic missing of respons to headers and LINESR.B.OCF is set.


According to Errata e3021 for MPC560xB rev 16 July 2014 included in Appendix A in this post there is a workaround, and it works, unfortunately it makes an other faulty mode to pop up, when doing LIN conformance test, 3.8.1 Incomplete frame reception. Break field only; this work around will in my case result in no response on the next header after the Break field without any header and the test fails.

register flags LINESR.B.SFEF and LINESR.B.OCF sets


Figure 1: Logic analyser, with no response.


But if I sets register flags according this;

LF->LINIER.B.OCIE = 1u;  /* Output Compare Interrupt Enable */

LF->LINTCSR.B.IOT  = 1u; /* LIN state machine reset to Idle on time out event. */


LF->LINTOCR.B.HTO  = 90u; /* Header timeout value */


Both Incomplete frame reception. Break field only works and sporadic frame response problem decrease allot but does not disappear.



Figure 2: Logic analyser, with response.


HTO value is not according to LIN 2.1 spec which specifies in 2.32 FRAME LENGTH

THeader_Nominal = 34 * TBit

THeader_Maximum = 1.4 * THeader_Nominal


Which in my case would be TBit = 52 us in 19200 baud which would give a HTO value of 48, lower HTO than 90 gives sporadic LIN timeout



Is this a known issue with LINFLEX? and does anyone know if it is secure according to LIN to have a to high HTO value?


Appendix A

e3021: LINFlex: Unexpected LIN timeout in slave mode

Description: If the LINFlex is configured in LIN slave mode, an unexpected LIN timeout event

(LINESR[OCF]) may occur during LIN Break reception.

Workaround: It is recommended to disable this functionality during LINFlex initialization by clearing

LINTCSR[IOT] and LINIER[OCIE] bits, and ignore timeout events.