S32K: Assistance Required with LIN Timeout Management Configuration

[dongxun]

Hi, 

I hope this message finds you well. I am currently facing an issue while configuring LIN timeout management using EBTreos. I have referred to the routine in Lin_MasterFrameTransfer_S32K312 as well as the RTD_LIN_UM.pdf document found in Lin_TS_T40D34M20I2R0. In my setup, the MCU is acting as the host, and I am sending headers to receive simulated messages in CANOE. Here are the specific issues I have encountered:

1. When I enable Lin Frame Timeout Disable: I do not perform any response timeout management, and I can receive data normally.
2. When I do not enable Lin Frame Timeout Disable: I manually add the callback functions LinLpuartStart and LinLpuartStop, and I also configure the GPT module's timer callback function Switch_TimeOut to manage timeout events.

 However, in this scenario, the slave does not send any data. The oscilloscope shows that only the master sends a header. I suspect that the issue may be related to timing. I have configured the timer to a 40MHz clock and set the CountValue in Pit_Ip_StartChannel to 40MHz, which means the timing period is 1 second. Under this configuration, testing proceeds normally.

However, when I try to set the timer to microsecond-level timing, it does not work as expected. Here is a snippet of my code for reference: 

void LinLpuartStart(uint8 Instance, uint32 MicroSeconds)
{
	(void)Instance;
	(void)MicroSeconds;
	uint32 count_down = 0U;
	count_down = MicroSeconds * 40U;

	Pit_Ip_StartChannel(0, 0, count_down);
}

uint32 stop_cnt = 0U;
void LinLpuartStop(uint8 Instance)
{
	(void)Instance;
	stop_cnt+=1;
	Pit_Ip_StopChannel(0, 0);
}
uint32 test_lin_out = 0U;
/* This function called when timout event happens. */
void Switch_TimeOut(void)
{
	Lin_PduType linFrame = T_Lin_Frame[0U];
	/* Deal with timout event */
	test_lin_out+=1;
	Lpuart_Lin_Ip_TimerExpiredService(0);
	/* Send the Lin_Header Again */
	Lin_SendFrame(0U, &linFrame);
}

I would greatly appreciate any guidance or suggestions on how to resolve this issue, particularly regarding the proper configuration of the timer settings to ensure that the slave responds correctly.

Thank you for your time and assistance!

BR,

Dongxun

[dongxun]

Hi， 

I hope this message finds you well. I believe I have identified the root cause of the issue I encountered with the LIN timeout management configuration.

In the EB_Treos28 configuration, the LInResponseTimeout is set to 14. This value represents 1.4 times the bit transmission time, specifically calculated as (14/10)∗bit time(14/10)∗bit time. With a baud rate of 19200 bps, the corresponding time for generating this configuration is calculated as 1.4∗52.08 μs=73 μs1.4∗52.08μs=73μs.

Here is an excerpt of the relevant configuration code:

#ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
    2292U,           /*!< HeaderTimeoutValue in microseconds */

    73U,         /*!< ResponseTimeoutValue in microseconds for 1 byte */
#endif

In the function Lpuart_Lin_Ip_MasterRxPidByteProcess(const uint8 Instance, const uint8 Data), I noticed the following logic:

        else if (LinCurrentState->RxSize > 0u)
        {
        #if (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF)
            #ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
            LinCurrentState->TimerCounting = TRUE;
            /* Call notification to start timer for Lpuart instance and configure timeout value. The Master node will receive Response frame */
            LPUART_LIN_IP_START_TIMER_NOTIFICATION(Instance, UserConfig->ResponseTimeoutValue * (uint32)(LinCurrentState->RxSize));
            #endif
        #endif /* (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF) */
            LinCurrentState->CurrentNodeState = LPUART_LIN_IP_NODE_STATE_RECV_DATA;
        }

The timer is initially set for 73 μs∗9 bytes=657 μs73μs∗9bytes=657μs. After this point, the LIN driver state transitions to LPUART_LIN_IP_NODE_STATE_RECV_DATA, where it waits for the slave's data response. However, I originally set the timer to account for 657 , \mu s for the response time of the 9 bytes, which is clearly incorrect. The actual timeout management should be 73 μs∗9 bytes∗8 bits=5256 μs73μs∗9bytes∗8bits=5256μs.

To address this, I propose modifying the LPUART_LIN_IP_START_TIMER_NOTIFICATION callback function as follows:

void LinLpuartStart(uint8 Instance, uint32 MicroSeconds)
{
	(void)Instance;
	(void)MicroSeconds;
	uint32 count_down = 0U;
	count_down = MicroSeconds * 40U * 8U;
	pit_data.swtich_notificatio_cnt +=1;  /* The Start notification shall be called many times which depends on the times of sending frames */
	Pit_Ip_StartChannel(0, 0, count_down); 
}

BR,

dongxun

[danielmartynek]

Hello @dongxun,

This is a known issue that has been fixed since RTD 5.0.0.

I'm sorry for the inconvenience caused by it.

Best regards,

Daniel