S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked

cjq

Hi NXP Experts,

I am currently working on the LIN implementation using the LLCE component on S32G3 (running as a LIN Master). We are using S32G_LLCE_1_0_10.

We have encountered a strange behavior regarding the Frame Timeout configuration in the LLCE LIN firmware, and I would like to seek some internal details or clarifications about the firmware's black-box logic.

Problem Description:
When configuring the LIN channel with "Disable Frame Timeout" UNCHECKED (meaning timeout detection is enabled) and setting the Response Timeout value to 14:

The LLCE LIN Master successfully transmits the Header (Break + Sync + PID) to the bus.

The Slave node receives the Header and responds with the correct Data + Checksum immediately.

However, the LLCE LIN Master randomly or constantly fails to capture/receive the data. It behaves as if the data is lost or dropped by the LLCE firmware.

Workaround Found:
If we simply CHECK "Disable Frame Timeout" (disabling the firmware's internal timeout logic) in the configuration tool while keeping all other hardware and physical bus environments exactly the same:

The Master never drops any data and successfully receives every single response from the Slave.

Our Questions:
Since the LLCE_firmware_user_guide.pdf provides very limited information about the internal state machine, we are confused by this behavior:

How is the timeout value "14" precisely calculated inside the LLCE firmware? Does a value of 14 represent absolute microseconds, bit times, or cycles related to a specific GPT/timer clock source?

Why does the Master fail to grab the response even when the Slave replies immediately? Is it possible that the timeout counter starts too early (e.g., before the Header finishes transmitting), or is "14" too small a threshold due to some internal hardware/firmware execution latency?

What is the recommended way to properly calculate and set this timeout value if we do want to keep the Frame Timeout protection active without dropping valid responses?

Any documentation, application notes, or insights into the LLCE LIN firmware's internal timing logic would be highly appreciated.

Thanks in advance!

Best regards,
cjq

chenyin_h

Hello, @cjq

Thanks for the post.

1. May I know if you are working with a S32G3 based custom board or reference board from NXP?

2. Is the issue found in your custom implementation or from any samples provisioned by NXP?

BR

Chenyin

cjq

Hi Chenyin,

Thank you for your quick response. Here are the clarifications to your questions, along with a correction regarding the firmware version:

Hardware: We are using a custom board based on S32G3, not the official NXP reference board.
Implementation: We are not running the official example directly. It is our custom implementation, but it is closely referenced and developed based on the official NXP sample code.

Correction on Firmware Version: I realized I made a mistake regarding the version in my initial post. We are actually using S32G_LLCE_1_0_09, not S32G_LLCE_1_0_10.

Could you please help check if there are any known bugs related to the LIN response timeout in version 1.0.09, or how the timeout value "14" is interpreted by this specific firmware version?

Best regards, cjq

chenyin_h

Hello, @cjq

Thanks for your clarification.

1. If DisableFrameTimeout box is checked, then Lin driver will accept the frame that is longer than Maximal Frame Length.

2. For "LinResponseTimeout", the reset value is 0Eh = 14, corresponding to T_Response_Maximum = 1.4 x T_Response_Nominal. This is the response timeout duration (in bit time) for 1 byte.

BR

Chenyin

cjq

Hi Chenyin,

Thank you for the clarification. Since we have decided to keep DisableFrameTimeout checked for our application, the specific timeout calculation is no longer an issue for us.

However, I would like to confirm one specific behavior regarding the firmware's state machine when DisableFrameTimeout is enabled:

When the LIN Master transmits a Header and the Slave fails to reply, calling Lin_GetStatus() shows that the channel remains permanently stuck in the LIN_TX_BUSY state.

Is this permanent LIN_TX_BUSY state the expected and normal behavior of the LLCE firmware under this configuration?

I assume that because the frame timeout logic is entirely disabled, the internal state machine will wait indefinitely for the response data and will never automatically transition out of the busy state. I just want to verify if my understanding aligns with the official design.

Best regards, cjq

chenyin_h

Hello, @cjq

Thanks for your reply.

With frame timeout disabled and no slave response, since LLCE_LIN state machine receives neither a response-complete event nor a timeout event, there would be issues, so If no-response detection is required, keep frame timeout enabled or implement an application-level timeout that aborts/reinitializes the LIN channel.

BR

Chenyin