3 Firmware

The LIN Responder generates firmware that handles all the frame processing and timing routines. It also allows users to create custom callbacks for error handling and processing of the received or transmitted data.

3.1 Frames Configuration

An Nx5 array is generated in lin_config.c based on the user-defined frames’ configuration in the UI, where N is the number of frames. It includes information about the frame ID, type, size in bytes, signals and response time-out. The user must not directly modify this table.

Signal values can be updated anytime using the write APIs, and can be read using the read APIs. The signals for subscribe type frames are automatically updated after every successful reception.

3.2 Frame Processing

The frame processor handles Break and Sync character detection, PID validation, data and checksum transmission/reception, and error checking, as shown in the state machine below.

Figure 3-1. Frame Processor State Machine

The frame processor can operate in either Blocking or Non-Blocking mode depending on the selected mode in the UI:

  • Non-Blocking Mode—This is a purely interrupt-driven implementation. The different frame processing states are handled in the background after the LIN Responder initialization function is called.

  • Blocking Mode—In the Blocking or polling-based mode, all the frame processing states are handled within the LINRESP_Handler() function. This function must be called inside the main function’s while(1) loop.

3.3 Error Detection and Handling

The driver has the capability to detect errors for Break, Sync, PID, Checksum, Readback, Framing, Response Too Short, and No Response conditions. Frame processing will be automatically aborted once an error is detected.

For LIN 2.x nodes(1), the configured Response Error signal is automatically set whenever an error condition occurs. It is cleared by the software after the frame containing the signal has been successfully processed. There is no Response Error signal for LIN 1.x nodes(1).

Each error condition can be assigned with an error callback handler. Handlers can be assigned using the callback register APIs provided in the generated lin_responder.h header file. The callback will be executed whenever the relevant error is detected. Check out the Adding the Application Code section for a sample implementation.

Refer to the LIN Responder API Reference document to learn more about the different APIs.

Note:
  1. If no LDF is loaded in the LIN Responder GUI, a node can be identified as LIN 2.x if the selected checksum type is Enhanced, and as LIN 1.x if the checksum is Classic.

3.4 Response Timing

The response time-out value for every frame is pre-calculated based on the following formula:

Response ⁢     Timeout = 10 * ( frameLength + 1 ) * ( 1 / baudRate ) * 1.4

Whenever a valid PID is detected, timing will commence. The timer will stop after a frame is successfully processed. A time-out can take place due to either of the following conditions:

  • No Response—The node did not receive a response. This condition takes place when the node does not receive a single data byte or the checksum within the time-out period.

  • Response Too Short—The received response is shorter than expected. For example, a node is expecting eight data bytes and one checksum byte, which is a total of nine bytes. If the node receives less than nine bytes within the time-out period, a Response Too Short condition will be flagged.

3.5 Data Processing

Frame application callback registers are generated based on the configured frames in the UI. The user can assign a callback for every frame, which will be automatically executed once the frame has been successfully processed (transmitted or received without errors). A sample implementation is provided in the Adding the Application Code section.