• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 158 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSPM0L1306: MSPM0L1306: Simultaneous LIN break-threshold AND UART framing-error detection

Zaigham Khawaja
Prodigy 10 points

Part Number: MSPM0L1306
Other Parts Discussed in Thread: MSPM0G3507

For the MSPM0L1306,
Framing-error detection is required for LIN conformance, including framing errors in the sync, PID, data, and checksum fields.
But the TRM states: "Framing errors and break conditions are not set when LIN mode is enabled."
image.png
For LIN break-threshold detection, it must be operated in LIN Mode, utilizing LINCNT, LINC0, and the following LINCTL settings, which stops the framing-error detection as the side-effect.

Newer MSPM0L devices (MSPM0L211x/122x) come with UNICOMM-UART which has an additional setting LINCTL.EN_FRM_ERR, allowing framing-error reporting during LIN operation:

image.png


But the MSPM0L1306 UART does not provide this field:
image.png

So,
How can framing-errors be detected on the MSPM0L1306 while using the LIN counter for break-threshold detection?

If simultaneous operation is not supported, what is TI’s recommended implementation for meeting both requirements?

1. Break detection with an 11-Tbit threshold
2. Framing-error detection for LIN Conformance Tests

Thanks in advance,
Zaigham

  • 0
    TI__Mastermind 26308 points

    Two choices:

    1. Using Mcal Lin

    2. Based on SDK, try to use below method:

    3. Other method: to add a delay at LIN UART Rx, then read input IO's logic.

        Delay could be CPU/Timer/LINCNT delay, input IO read could be LIN Rx connect to another IO.

    Notes: recommended to use latest SDK: C:\ti\mspm0_sdk_2_11_00_07\examples\nortos\LP_MSPM0G3507\lin

  • 0 in reply to Helic Chi
    Prodigy 10 points

    Hi Helic, thank you for the response.

    Our constraints:

    1. MCAL LIN is not an option, since we are a Tier-2 supplier.

    2. The dual-UART method requires routing the transceiver RXD to a second MCU pin. Our customer's hardware is finalized and in validation, so this is closed for us.

    3. A delayed GPIO read is a single-point sample with no qualification; not robust enough for conformance-level break detection.

    4. I also reviewed the referenced SDK example (`LP_MSPM0G3507\lin\lin_responder`). It disables the LIN counter after sync and re-enables it only at frame end, which makes FRMERR available during PID/data/checksum, right?

    But this isn't sufficient because break can appear at any time, including mid-frame (master abort, collision etc. scenarios tested in conformance), so disabling the counter during the data phase is not acceptable either.

    So,

    1. For a break arriving mid-frame while the LIN counter is disabled, the only indication is FRMERR with RX = 0x00, which corresponds to roughly 9.5 Tbit of dominant time, below the 11-Tbit break threshold. How does TI recommend qualifying such a break to the required threshold in this configuration?

    2. Does TI have a validated reference covering simultaneous break-threshold and framing-error detection on the MSPM0L1306, that handles out-of-sequence break signals?

    3. Also, the sequences in your slide are marked "need further verification." This affects our customer's product qualification, so we would appreciate TI's confirmed position.

    Best regards,
    Zaigham

  • 0 in reply to Zaigham Khawaja
    TI__Mastermind 26308 points
    Zaigham Khawaja said:
    4. I also reviewed the referenced SDK example (`LP_MSPM0G3507\lin\lin_responder`). It disables the LIN counter after sync and re-enables it only at frame end, which makes FRMERR available during PID/data/checksum, right?

    Can't guarantee the uart will operate normally during LIN frame transmission and switch LIN disable/enable mode.

    Zaigham Khawaja said:
    2. Does TI have a validated reference covering simultaneous break-threshold and framing-error detection on the MSPM0L1306, that handles out-of-sequence break signals?

    refer to Mcal demo, it uses only one UART.

    Using the same mechanism in your SDK project.

    Zaigham Khawaja said:
    3. Also, the sequences in your slide are marked "need further verification." This affects our customer's product qualification, so we would appreciate TI's confirmed position.

    This is a proposal method, since it is only not verified at TI side (I don't have that demo now), we added that mark.

    At last, recommended to refer to Mcal's mechanism.

  • 0 in reply to Helic Chi
    Prodigy 10 points

    Hi Helic, thank you for the discussion so far.

    I assume the MCAL implementation you're referring to is third-party, not TI reference code. Please confirm.


    To get a clear position for our records: is simultaneous 11-Tbit break-threshold detection and full-frame framing-error detection a known limitation of the MSPM0L1306's UART for LIN use? Given that, does TI recommend a newer device (e.g. MSPM0L211x/122x with LINCTL.EN_FRM_ERR) for applications requiring both, for a full automotive-qualified LIN stack?

  • 0 in reply to Zaigham Khawaja
    TI__Mastermind 26308 points
    Zaigham Khawaja said:
    is simultaneous 11-Tbit break-threshold detection and full-frame framing-error detection a known limitation of the MSPM0L1306's UART for LIN use

    This is given in TRM, standard UART doesn't support frame error detection when LIN is enabled.

    Zaigham Khawaja said:
    does TI recommend a newer device (e.g. MSPM0L211x/122x with LINCTL.EN_FRM_ERR) for applications requiring both, for a full automotive-qualified LIN stack?

    Device that supports Unicomm-UART.

    Zaigham Khawaja said:
    I assume the MCAL implementation you're referring to is third-party, not TI reference code. Please confirm.

    Mcal provide by TI, using a little bit complex method to get frame error detection.

    You can contact your local support team for access link.