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.

TMS320F280039: MCAN bus error masking to avoid enter Bus_Off

Part Number: TMS320F280039

Tool/software:

Hi expert,

Customer using F280039 MCAN module, would like to know is there any register that could clear all faults like CRC, ACK, etc. to avoid trigger bus-off. Or if customer wants to reach such aim, is there any ISR or configurations that could rootly prevent MCAN to enter bus-off state? 

In datasheet I found below related points but not sure:

  • Loop-back mode for self-test
  • Maskable interrupt (two configurable interrupt lines, correctable ECC, counter overflow, and clock stop or wakeup)
  • MCAN_CCCR.INIT

Could you help provide any insights?

Joyce

  • Hi Joyce,

    Integrated in the CAN protocol is automatic checks on each node to determine that the CAN bus is always in a good state and if a anomaly is detected in one of the nodes, that node is turned off so that the other nodes can continue operating.  A node if forced to enter bus off state when the error threshold of 255 is reached.  A transmission error increments the error counter by 8 counts and one count for other errors. If total error reaches 255, then the transmitting node will be put in bus off so the other nodes will have a chance to claim the CAN bus through arbitration so that other nodes will have a chance to communicate.  In CAN, a node will have the priority to control the CAN bus if it wins arbitration.  Lower addressed nodes will have priority in claiming the bus.  Only the node that gets priority will transmit and that node will keep on transmitting unless an ACK signal is received from any of the nodes.  If there are transmission errors and the node is not put on bus off, then that node which has the priority or control over the CAN bus will keep transmitting indefinitely giving no chance for the other nodes to transmit their data.  This is the primary reason why a node is put on bus off state and it cannot be masked.

    The proper approach should be to determine the cause of the errors in the first place.  Customer should inspect error and LEC registers to determine what is the predominant error occurrence and address them first.

    Regards,

    Joseph