@danielmartynek Hello, when I was using the LPUART1 of S32K314 as the LIN slave to communicate, I found that initially the slave could respond normally to the frame headers sent by the host, but after a period of time, the slave could no longer respond to the frame headers sent by the host. Moreover, when receiving data, starting from the second interrupt, it could no longer stay at my data receiving breakpoint. As shown in the figure below, I use the callback function to handle the responses and receptions of the slave machine. When using the debugging monitoring function, I found that the first time entering the interrupt could detect the status of the synchronization interval segment and enter the function for processing the synchronization interval segment. However, when entering the interrupt again, it would go into the (void)Lpuart_Lin_Ip_HwClearStatusFlag(Base, LPUART_LIN_IP_ALL_INT_FLAGS); routine. When the function re-enters the interrupt, it will detect LPUART_LIN_IP_FRAME_ERR && LPUART_LIN_IP_INT_FRAME_ERR_FLAG and perform error handling. Only after this handling is completed will it enter my callback function for execution. I set breakpoints in the Lpuart_Lin_Ip_FrameIrqHandler function at LPUART_LIN_IP_NODE_STATE_RECV_SYNC and LPUART_LIN_IP_NODE_STATE_RECV_PID respectively, but there was no execution to this point. I wonder what kind of problem might cause this. I am looking forward to your reply, as it is very important to me.
Hello, based on your request, I set a breakpoint at the Lpuart_Lin_Ip_FrameErrorIrqHandler location for monitoring. I found that during the running process, my LIN would switch back and forth between this code and my receiving callback function, and my buffer was able to receive data. There was no specific error reason in the Lpuart_Lin_Ip_FrameErrorIrqHandler function. Currently, what I can confirm is that this function Lpuart_Lin_Ip_FrameErrorIrqHandler is frequently called during the running process, but my receiving response buffer is still able to receive data. After a period of running, this function Lpuart_Lin_Ip_FrameErrorIrqHandler and my callback function will no longer enter the loop. I can interpret this as a communication interruption. How can I find out where the problem lies? Do I need to check any registers? Oh, by the way, the first picture shows that after learning about the error of not clearing the overflow register flag in the RTD2.0.0 version, I manually cleared it in the box. Am I understanding this correctly? This indeed solved the problem that I couldn't enter the callback function after running several times, but the communication still got disconnected afterwards. My description might be a bit complicated, but I'm looking forward to your help. I would be extremely grateful.
Hi @Aoyng,
When you place a breakpoint in the RECV_SYNC case, the LIN master continues transmitting and does not wait for the slave. As a result, the PID field and the rest of the frame are sent while the CPU is halted, so they are not processed correctly by the driver.
This likely causes the desynchronization and leads to the “spurious” interrupt you are observing.
Instead, I recommend placing breakpoints in the error handling path, for example in Lpuart_Lin_Ip_FrameErrorIrqHandler(). These handlers are triggered by actual protocol or bus errors.
Once you identify the initial LPUART error, we can analyze the issue further.
BR, Daniel
Could you please tell me if there are any hidden bugs in my aforementioned code? Thank you very much for checking if there are any issues with my code logic. Since I haven't encountered the situation of LIN communication interruption before, I would greatly appreciate it if you could help me analyze it. Thank you!
It seems the message for LPUART_LIN_IP_FRAME_ERR && LPUART_LIN_IP_INT_FRAME_ERR_FLAG have blocked your LIN communication. Have you check from HARDWARE side? How about your LIN communication loop from structure point of view
Hello @Aoyng,
If Lpuart_Lin_Ip_FrameErrorIrqHandler() is called, it indicates that a real framing error has been detected.
Please verify both baud rates using an oscilloscope.
Refer to the Reference Manual, section 77.3.2 Baud rate tolerance.
The overrun occurs because the application is not able to read the received data in time. This may happen if a higher-priority interrupt preempts the LIN interrupt.
You may try increasing the priority of the LPUART interrupt or temporarily disabling competing interrupts to confirm this behavior.
Regarding your previous comment, it is not entirely clear:
Do you mean that the overrun interrupt is not being processed in Lpuart_Lin_Ip_RxOverrunErrorProcess()?
Can you confirm whether execution reaches this function?
This function is responsible for clearing the overrun (OR) flag.
Based on the current information, there is no indication that the driver itself needs to be modified.
Regards,
Daniel
Hello, currently my LIN interrupt priority is set to 0. I believe the priority has reached the highest level. The situation I mentioned about being unable to clear the overflow flag was seen in a post by a person named dongxun. The post is about a bug in the RTD 2.0.0 library: LIN: S32K312 MCU as a Master, Lin Timeout Error while waiting for LinID. And after clearing the received overflow in the interrupt, I did not encounter the situation where the program got stuck at the receiving part after running for the second time. It only ran for a while and then disconnected. Regarding the baud rate issue you mentioned, I set both the master and slave sides to a baud rate of 19200. I am certain of this because if it were a baud rate issue, I believe the communication would not have started in the first place.
What you are seeing is actually expected behavior in this setup. When you increased the LIN interrupt priority and lowered the PIT priority, you ensured that the LIN ISR is serviced in time, which is critical for correct operation.
Each received byte must be read from the DATA register before the next byte arrives. If the CPU does not service the RX interrupt fast enough, the hardware sets the overrun (OR) flag.
If the PIT interrupt is able to preempt the LIN interrupt, then the PIT interrupt service routine must be very short. Otherwise, it can delay the LIN ISR long enough to miss incoming data.
Regards,
Daniel
Hi @Aoyng,
You’re correct—there is a bug in the LIN driver: the overrun interrupt is not enabled by default. Have you tried enabling this interrupt after initializing the LIN driver? The logic to clear the flag is already implemented.
it’s always a good practice to verify baud rates using an oscilloscope to ensure proper timing.
BR, Daniel
Hello, I was attempting to set the LIN interrupt priority to the highest level and the PIT priority to a lower level. After doing so, I found that the communication could run normally without any interruption. Could you please explain why there is a communication disconnection issue with LIN? Currently, I am using the LIN transceiver with the FS6500 chip. From my understanding, if there is an interrupt conflict, shouldn't there be a frame loss problem? Can you provide an answer? Looking forward to your reply.