• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 34 subscribers
  • Views 2873 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.

CAN bus off handling

Richard Burke
Expert 1910 points
Other Parts Discussed in Thread: TMS570LS1227

Hello,

We recently performed EMC testing on a TMS570LS1227 where ESD was injected onto the CAN lines and an issue was raised.

It appears that the CAN bus went bus off but then did not recover. We have set the ABO (Auto-bus-on Enable) bit to 1 and ABOTR (Auto-Bus-On Timer Register) to 0. We plan in future to make the ABOTR value a configurable item.

Are there any issues setting ABOTR to 0? Can you think of any other reasons why the CAN bus might not recover from bus-off?

Regards,
Richard 

  • 0
    TI__Guru 68180 points

    Richard,

    At the moment, I'd recommend not using the ABOTR / ABO feature at all.   In researching your question, I noticed that the Bosch User's Guide for this IP (which we licensed from Bosch semiconductor) doesn't document ABO or ABOTR.  (http://www.bosch-semiconductors.de/en/ubk_semiconductors/safe/ip_modules/d_can/d_can.html).    Until we run down why this is not documented, I'd be cautious and not use it.  

    Editorial comment:   While we do license the DCAN IP from Bosch, the TI version of DCAN has some additional features as compared to the above referenced spec.  Therefore it is important to use the TI DCAN TRM chapter and not the above Bosch spec as the authorative reference for this IP as it exists on Hercules products.

     

  • 0 in reply to Anthony F. Seely
    Expert 1910 points

    Hi Anthony,

    So to clarify you are recommending that we don't set ABO but manually reset the init bit when bus-off occurs?

    Would it be possible to clarify the operation of auto bus-off?

    Thanks,

    Richard

  • 0 in reply to Richard Burke
    TI__Guru 68180 points

    Richard,

    There's not enough information in our documentation to answer your question (is a count of 0 ok?).

    Additionally, there are some notes with respect to auto-bus on that make it look a little tricky.   For example, writing to the CAN control register while the auto-bus on sequence is counting will terminate the bus-on - meaning you have to recover with the CPU anyway.

    If it were my project at given this I'd probably go with a CPU controlled bus-on sequence. 

    We've started the inquiry to get the answer on the auto-bus on feature, in the meantime.  But it may take some time to get an acceptable answer.

    Sorry I know this isn't a great answer, but it's what I'd recommend given the current information.

  • 0
    TI__Genius 13810 points

    Richard,

    I have observed this before. It turns out to be the CAN transceiver's problem. The CANHI/LO stops to respond to the CANTX signal for a short time after the ESD pulse. Power cycling the CAN transceiver will solve the problem. Can you provide the part number of CAN transceiver?

    Regards,

    Haixiao

  • 0 in reply to Haixiao Weng
    Expert 1910 points

    Hi Haixiao,
    We are currently using an isolated CAN transceiver - the schematic says IL41050TA-3E.

    Is this the part that you have experience of? Recycling the power corrected the problem in our case.

    Regards,
    Richard

  • 0 in reply to Richard Burke
    TI__Mastermind 49120 points

    Hi Richard,

    The value you program in the Auto-Bus-On Timer Register only serves to delay the auto bus-on sequence. Once this timer reaches zero (always the case if you program it to zero), the auto bus-ON sequence is triggered. This sequence requires the CAN RX line to be recessive (High) for at least 129 x 11 consecutive bit periods before resuming normal operation and clearing the error counters.

    The most likely scenario in your case is that the CAN RX input to the MCU is getting stuck low after the noise injection.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Expert 1910 points

    Thanks Sunil. We plan to do more testing and identify exactly what the problem is.

    Regards,
    Richard 

  • 0 in reply to Richard Burke
    TI__Expert 4225 points

    Hi Richard,

    you mentioned this: "Recycling the power corrected the problem in our case".

    can you please clarify if this recycling power is done only for CAN transceiver or Hercules and CAN transceiver?

  • 0 in reply to Henry Nguyen
    Expert 1910 points

    Hi Henry,
    The power was recycled on both processor  and CAN transceiver.

    There is still a slight question over whether it was the device at the other end that went bus off and stayed like that so we still need to do some further investigation.

    I'm going to be away for a couple of weeks so I won't be able to update this thread until I return.

    Regards,
    Richard

  • 0 in reply to Richard Burke
    TI__Expert 4225 points

    Hi Richard

    yes the power cycle both mcu and transceiver can not isolate where the issue is.  If you can find a way to power cycle only the transceiver that would be a good experiment to know. 

  • 0 in reply to Sunil Oak
    Prodigy 30 points

    Hi,

    Is there a possibilty that receive also fails at BUS off and we are not able to monitor 128*11 bits at RX counter?Apart from clearing the CCR BIT in the CANMC register, is there any way to avoid Bus off condition?

    Regards,

    Learner Bee

     

  • 0 in reply to Learner Bee
    TI__Expert 4225 points

    Hi Learner,

    Bus off condition occurs when your CAN line is shorted to GND for a long time.

    Your error counter has to be in 248 to 256 to cause bus off condition and thus disable your CAN by resetting the CAN INIT bit.

    One thing we noticed is that when you short your CAN H to ground, the RX pin of the transceiver will drives '1'.

    To avoid bus off condition, you have to avoid CAN H line shorting.