TMS320F2800157-Q1: TMS320F2800157[LIN COMMUNICATION] LIN communication error&&Startup delay before initiating LIN communication

Hello,

I have a few clarifying questions before I can provide some explanations.

1. By ON/OFF testing of the device, which of the resets did you do? 

1. When you see the "issue where LIN communication fails to operate", does this mean there will never be a response on the LIN bus until the next reset? Or it just takes some time after starting up to begin working?
2. How are you initializing the LIN module? Where in your device startup does this happen (can you share your code)?
3. Overall, could you give a little more information about your application and what you expect the LIN module to do vs. what the actual behavior was?

Best Regards,

Delaney 

Dear [Delaney Woodward],

I hope this message finds you well.

We are currently experiencing an issue related to LIN communication during system startup. Please see the summary of the issue below:

1.The MCU input power is turned ON and OFF

1. After power-on, LIN communication occasionally fails to start immediately — approximately once in every 50 power cycles. In such cases, it begins functioning normally only after a delay of about 10 minutes. This intermittent issue is causing disruptions in system operation.

2. We have attempted to recover communication by performing a software reset and executing the LIN wake-up sequence, as shown below:

// Enable LIN Mode
HWREG(LINA_BASE + LIN_O_SCIGCR0) |= 0;
HWREG(LINA_BASE + LIN_O_SCIFLR) |= 0;
HWREG(LINA_BASE + LIN_O_SCIFLR) |= LIN_SCIGCR1_LINMODE;

// LIN Wake-up Sequence
HWREG(LINA_BASE + LIN_O_SCIGCR0) |= 0;
HWREG(LINA_BASE + LIN_O_SCIGCR1) |= 0;
HWREG(LINA_BASE + LIN_O_SCIGCR1) |= LIN_SCIGCR1_SWNRST;
HWREG(LINA_BASE + LIN_O_SCIFLR) |= LIN_SCIFLR_WAKEUP;

3. The MCU itself is operating normally; however, both LIN RX and TX are unresponsive. Approximately 10 minutes after power is supplied, the LIN communication becomes active and operates as expected.

4. Could you kindly provide the expected LIN communication stabilization time after power-on? Any insights or recommendations to resolve this delay would be greatly appreciated.

Hello,

I would recommend following the initialization flow from one of our software examples to make sure the LIN module is being configured fully and in the correct order. It looks like your code differs from how the examples and driver functions initialize the module. These examples can be found in the SDK path: [C2000ware install]/driverlib/f280015x/examples/lin/. 

?? ? said:

4. Could you kindly provide the expected LIN communication stabilization time after power-on? Any insights or recommendations to resolve this delay would be greatly appreciated.

If everything is initialized properly in software, there should be no need for extra stabilization time for the LIN. It sounds like sometimes the module is getting into an invalid state. Can you try changing your startup code to use driverlib function calls in the order from one of the SDK examples and see if that fixes your issue?

Best Regards,

Delaney

Dear [Delaney Woodward],

I hope this message finds you well.

We are currently experiencing an issue related to LIN communication during system startup. Please see the summary of the issue below:

As observed, LIN communication is functioning normally, but the error flags CE (Checksum Error) and FE (Framing Error) are not being cleared. It is said that they are cleared upon reception of a new sync break, but I would like to understand why they are not cleared even when a valid LIN frame is received.

Hello,

These flags should be automatically cleared if the next synch break is received successfully. Note however that they will be set again if the next packet has errors. How are you checking the status of the flags? Are you stopping at a breakpoint inside a LIN ISR? Do you have continuous refresh toggled on?

Best Regards,

Delaney

I checked the register flag values through the debugger connection.
Even when the Sync Break is transmitted, the flags are not cleared.
Additionally, I did not pause execution using a breakpoint.
Continuous refresh is enabled.

As shown in the waveform below, there is no noise or data corruption — the frame comes in perfectly normal.
However, the LIN frame error does not get cleared.

To prevent receiving abnormal values due to noise, we check the LIN error flag before accepting data.
However, even when a valid frame is received, the error flag does not get cleared.

Hello,

For the framing error specifically, this indicates that synchronization of packets between the transmitting LIN and the receiving LIN has been lost. If this is the case, the framing error flag will continue to get raised since it is always looking at the wrong portion of each frame (maybe it is shifted by one bit). For this reason, even if the data looks fine after the error takes place, it can detect a framing error. This issue would also cause a checksum error since the module would be computing the checksum on the wrong part of the message and comparing to the wrong byte.   

Usually, with these types of errors, it is best to avoid them all together by fixing the software implementation rather than trying to recover the module from this state.

What baud rate and SYSCLK frequency are you using? - This will help determine if the configurations are prone to errors.

Best Regards,

Delaney

Hello,

I am going out of office, so looping in another expert to assist you further.

Best Regards,

Delaney

When clearing the LIN error flags (BE, CE, FE, OE) in the SCIFLR register, I’m considering two methods: setting the SWnRESET bit (SCIGCR1.7) or writing a 1 directly to the flag bit. In the case of setting the SWnRESET bit (SCIGCR1.7), are there any side effects?

Hello,

Delaney is still out of office the next week. I will try to provide some information in the meantime.

Regarding the two methods:

1. Using SWnRESET (SCIGCR1.7): 

• Keep in mind this SW RESET ensures all flags in SCIFLR register are frozen with their reset values while SWnRST = 0. This means the SW RESET affects multiple flags and LIN functionality (state machine is reset), not just error flags. This can be a benefit when needed to recover communication after error handling, but just be aware that not only one error flag is reset.

2. Writing 1 directly to error flags: 

• This is a more targeted approach as it only affects the specific error flag being cleared. This ensures your other configurations are not reset as noted above. However, depending on your system error, simply clearing the single flag may not be enough to restore LIN functionality. In that case, RESET would be advised. 

Best Regards,

Allison