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.

Clearing CAN_STATUS_EWARN in return from CANStatusGet

Other Parts Discussed in Thread: TM4C123BE6PZ

So you have a controller (#1) trying to send a message when there is no other controller on the bus.  CANSTS contains a 0x43 which is what CANStatusGet returns.  Now you turn on another controller (#2), the message is sent out of #1 and now  CANSTS contains 0x48, or CAN_STATUS_EWARN | CAN_STATUS_OK.

It seems once EWARN is set, it is always set.  How do you clear it?  Is there a reason not to clear it?

I am working with a TM4C123BE6PZ using CCS 5.5, TivaLib 2.1.

  • EWARN is RO and should reset on its own.  A single message is unlikely to be enough to reset it though.

    See detection and fault confinement for an introduction to the CAN error counting process. The count up process is more rapid than the count down process so it is harder to clear an warning than it is to set it orginally. Also since CAN automatically re-transmits in case of an error a single failed messge can cause an error flag to be set but it can take hundreds to set the error count back to zero.

    A full CAN peripheral reset should clear the flag as well. You should not normally reset it since it is part of the error confinement process in the protocol.


  • Robert Adsett said:

    Great link.  I now understand CAN faults much better.  Especially why a single controller sending a message and generating many no-ack faults does not take you off bus AND how some flags clear themselves.

    I have a further question.  Say you find yourself off bus.  You are a remote system.  There is nobody to key off -> key on to reset the CAN peripheral.  Are there general rules for having a device "try again"? 

    If our target machine has an intermittent CAN bus fault, I want devices to start talking again when it clears.

    For the near term, if a device senses a bus off condition, it waits 500msec, reinitializes the CAN peripheral and driver stack.  It repeats forever until it isback on bus.  Is this a reasonable fault recovery approach?

  • Glad it was useful.

    That's the basic recovery approach I'm taking.  I do wait longer (10s), I see it as a tradeoff between repeatedly disturbing the bus if the unit does have a problem and recovery time if it is a transient condition.