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.

AWR1843: CANFD Bus Off interrupts vs Bus Off protocol status

Part Number: AWR1843

While trying to use two devices on the same CAN bus, I noticed that the device runs into data protocol errors and eventually goes into bus off state.  However, I am not getting the bus off interrupt to my error callback function.  Is the bus off interrupt in MCAN_IR tied to the PSR bus off status, or should I poll PSR bus off to determine the bus state?

SDK 03.04.00.03

Thanks

  • Could you tell us which application you are trying here?

    And make sure that errInterruptEnable=1 and appErrCallBack callback function are provided in CANFD_MCANInitParams structure during CANFD_init driver function call.

    Regards,

    Jitendra

  • Hi Jitendra,

    This is based on the demo application.  appErrCallBack is working properly for other errors (PROTCOL_ERR_DATA_PHASE and PROTOCOL_ERR_ARB_PHASE).  But when I get BUS_OFF state in the PSR register (which I can verify by calling CANFD_getOptions with CANFD_Option_MCAN_PROTOCOL_STATUS), I don't get the CANFD_Reason_BUSOFF error reason in my callback.  

    Another question I have: if MCAN goes into BUS_OFF state in PSR, what is the correct way to teardown and re-initialize the MCAN/CANFD module?  

    Thanks

  • Hi Jovial,

    Let me discuss this internally and get back to you by this week to provide a solution for this CAN error issue.

    Regards,

    Jitendra

  • To recover from the BUSOFF mode , the MCAN IP need to be put in NORMAL/operation mode

     

    static void MCANAppErrStatusCallback(CANFD_Handle handle, CANFD_Reason reason, CANFD_ErrStatusResp* errStatusResp)

    {

        int32_t                 errCode;

        

        if(reason == CANFD_Reason_BUSOFF)

        {

            gErrStatusInt++;

            CANFD_BusOffRecovery(handle, &errCode);

        }

       

        

        return;

    }

     

    int32_t  CANFD_BusOffRecovery(CANFD_Handle handle,  int32_t* errCode)

    {

        CANFD_DriverMCB*                ptrCanFdMCB;

        uint32_t                        baseAddr;

         int32_t                         retVal = 0;

        

        ptrCanFdMCB = (CANFD_DriverMCB*)handle;

        if ((ptrCanFdMCB == NULL) )

        {

            *errCode = CANFD_EINVAL;

            retVal = MINUS_ONE;

           

        }

       

        baseAddr = ptrCanFdMCB->hwCfg.regBaseAddress;

        /*Check if the busoff status and also the Error counter*/

       

        /* Put MCAN in opertional mode */

        MCAN_setOpMode(baseAddr, CANFD_MCANOperationMode_NORMAL);

     

        /* Wait while MCAN is not in operational mode. TODO add timeout */

        do

        {

        } while (MCAN_getOpMode(baseAddr) != CANFD_MCANOperationMode_NORMAL);

       

        return retVal;

    }

  • Hi Jitendra,

    Thank you for the detailed code snippet.  I will test it out on my side.

    My other question still remains: is there a link between the MCAN_PSR Busoff bit and the MCAN_IR Bus off bit?  My understanding is the MCAN_IR is what triggers the MCAN callback function, so if the MCAN_PSR Busoff bit is set, will the MCAN_IR see Bus off set?

    Best

  • Here is the figure snapshot for CAN interrupt tologoy (from AWR1843 TRM), where Bus-off interrupt is routed to DCAN0INT, so you it should arrive at error-callback function.

    Regards,

    Jitendra

  • Hi Jitendra,

    Thank you for the reference.  Which TRM revision is this diagram from?  I can't find it in the revision E AWR1843 TRM (from this link https://www.ti.com/lit/pdf/swru520 on the AWR1843 product page).

  • Nevermind - I found this diagram in rev E, it is now Figure 22-13.  I will look at this section in more details and see if I can figure out why I cannot see the bus off interrupt.