<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: S32K: Assistance Required with LIN Timeout Management Configuration in S32K</title>
    <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2079479#M47713</link>
    <description>&lt;P&gt;Hi，&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;In the EB_Treos28 configuration, the LInResponseTimeout is set to 14. This value represents 1.4 times the bit transmission time, specifically calculated as &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;(14/10)∗bit&amp;nbsp;time&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;(&lt;/SPAN&gt;&lt;SPAN class=""&gt;14/10&lt;/SPAN&gt;&lt;SPAN class=""&gt;)&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bit&amp;nbsp;time&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;. With a baud rate of 19200 bps, the corresponding time for generating this configuration is calculated as &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;1.4∗52.08 μs=73 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;1.4&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;52.08&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;Here is an excerpt of the relevant configuration code:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;#ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
    2292U,           /*!&amp;lt; HeaderTimeoutValue in microseconds */

    73U,         /*!&amp;lt; ResponseTimeoutValue in microseconds for 1 byte */
#endif&lt;/LI-CODE&gt;&lt;P&gt;&lt;SPAN&gt;In the function &lt;/SPAN&gt;Lpuart_Lin_Ip_MasterRxPidByteProcess(const uint8 Instance, const uint8 Data)&lt;SPAN&gt;, I noticed the following logic:&lt;/SPAN&gt;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;        else if (LinCurrentState-&amp;gt;RxSize &amp;gt; 0u)
        {
        #if (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF)
            #ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
            LinCurrentState-&amp;gt;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-&amp;gt;ResponseTimeoutValue * (uint32)(LinCurrentState-&amp;gt;RxSize));
            #endif
        #endif /* (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF) */
            LinCurrentState-&amp;gt;CurrentNodeState = LPUART_LIN_IP_NODE_STATE_RECV_DATA;
        }&lt;/LI-CODE&gt;&lt;P&gt;The timer is initially set for &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73 μs∗9 bytes=657 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;9&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bytes&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;657&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;. 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 &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73 μs∗9 bytes∗8 bits=5256 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;9&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bytes&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;8&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bits&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;5256&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;To address this, I propose modifying the LPUART_LIN_IP_START_TIMER_NOTIFICATION callback function as follows:&lt;/P&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;LI-CODE lang="c"&gt;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); 
}&lt;/LI-CODE&gt;&lt;P&gt;BR,&lt;/P&gt;&lt;P&gt;dongxun&lt;/P&gt;</description>
    <pubDate>Mon, 14 Apr 2025 02:08:28 GMT</pubDate>
    <dc:creator>dongxun</dc:creator>
    <dc:date>2025-04-14T02:08:28Z</dc:date>
    <item>
      <title>S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2078965#M47684</link>
      <description>&lt;P&gt;Hi,&amp;nbsp;&lt;/P&gt;&lt;P&gt;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 &lt;STRONG&gt;Lin_MasterFrameTransfer_S32K312&lt;/STRONG&gt; as well as the &lt;STRONG&gt;RTD_LIN_UM&lt;/STRONG&gt;.pdf document found in &lt;STRONG&gt;Lin_TS_T40D34M20I2R0&lt;/STRONG&gt;. 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:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;When I enable Lin Frame Timeout Disable: I do not perform any response timeout management, and I can receive data normally.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&amp;nbsp;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 &lt;STRONG&gt;Pit_Ip_StartChannel&lt;/STRONG&gt; to 40MHz, which means the timing period is 1 second. Under this configuration, testing proceeds normally.&lt;/P&gt;&lt;P&gt;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:&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;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, &amp;amp;linFrame);
}&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Thank you for your time and assistance!&lt;/P&gt;&lt;P&gt;BR,&lt;/P&gt;&lt;P&gt;Dongxun&lt;/P&gt;</description>
      <pubDate>Fri, 11 Apr 2025 09:32:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2078965#M47684</guid>
      <dc:creator>dongxun</dc:creator>
      <dc:date>2025-04-11T09:32:29Z</dc:date>
    </item>
    <item>
      <title>Re: S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2079479#M47713</link>
      <description>&lt;P&gt;Hi，&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;In the EB_Treos28 configuration, the LInResponseTimeout is set to 14. This value represents 1.4 times the bit transmission time, specifically calculated as &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;(14/10)∗bit&amp;nbsp;time&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;(&lt;/SPAN&gt;&lt;SPAN class=""&gt;14/10&lt;/SPAN&gt;&lt;SPAN class=""&gt;)&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bit&amp;nbsp;time&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;. With a baud rate of 19200 bps, the corresponding time for generating this configuration is calculated as &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;1.4∗52.08 μs=73 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;1.4&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;52.08&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;Here is an excerpt of the relevant configuration code:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;#ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
    2292U,           /*!&amp;lt; HeaderTimeoutValue in microseconds */

    73U,         /*!&amp;lt; ResponseTimeoutValue in microseconds for 1 byte */
#endif&lt;/LI-CODE&gt;&lt;P&gt;&lt;SPAN&gt;In the function &lt;/SPAN&gt;Lpuart_Lin_Ip_MasterRxPidByteProcess(const uint8 Instance, const uint8 Data)&lt;SPAN&gt;, I noticed the following logic:&lt;/SPAN&gt;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;        else if (LinCurrentState-&amp;gt;RxSize &amp;gt; 0u)
        {
        #if (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF)
            #ifdef LPUART_LIN_IP_START_TIMER_NOTIFICATION
            LinCurrentState-&amp;gt;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-&amp;gt;ResponseTimeoutValue * (uint32)(LinCurrentState-&amp;gt;RxSize));
            #endif
        #endif /* (LPUART_LIN_IP_FRAME_TIMEOUT_DISABLE == STD_OFF) */
            LinCurrentState-&amp;gt;CurrentNodeState = LPUART_LIN_IP_NODE_STATE_RECV_DATA;
        }&lt;/LI-CODE&gt;&lt;P&gt;The timer is initially set for &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73 μs∗9 bytes=657 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;9&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bytes&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;657&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;. 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 &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73 μs∗9 bytes∗8 bits=5256 μs&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;73&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;9&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bytes&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;∗&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;8&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;bits&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;=&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;5256&lt;/SPAN&gt;&lt;SPAN class=""&gt;μ&lt;/SPAN&gt;&lt;SPAN class=""&gt;s&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;To address this, I propose modifying the LPUART_LIN_IP_START_TIMER_NOTIFICATION callback function as follows:&lt;/P&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;LI-CODE lang="c"&gt;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); 
}&lt;/LI-CODE&gt;&lt;P&gt;BR,&lt;/P&gt;&lt;P&gt;dongxun&lt;/P&gt;</description>
      <pubDate>Mon, 14 Apr 2025 02:08:28 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2079479#M47713</guid>
      <dc:creator>dongxun</dc:creator>
      <dc:date>2025-04-14T02:08:28Z</dc:date>
    </item>
    <item>
      <title>Re: S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2082337#M47872</link>
      <description>&lt;P&gt;Hello &lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/247897"&gt;@dongxun&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;This is a known issue that has been fixed since RTD 5.0.0.&lt;/P&gt;
&lt;P&gt;I'm sorry for the inconvenience caused by it.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Best regards,&lt;/P&gt;
&lt;P&gt;Daniel&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 17 Apr 2025 07:18:33 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2082337#M47872</guid>
      <dc:creator>danielmartynek</dc:creator>
      <dc:date>2025-04-17T07:18:33Z</dc:date>
    </item>
    <item>
      <title>Re: S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363644#M58497</link>
      <description>&lt;P&gt;Could you please tell me where the "pit_data" and "T_Lin_Frame" parameters are defined? I haven't found these variables in my project, and I'm also not sure where the "Switch_TimeOut" function is linked. Please let me know what their functions are. Thank you.&lt;/P&gt;</description>
      <pubDate>Tue, 12 May 2026 01:42:07 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363644#M58497</guid>
      <dc:creator>Aoyng</dc:creator>
      <dc:date>2026-05-12T01:42:07Z</dc:date>
    </item>
    <item>
      <title>Re: S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363650#M58498</link>
      <description>&lt;P&gt;hi, Aoyng,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&lt;SPAN&gt;T_Lin_Frame is defined in a demo file, the&amp;nbsp;complete definition is：&lt;/SPAN&gt;&lt;/P&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;LI-CODE lang="c"&gt;uint8 T_Lin_Data[3] = {0x01, 0x02, 0x03};
const Lin_PduType T_Lin_Frame[T_LIN_TEST_FRM_NUM] =
{
    {0x1A, LIN_ENHANCED_CS, LIN_MASTER_RESPONSE, 3u, T_Lin_Data}
};&lt;/LI-CODE&gt;&lt;DIV&gt;&lt;SPAN&gt;And the pit_data &amp;nbsp;is a variable that I debug myself.&amp;nbsp;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;SPAN&gt;If you want to find the demo routine, please refer to whether you have this path XXX:\NXP\SW32K3_RTD_4.4_2.0.2\eclipse\plugins\Lin_TS_T40D34M20I2R0\examples\EBT\Lin_MasterFrameTransfer_S32K312\&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;</description>
      <pubDate>Tue, 12 May 2026 01:55:10 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363650#M58498</guid>
      <dc:creator>dongxun</dc:creator>
      <dc:date>2026-05-12T01:55:10Z</dc:date>
    </item>
    <item>
      <title>Re: S32K: Assistance Required with LIN Timeout Management Configuration</title>
      <link>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363655#M58499</link>
      <description>&lt;P&gt;OK, thank you. Could you please tell me where you obtained the formula with a result of 73us? Also, what do the various parameters in this formula represent?&lt;/P&gt;</description>
      <pubDate>Tue, 12 May 2026 02:07:12 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K-Assistance-Required-with-LIN-Timeout-Management/m-p/2363655#M58499</guid>
      <dc:creator>Aoyng</dc:creator>
      <dc:date>2026-05-12T02:07:12Z</dc:date>
    </item>
  </channel>
</rss>

