AWRL6432: Can Interrupt is not fired incase of Rx Frame

Hi Mostafa,
     I have looped in our SW expert. Please allow us a day or so to respond.

Thanks and Regards,
Sivaprasad

Hey Mostafa,

First of all, what software are you using - e.g., SDK or MCAL? Also verify that you are using the latest version of the software. For the MMWAVE-L-SDK, the latest version is 5.5.3.0, and for the MCAL, the latest version is 3.0.5.0 - available through TI mySecure. 

Just to clarify, all the interrupts in the IR register will be triggered by their respective sources regardless of the IE register settings, but only the interrupts that are enabled in the IE register will trigger the NVIC to call the ISR. 

Is there a particular reason the protocol errors need to be disabled? Have you tested to see if this issue appears with PEA and or PED enabled? You can also create a separate ISR for just the protocol errors and assign that to a different interrupt line from your other interrupts. 

/* Assign MCAN instance address */
gMcanBaseAddr = (uint32_t) AddrTranslateP_getLocalAddr(APP_MCAN_BASE_ADDR);
/* APP_MCAN_BASE_ADDR generated by SysConfig CAN driver */

/* Register interrupt */
HwiP_Params_init(&hwiPrms);
hwiPrms.intNum      = 38; /* CAN interrupt line 1 */
hwiPrms.callback    = &errorMcanIntrISR; 
status              = HwiP_construct(&gMcanHwiObject, &hwiPrms);
DebugP_assert(status == SystemP_SUCCESS);

/* Enable PEA and PED */
MCAN_enableIntr(gMcanBaseAddr, (MCAN_INTR_SRC_PROTOCOL_ERR_ARB | MCAN_INTR_SRC_PROTOCOL_ERR_DATA), (uint32_t)TRUE);
/* Select Interrupt Line 1 for PEA and PED */
MCAN_selectIntrLine(gMcanBaseAddr, (MCAN_INTR_SRC_PROTOCOL_ERR_ARB | MCAN_INTR_SRC_PROTOCOL_ERR_DATA), MCAN_INTR_LINE_NUM_1);
/* Enable Interrupt Line 1 */
MCAN_enableIntrLine(gMcanBaseAddr, MCAN_INTR_LINE_NUM_1, (uint32_t)TRUE);

static void App_mcanIntrISR(void *arg)
{
    uint32_t intrStatus;

    intrStatus = MCAN_getIntrStatus(gMcanBaseAddr);
    MCAN_clearIntrStatus(gMcanBaseAddr, intrStatus);
    
    /* up to user implementation */
}

Regards,

Kristien

Hello Kristien,

Thank you for your reply and proposal, I have additional questions:

1-Why do we have protocol error ? (we didn't make busoff or any defect to the bus)

2-Even if having protocol Error why the Can interrupt is not fired anymore ?

Hey Mostafa,

There are a couple of reasons that may cause protocol errors. Listed below are a few notes on design needs or possible error causes, though I would recommend reviewing the following application note on CAN physical requirements:

• Both ends of the CAN line should be terminated with a 120 ohm resistor between the CAN low and CAN high lines to prevent reflections from impedance mismatching
• There must be isolated common ground for the bus to prevent noise injection
• Ensure the bus length does not exceed the supported baud rate
  • The High-Speed ISO 11898 Standard specifications are given for a maximum signaling rate of 1 Mbps with a bus length of 40 m with a maximum of 30 nodes. It also recommends a maximum unterminated stub length of 0.3 m
    
• Incorrect baud rate
  • This can either be from a mismatch in the bit timing parameters or caused by tolerances in the reference CAN clock
  • In the case of the latter, note that different bit timings will require different clock tolerances

If the CAN interrupt is no longer firing, this could potentially be caused by the NVIC failing to be reset after interrupts are serviced. You can check for whether the NVIC is properly being reset by checking address 0xE000E200 or 0xE000E280 which corresponds to the NVIC Interrupt Set-Pending Register and NVIC Interrupt Clear-Pending Register respectively.

Immediately before entering the ISR, the 21st bit of these registers should be set to - i.e., 0x00200000 mask - which corresponds to external interrupt number 21 which is CAN interrupt line 0 (the 22nd bit would be for CAN interrupt line 1). By the end of the ISR, the 21st bit should be reset back to 0. 

If this isn't the case, this would imply that the ISR did not clear the NVIC interrupt, though this should be handled automatically. This can be manually done by adding the HwiP_clearInt function: HwiP_clearInt(37U). Note: 37 is the absolute number for CAN interrupt line 0.

Regards,

Kristien