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.

BOFF in CAN peripheral status register (TM4C123BE6PZ)

Other Parts Discussed in Thread: TM4C123BE6PZ

I am working on a TM4C123BE6PZ.  My CAN driver catches the BOFF bit set and logs an error to EE.  I have no evidence this has ever happened.

Is there a white paper or engineering note on what would be best to do if ever this bit is set?

What causes this bit to be set? 

Would the CAN+ or CAN- grounded or shorted produce this error? 

How about just a random static strike?  In this case, how would you clear the error and go back on bus?

  • John Osen said:
    CAN driver catches BOFF bit set - logs error to EE - have no evidence this has ever happened.

    Might that, "Can driver's catch" serve as, "some evidence."  Perhaps you may clarify...

    While we employ CAN - such detail has not landed - our humble space.  Thus - resort to standard diagnostic mode:

    a) does this happen at high bus speeds, highly loaded and/or noisy CAN bus - w/little down time?

    b) what is the frequency of occurrence?

    c) does this gremlin impact multiple boards - in different locations - at different times?

    Should those w/sacred/hidden "insider info" not respond/rescue - cannot you (relatively) quickly/easily cause CAN+ and/or CAN - to become grounded/shorted?  (thus harvest "real data" - locked to your boards/task...)

    SysCtlPeripheralReset() seems a standard means to restore - clear that/other errors... (function name from memory - you should confirm...)

  • Thanks again for the advice.  This is a cousin post to one on a processor appearing to hang due to relay toggles.

    cb1_mobile said:

    Might that, "Can driver's catch" serve as, "some evidence."  Perhaps you may clarify...

    My driver is written to save a fault to EE if any of the error bits are set in the status register.  We have looked at a handful of controllers and see no evidence that such an error has ever been recorded. 

    My main concern with this post is:  When and if the driver does see such an error, what should it do?  I believe your answer is to call SysCtlPeripheralReset, which never registered in my reading of the CAN section of the UG.

    Our USB to CAN interface, for monitoring traffic on a PC, registered CAN bus faults.  Which is why we started looking at our recorded faults for evidence of CAN bus faults.  Now we are having trouble recreating the bus faults on the test harness. Your suggestion for shorting the CAN+ and CAN- lines should test whether my error logging code even works.

    I will post results.

  • We test for such, "bus/other" faults by having an unused gpio pulse either an open collector bipolar or fet transistor. 

    This enables your complete command over the timing of the "event" - its severity (duration or number of signals impacted) and the number of such "attacks." (required to generate (or insure) that fault.)  Method works so well for us that we've implemented multiple devices - upon small pcb - so that tests may be routinized...

    Neat that you sensed the import of verifying that error logging code - before launching into further detail...