Hi @杨工,
Based on the screenshot you posted, LIN_FRAMERESPONSE_RX indicates that the master node will receive the response part of a LIN frame. When configured as a subscriber for a specific frame ID, the node sends the Break + Sync + PID header and then listens for the Data + Checksum from the slave.
If the slave does not send anything, the master will not terminate the frame on its own. Any subsequent call to Lpuart_Lin_Ip_SendFrame() will return STATUS_BUSY. The application is responsible for terminating the transfer.
The RTD LIN driver provides a Lin Frame Timeout feature for exactly this situation. If you enable it in the configuration tool and implement the timer notifications (LinLpuartStartTimerNotification / LinLpuartStopTimerNotification), calling Lpuart_Lin_Ip_TimerExpiredService() on timeout expiry will return the driver state to IDLE.
As a quick diagnostic, you can call Lpuart_Lin_Ip_TimerExpiredService() or even Lpuart_Lin_Ip_GoToIdleState() directly from the application whenever Lpuart_Lin_Ip_SendFrame() returns STATUS_BUSY, to confirm this is the root cause before wiring up the full timer mechanism.
Regards,
Daniel
