• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 611 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2634-Q1: AM263X CAN bus error handling

Tim Clarke
Prodigy 70 points
Part Number: AM2634-Q1

Hi,

I am adapting our CAN stack that was implemented on the 49C micro.

in this stack, we setup Auto Bus On when the CAN bus goes into an idle state:

    //
    // setup Auto Bus On and delay time (in clock cycles - default is 0h)
    //
    CAN_setAutoBusOnTime(CANA_BASE, 0UL);
    CAN_enableAutoBusOn(CANA_BASE);

We are currently using SDK 8.4.17.

When the CAN peripheral detects and error, is their can ISR handler that has to be created or will the code jump to an undefined location and possibly sit idle or reset the micro?

We need some help with doing proper CAN bus error handling.

Thanks in advance.

  • 0
    TI__Mastermind 29388 points

    Hi Tim,

    Sri Vidya will respond soon.

    Thanks,
    Frank

  • 0 in reply to Frank Livingston
    TI__Expert 7586 points

    Hi Tim

    Apologies for the delay.

    Currently the bus off error is not handled in the SDK and there is no plan to add this feature as it is configured mostly in the application side.

    The main error handling is to clear the MCAN INIT bit, when Bus Off State is detected. The procedure to do it in the application is described in this below document.

    m_can_an004_v1-0_busoff_recovery_handling.pdf

    Regards

    Sri Vidya

  • 0 in reply to Sri Vidya Gunturi
    TI__Expert 7586 points

    Hi Tim

    By going through the same document, I have gathered the following points related to SDK.

    1. In the document it is mentioned that, the Busoff state is reported by PSR.BO. 

    So we can set interrupt for the bus off error by configuring MCAN_IR_BO_MASK of the Register MCAN_IE. The SDK already has API for this MCAN_enableIntr(gMcanBaseAddr, MCAN_INTR_MASK_ALL, (uint32_t)TRUE); Make sure you are setting the MCAN_IR_BO_MASK also for configuring the interrupt.

    This Bus Off status can be viewed from the PSR Register using this API:  MCAN_getProtocolStatus

    2. To restart CAN operation, the application software needs to clear CCCR.INIT.
    After CCCR.INIT is cleared, the M_CAN’s CAN state machine waits for the completion of the Busoff Recovery Sequence according to CAN protocol (at least 128 occurrences of Bus Idle Condition, which is the detection of 11 consecutive recessive bits).

    CCCR.INIT in register addendum:

    For Other Error Handing techniques Please refer to TRM. One more feature I came accross was DAR, this is described in the TRM:

    Regards

    Sri Vidya

  • 0 in reply to Sri Vidya Gunturi
    Prodigy 70 points

    Hi Sri,

    How does the CAN peripheral detect repeated Stuff errors?

    Do you have a flowchart or sequence of events?

    Our firmware is able to recover from short of the differential lines on the bus.  However, the firmware is not able to recover from repeated Stuff errors on the bus.

    We would like to know how the peripheral would detect this issue and report it.

    Thanks.

    Tim

  • 0 in reply to Tim Clarke
    TI__Expert 7586 points

    Hi Tim

    Could you please elaborate on what errors are you getting?

    Thanks & Regards

    Sri Vidya

  • 0 in reply to Sri Vidya Gunturi
    TI__Expert 7586 points

    Hi Tim

    Could you please share the protocol status register value when the CAN goes into this idle state?

    Are other processes are being performed when this happens or does the whole device goes into an error state?

    Regards

    Sri Vidya