• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 221 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.

MSPM0G3507: 'Break Error' or 'Framing Error' detection is not working

Dhaval Patel
Prodigy 15 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

I tried to set a breakpoint inside the break-error interrupt, but it never triggered. The receive function is working, but I’m getting an error in PLIN VIEW PRO saying “slave not responding,” which means the TX is not working.

Additionally, I am using the ATA663211 transceiver, and the connections are made with the MSPM0G3507 controller like below. Is this correct? Because in the linked project (www.ti.com/.../slaaek9.pdf, the connections are crossed — TX to RX and RX to TX.

TX (ATA663211) → TX (PA0 – MSPM0G3507)
RX (ATA663211) → RX (PA1 – MSPM0G3507)

I have also attached my configuration(syscfg) file's screenshots.

Currently, I have connected:Screenshot 2025-11-14 143924.pngScreenshot 2025-11-14 143615.pngScreenshot 2025-11-14 143555.pngScreenshot 2025-11-14 143522.pngScreenshot 2025-11-14 143456.png

  • 0
    TI__Genius 10455 points

    Hi Dhaval,

    As I checked the datasheet of ATA663211, the TX in this device means transfer data from end point to LIN bus, so I think it does not need cross connection between ATA663211  and MSPM0.

    And the 'Break Error' or 'Framing Error' are the error related to UART "receive" process, as you said the receive function is normal, so there is not break or framing error reported.

    As for the "transmit" process, could you measure the waveform on the TX pin? One of my guess is that PA0 and PA1 is open-drain pins in MSPM0, if you do not add a pull-up resister on TX pin, it may not normally output high-level signal.

  • 0 in reply to Pengfei Xie
    Intellectual 453 points

    Hi Pengfei,

    Thank you for your answers!

    Pengfei Xie said:
    And the 'Break Error' or 'Framing Error' are the error related to UART "receive" process, as you said the receive function is normal, so there is not break or framing error reported.

    Based on my experience with other microcontrollers (e.g., Microchip PICs), the break error interrupt and the framing error interrupt are used to detect the start of a LIN frame.
    Although the break error interrupt and, optionally, the framing error interrupt are enabled here in the sysconfig, neither the break nor the framing error interrupt is triggered when a LIN message is received. 
    Neither the break field, i.e., 13 or 14 consecutive zeros, nor the sync byte 0x55 is recognized by an interrupt, even though it is displayed by a logic analyzer, i.e., it is actually present. 

    Only the first actual byte containing the PID and the following data byte is recognized.

    Pengfei Xie said:
    As for the "transmit" process, could you measure the waveform on the TX pin? One of my guess is that PA0 and PA1 is open-drain pins in MSPM0, if you do not add a pull-up resister on TX pin, it may not normally output high-level signal.

    The TX pin was permanently low. I know that TX is active low.
    Following your advice, the TX pin was provided with an internal pull-up (in sysconfig). Now the pin is high, as it should be.
    However, sending frames in response to an INFO frame still does not work.

    Thanks a lot in advance,

    Matze

  • 0 in reply to Matze
    TI__Genius 10455 points

    Hi Matze,

    So you mean actually your did not get the complete receiving frame in MCU, so the transmission logic is not even get triggered right?

    As for the break and frame error, actually they are disabled in LIN mode, please refer  MSPM0 G-Series 80-MHz Microcontrollers Technical Reference Manual (Rev. C) for details.

    In MSPM0, a LIN slave break is detected by a falling edge, and will start a counter to record break time. There is a LIN response example in our SDK, could you try with our example for the LIN communication?

  • 0 in reply to Pengfei Xie
    Prodigy 15 points

    Hi Pengfei,

    I have created a completely new project with no interrupts or additional functionality and tried to toggle only the PA0 pin under both options: LIN0 UART mode and GPIO mode. I also manually set the pin to both logic levels (0 and 1) for verification. Additionally, we connected a logic analyzer directly to the PA0 pin, and we confirmed that the pin is not toggling under any of these conditions.

  • 0 in reply to Pengfei Xie
    Prodigy 15 points

    Hi Pengfei,

    I would like to connect the LIN transceiver ATA663211 to the PINs PA0 (TX) and PA1 (RX). The RX path is working. The TX path is permanently low. This is due to the internal pull-down of the ATA663211 on the one hand and the configuration of the PA0 pin of the MSPM0G3507 on the other. I am unable to configure the PA0 pin as push-pull in SysConfig. The pin is configured as open drain by default. Can you explain what I need to set in SysConfig to configure the pin as push-pull? Or is this not possible and I need to use a different UART0-TX pin?

    If this is not possible with PA0, I would use PIN PA28, which is configured as “High-Drive” by default, for the TX path.
    Can you explain to me what I need to set in SysConfig to use this pin as push-pull?

  • 0 in reply to Dhaval Patel
    TI__Genius 10455 points

    Hi Dhaval,

    The PA0 and PA1 is open-drain IO in MSPM0. So it could not output as high, and also no internal pull-up resistor. A external pull-up needed if you want to use this pin.

    For other pins (such as PA28), you could configure pull-up function as below: