• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1122 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: "Bus Off" state in MCAN controller

Christian Neuwirth
Prodigy 120 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: AM62P,

Tool/software:

Hi Experts:

We are using a MSPM0G3507 with a CAN interface on one of our HW design. We are applying CANopen and the firmware tries to send heartbeat messages every 2 seconds.

What I'm usually seeing when the CAN bus is in an unterminated state (for instance when no cable is connected) is that the error counter MCAN_ECR.TEC goes up to a value of 128, causing the CAN controller to enter the "Error Passive" state (MCAN_PSR.EP=1). In most cases the error counter stops there even though the firmware continues to try sending heartbeat messages.

Question 1: Why does the error counter MCAN_ECR.TEC (usually) stop incrementing at 128?

I ran into a situation once (!) in which the error counter MCAN_ECR.TEC did go higher. The value I saw was 248, but the CAN controller had entered the "Bus Off" state (MCAN_PSR.BO=1), indicating that the error counter had reached a value of 255 before I read it. I'm not sure, though, how the error counter can decrement when the CAN controller is in "Bus Off". The error counter did not decrease when I reconnected the CAN cable and terminated the bus. The only option I found to get the MCU out of this state was to reset it.

Question 2: Under which conditions does the error counter MCAN_ECR.TEC increment beyond 128?
Question 3: How can I recover from the the "Bus Off" state w/o resetting the MCU?

Basically that same questions also applies to the AM62P (running Linux), which we use at "the other end". The CAN controllers appear to be very similar (if not the same). It seems that the TRMs of neither the MSPM0G3507 nor the AM62P provide any details about this behavior.

Any help or additional documentation would be appreciated.

  • 0
    TI__Genius 9185 points

    Hi Christian,

    1. Q1 & Q2:

    I try to test the mcan_multi_message_tx_LP_MSPM0G3507_nortos_ticlang example in LP-MSPM0G3507 without any CAN transceiver connected to create bus off condition. But in my test, the first time of MCAN transfer, the MCAN_ECR.TEC will reach 248. And from the TRM, TEC support from 0 to 255.

    So could you please tell where you got the conclusion that the TEC will not increase after it reach to 128? 

    2. Q3:

    The API DL_MCAN_reset() could reset the TEC and BO status.

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points
    Pengfei Xie said:
    So could you please tell where you got the conclusion that the TEC will not increase after it reach to 128? 

    This is what I'm seeing (reproducibly) on my hardware.

    Pengfei Xie said:
    But in my test, the first time of MCAN transfer, the MCAN_ECR.TEC will reach 248.

    Why only 248? It should go up to 255, right?

    Pengfei Xie said:
    The API DL_MCAN_reset() could reset the TEC and BO status.

    Alright. I'll try that when I can get the MCU on my hardware to go into BO state once again. As I mentioned in my initial post, this happened only once up to this point.

  • 0 in reply to Christian Neuwirth
    TI__Genius 9185 points

    Hi Christian,

    Christian Neuwirth said:
    Why only 248? It should go up to 255, right?

    I think it may related with the transfer data size and struct. A bit more test needed to prove it. 

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points

    Hi Pengfei,

    a piece of additional information:

    I think the one time when I saw the MCU entre BO state when I was (mistakenly) running the firmware on a prototype board without CAN transceiver mounted. That's the same situation that you have where the error counter ends up at 248 but the CAN controller enters BO state.

    On a prototype board with CAN transceiver, I cannot get the CAN controller to increment its transmit error counter past 128 and it never enters BO state.

    Essentially I don't have a problem with that if I know that this is what the CAN controller does. I merely want to understand why and find some documentation describing this behavior.

  • 0 in reply to Christian Neuwirth
    TI__Genius 9185 points

    Hi Christian,

    Christian Neuwirth said:
    I think the one time when I saw the MCU entre BO state when I was (mistakenly) running the firmware on a prototype board without CAN transceiver mounted. That's the same situation that you have where the error counter ends up at 248 but the CAN controller enters BO state.

    Yes, what I will do is to change Bus Off condition to see whether this number will be different. And currently there is not much description about CAN bus off in TRM.

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points

    Hi Pengfei ... just wondering if you made any progress in the meantime?

  • 0 in reply to Christian Neuwirth
    TI__Genius 9185 points

    Hi Christian,

    I try to connect MSPM0 to a CAN transceiver to have CAN communication with other note. When I make the CAN Bus CANH and CANL short connect and continuously transfer data, the TEC will increase to 248 and a BusOff flag is raised. So I think the value "248" is the threshold value for BusOff in MSPM0 MCAN.

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points

    Hi Pengfei,

    Pengfei Xie said:
    When I make the CAN Bus CANH and CANL short connect and continuously transfer data, the TEC will increase to 248 and a BusOff flag is raised

    So, essentially the same thing as without CAN transceiver, right?

    Pengfei Xie said:
    So I think the value "248" is the threshold value for BusOff in MSPM0 MCAN.

    That's what I think, too. However, I'd like to see that behavior documented somewhere in TI's documentation.

    And the bigger question remains:
    Why does the CAN controller (seemingly) limit the TEC at 128 and never enter BO state when a CAN transceiver is present?

    You should be able to reproduce that scenario now.

  • 0 in reply to Christian Neuwirth
    TI__Genius 9185 points

    Hi Chris,

    Christian Neuwirth said:
    I'd like to see that behavior documented somewhere in TI's documentation.

    Sorry we do not have such a document to exactly descript the busoff behavior, but I thinks it is a standard process defined by CAN protocol. You could try to find it in the official CAN standard manual. 

    Christian Neuwirth said:
    Why does the CAN controller (seemingly) limit the TEC at 128 and never enter BO state when a CAN transceiver is present?

    No, I mean I tested by connect a CAN transceiver, and if I short connect the CAN bus, it will also enter a BO status and TEC reach to 248.

    Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points

    Hi Pengfei,

    Pengfei Xie said:
    I thinks it is a standard process defined by CAN protocol

    No, it's not. Otherwise I wouldn't ask. Even the (little) documentation that TI does provide in this context says something different:

    Pengfei Xie said:
    No, I mean I tested by connect a CAN transceiver

    If you don't short the bus and leave it open without termination, you should be able to see the same behavior that I see.

  • +1 in reply to Christian Neuwirth
    TI__Genius 9185 points

    Hi Christian,

    Christian Neuwirth said:
    Even the (little) documentation that TI does provide in this context says something different

    Here is some description from ISO 11898-1 2025 document about error counting. You could see if an error flag transferred, the TEC will be incremented by 8. (from point c). And when TEC increases to 248, it should not increase again to make TEC overflow to zero. So I think it is reasonable to keep TEC at the last counter value (248) when it increases over 255 and trigger a bus off error. 

    Christian Neuwirth said:
    If you don't short the bus and leave it open without termination, you should be able to see the same behavior that I see.

    Please see point c) exception 1, when there is a transceiver exist, in this case the CAN bus could be observed, and if other terminate note is not connected, it should get a ACK error. And when the TEC increases to 128 (MCAN change from error active to error passive), the exception 1 condition is met, so it will not increase any more. 

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 120 points

    Thx Pengfei!

    Understood. That explains the behavior and it was in the CAN spec after all.