SNIP_CLASSIC_LIN_SECTION_7_1_2_1_3_Status_check

7.1.2.1.3 Status check [SWS_LinIf_00030] ⌈The LIN Interface shall determine the status of the LIN Driver module by calling the function Lin_GetStatus earliest after the maximum frame length and latest when the next schedule entry is due.⌋ It is up to the LIN Interface module’s implementer to find an efficient way to determine the status check of the LIN Driver. The normal implementation would be that the status is checked within each LinIf_MainFunction_<LinIfChannel.ShortName> function call after the maximum frame length has passed. In this case, the frame transmission is still going on (busy). Therefore the status determination shall be checked again within the next LinIf_MainFunction_<LinIfChannel.ShortName> function call (if the current LinIf_MainFunction_<LinIfChannel.ShortName> does not start a new frame, of course). The Figure 7.1 shows an example of how the frame transmission is initiated and confirmed on the bus. Figure 7.1: Lin_GetStatus call example When the status from the function Lin_GetStatus is returned and a frame is received, the following interpretation for different types of frames takes place: [SWS_LinIf_00873] ⌈If Bus Mirroring is enabled globally (configuration parameter LinIfBusMirroringSupported) and has been activated with a call to LinIf_EnableBusMirroring() for a LIN channel, the LIN Interface shall call Mirror_ReportLinFrame() each time after reading the LIN Driver’s status for an Rx slot on that channel, providing the received data when the status is LIN_RX_OK, and otherwise a NULL pointer.⌋ [SWS_LinIf_00033] Status: OBSOLETE Use instead: SWS_LinIf_00890 Upstream requirements: SRS_Lin_01502, SRS_Lin_01558 ⌈The LIN Interface shall invoke <User_RxIndication> with the received data only when LIN Interface determines the LIN Driver module’s status is LIN_RX_OK.⌋ [SWS_LinIf_00890] Limitation on invocation of LSduR_LinIfRxIndication in master nodes Status: DRAFT Upstream requirements: SRS_Lin_01502, SRS_Lin_01558, SRS_Lin_01599 ⌈The LIN Interface shall invoke LSduR_LinIfRxIndication with the received data only when LIN Interface determines the LIN Driver module’s status is LIN_RX_OK.⌋ [SWS_LinIf_00259] ⌈When the LIN Interface is receiving an Event-triggered frame and the LIN Driver module’s status is LIN_RX_BUSY or LIN_RX_ERROR, the LIN Interface shall not consider the status as an error.⌋ This is considered that a collision may occur, which is handled as described in Section 7.1.1.2. The following shall apply, if none of the slave reply on the Event-triggered frame header. [SWS_LinIf_00258] ⌈When the LIN Interface has received an Event-triggered frame and determined the LIN Driver module’s status to be LIN_RX_NO_RESPONSE, the LIN Interface shall not consider this status as an error.⌋ [SWS_LinIf_00254] ⌈When the LIN Interface has determined the LIN Driver module’s status as LIN_RX_BUSY or LIN_RX_ERROR, the LIN Interface shall consider the received frame as lost. Therefore, the LIN Interface shall report the runtime error code LINIF_E_RESPONSE to the Default Error Tracer, if this frame is an Unconditional frame.⌋ [SWS_LinIf_00466] ⌈When the LIN Interface has determined the LIN Driver module’s status as LIN_RX_NO_RESPONSE, the LIN Interface shall consider the expected frame as lost. Therefore, the LIN Interface shall report the runtime error code LINIF_E_RESPONSE to the Default Error Tracer, if this frame is an Unconditional frame.⌋ If there is disturbance on the bus, the LIN Interface may have problems sending out the header. The philosophy of the ISO 17987 specifications [1] in this case is not reporting the error to upper layers. The same behavior applies also for transmitted and Slave-to-slave frames.