MSPM0G3518: Inquiry regarding LIN Auto Baud Rate Configuration Parameters (MSPM0G351x MCAL)

Hi Mohamed,

Here are some answer to your questions:

1. The recommendation is to enable LinChannelAutoBaudRate for responder nodes when the commander's baud rate may drift or is not precisely known. The auto baud rate feature is a software-implemented mechanism, not a purely hardware one. As the AUTOSAR LIN Driver User Guide states: 'The auto baud rate and stop bit detection features are implemented in software, which makes them prone to errors if the ISRs are not executed in time.'

The MSPM0G351x LIN Performance Sheet includes the state 'SYNC_FIELD - RXNE (Max value where baud rate update happens, last negative edge of SYNC)' as a distinct ISR measurement. This indicates that the baud rate is recalculated on every received SYNC byte — specifically at the last negative edge of the SYNC field — and not solely during initial lock or error recovery. 

2. As mentioned in the AUTOSAR LIN Driver User Guide "LinChannelBaudRateLimit shall be configured as a baud rate limit which can be a lower/higher value than the LinChannelBaudRate. Auto-baud adjustment will happen for the frames which are received at a baudrate which falls between these two fields"

This means the two fields together define the acceptable auto-baud window. If the incoming baud rate falls outside the range between LinChannelBaudRate and LinChannelBaudRateLimit, the baud rate update does not occur and the frame is processed (or fails) at the existing locked baud rate.

Additionally, the he AUTOSAR LIN Driver User Guide mentions that "The LIN driver does not support LIN_E_TIMEOUT as the driver doesn’t wait for any status update after writing to a HW register which requires a separate timeout mechanism"

3. The threshold defines how many 2Tbit cycle deviations must be observed before a baud rate update is triggered. If the deviation across the SYNC bit measurements is less than the configured threshold (e.g., < 2 cycles with threshold = 2), the driver processes the frame using the previously locked baud rate without adjusting. The baud rate update simply does not occur for that frame cycle. This is by design to prevent spurious updates on frames where the commander is operating within tolerance. Since the auto baud rate is SW-implemented in the ISR, the SYNC field ISR latency (4.2-8.2 µs depending on optimization, per the performance sheet) is the window within which this threshold evaluation occurs

4. I would recommend to look over the Configuration Assumptions of Use in the User guide. Bellow is what it mentions:

• LIN shall be provided with 2 clock reference points from MCU module, one being the LIN peripheral clock and the other being the CPU clock, this is used for baud rate calculations and timeouts

• The system integrator should configure the CPU clock greater than the LIN Peripheral Clock. The functional tests for LIN module were run with LIN peripheral clock less than or equal to 5MHz when the CPU clock is at 80MHz. The implementation uses internal 16-bit counter which may overflow if LIN is configured at higher peripheral clock and operated at lower baud rates.

• The LIN receive pin i.e UART_RX pin configured in port module shall be configured in LinRxPinChannelId in the form of channel id

• LinChannelBaudRateLimit shall be configured as a baud rate limit which can be a lower/higher value than the LinChannelBaudRate. Auto-baud adjustment will happen for the frames which are received at a baudrate which falls between these two fields

• LinTimeoutDuration shall be used for detecting incomplete responses and flagging errors such as incomplete and no response errors by the responder node and the max duration that can be configured is 65536, it uses on-board 16-bit LIN counter

• One LIN driver provides access to one LIN hardware unit type that may consist of several LIN channels through supported LIN instances

Best Regards,

Diego Abad