• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 678 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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

John Osen
Genius 3585 points
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.

  • 0
    Guru 27665 points

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

    See http://hem.bredband.net/stafni/developer/CAN.htm#Error 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

  • 0 in reply to Robert Adsett
    Genius 3585 points

    Robert Adsett said:
    http://hem.bredband.net/stafni/developer/CAN.htm#Error detection and fault confinement

    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?

  • 0 in reply to John Osen
    Guru 27665 points

    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.

    Robert