• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 33 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM263P4-Q1: AM263P4 MCAN RX Interrupt Triggering Continuously Even Without CAN Traffic

Rapeti Sravanthi
Prodigy 195 points

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: AM263P4

Hi Team,

I am working on MCAN implementation on the AM263P4 LaunchPad with the following configuration:

  • Nominal Bit Rate: 1 Mbps
  • Data Bit Rate: 4 Mbps (CAN FD)
  • MCAN Instance: MCAN3
  • RX Interrupt routed to Line 36 ( R5FSS0_CORE0_INTR_MCAN3_MCAN_LVL_INT_0 )
  • TX Interrupt routed to Line 37 (R5FSS0_CORE0_INTR_MCAN3_MCAN_LVL_INT_1)

For testing, I am using PCAN-View to transmit CAN FD frames.

No data is being transmitted from PCAN-View, and no valid CAN frames are being received by the AM263P4. However, the RX ISR is triggering continuously.

During debugging, I observed the following:

  1. The MCAN_IR register has multiple interrupt flags enabled after power-on reset (POR).
  2. We are attempting to clear the ARA bit in MCAN_IR during initialization, but it does not appear to clear. The bit remains set when observed through the CCS Memory Browser.
  3. Only the required RX-related interrupts are routed to Interrupt Line 0 and TX-related interrupts are routed to Interrupt Line 1.The ARA interrupt is not routed to either interrupt line.Despite this, the RX ISR continues to trigger repeatedly even when there is no CAN traffic on the bus.

 

  1. Is it expected for the ARA bit in MCAN_IR to remain set after writing a '1' to clear it?
  2. Can a pending ARA condition cause continuous interrupt generation even when it is not mapped to any interrupt line and what causes teh interrupt ARA to occur do we need to do any other configurations?

I have attached screenshots showing:

  • TX interrupt configuration
  • RX interrupt configuration
  • MCAN_IR register contents showing the ARA bit status as 1 even though it is being cleared explicitly.

WhatsApp Image 2026-06-13 at 12.31.50 PM (1).jpeg

WhatsApp Image 2026-06-13 at 12.31.50 PM (2).jpeg

WhatsApp Image 2026-06-13 at 12.31.50 PM.jpeg

WhatsApp Image 2026-06-13 at 12.31.53 PM (1).jpeg

Regards,
Sravanthi R.

  • 0
    TI__Mastermind 33633 points

    Hi Sravanthi,

    Your continuous RX ISR triggering is most likely caused by the ARA (Access to Reserved Address) interrupt being enabled in the MCAN_IE register (bit 29, ARAE), even though you believe it's not routed to an interrupt line. Here's why the ARA bit won't clear and why your ISR keeps firing:

    Finding 1: MCAN_INTR_SRC_RES_ADDR_ACCESS (ARA) is Being Explicitly Disabled — But the Problem is in MCAN_RXINTR_MASK_ALL

    From Screenshot 3 (App_mcanEnableIntr, lines 331–344), your interrupt configuration is:

    MCAN_enableIntr(gMcanBaseAddr, MCAN_RXINTR_MASK_ALL, (uint32_t)TRUE);
    MCAN_enableIntr(gMcanBaseAddr, MCAN_INTR_SRC_RES_ADDR_ACCESS, (uint32_t)FALSE);
    /* Select Interrupt Line 0 */
    MCAN_selectIntrLine(gMcanBaseAddr, MCAN_RXINTR_MASK_ALL, MCAN_INTR_LINE_NUM_0);
    MCAN_selectIntrLine(gMcanBaseAddr, MCAN_TXINTR_MASK_ALL, MCAN_INTR_LINE_NUM_1);
    /* Enable Interrupt Line */
    MCAN_enableIntrLine(gMcanBaseAddr, MCAN_INTR_LINE_NUM_0, (uint32_t)TRUE);
    MCAN_enableIntrLine(gMcanBaseAddr, MCAN_INTR_LINE_NUM_1, (uint32_t)TRUE);

    You are correctly attempting to disable the ARA interrupt enable. However, from Screenshot 1 (lines 40–41), your MCAN_RXINTR_MASK_ALL is defined as:

    #define MCAN_RXINTR_MASK_ALL (MCAN_IR_RF0W_MASK | MCAN_IR_RF0L_MASK | \
    MCAN_IR_RF1W_MASK | MCAN_IR_RF1L_MASK | \
    MCAN_IR_EP_MASK | MCAN_IR_BEU_MASK | \
    MCAN_IR_TFE_MASK)

    Critical observation: Your custom MCAN_RXINTR_MASK_ALL includes MCAN_IR_EP_MASK (Error Passive) and MCAN_IR_BEU_MASK (Bit Error Uncorrected). These are error-state interrupts, not RX data interrupts. If the CAN bus is in an error state (which is very likely if no termination resistor is present or no other CAN node is active), these flags will assert continuously and drive Line 0 active without pause.

    Finding 2: Memory Browser Shows MCAN_IR = 0x20000000 — This is the ARA Bit

    From Screenshot 2, the Memory Browser at address 0x52638250 shows:

    0x52638250: 20000000 1FFFFFFF 06A00800 00000003 ...

    Address 0x52638250 corresponds to MCAN3's IR register (CFG_IR, offset 0x050). The value 0x20000000 means bit 29 is set, which is the ARA (Access to Reserved Address) flag.

    The adjacent value 0x1FFFFFFF at 0x52638254 is the MCAN_IE register — and 0x1FFFFFFF means bits 0–28 are all enabled in the interrupt enable register. Notably, bit 29 (ARAE) appears cleared, which is consistent with your explicit FALSE call. However, the ARA condition in IR is still asserted and not clearing.

    This confirms:

    1. The ARA flag is stuck set — the underlying condition persists
    2. The MCAN_IE value of 0x1FFFFFFF enables a very broad set of interrupts including error interrupts that are likely firing due to bus-off or error passive conditions

    Finding 3: Message RAM Configuration is Inside #if(0) Block

    From Screenshot 3 (lines 352–363):

    MCAN_initMsgRamConfigParams(msgRAMConfigParams);
    #if(0)
    /* Configure the user required msg ram params */
    msgRAMConfigParams->lss = APP_MCAN_STD_ID_FILTER_CNT;
    msgRAMConfigParams->lse = APP_MCAN_EXT_ID_FILTER_CNT;
    msgRAMConfigParams->txBufCnt = APP_MCAN_TX_BUFF_CNT;
    ...
    msgRAMConfigParams->rxFIFO0Cnt = APP_MCAN_FIFO_0_CNT;
    msgRAMConfigParams->rxFIFO1Cnt = APP_MCAN_FIFO_1_CNT;

    This is a significant issue. Your message RAM configuration parameters are wrapped inside a #if(0) block, meaning they are compiled out and never executed. Only MCAN_initMsgRamConfigParams() is called, which initializes the struct to default values — but your actual application-specific buffer counts, FIFO sizes, and filter counts are never applied. This means MCAN_msgRAMConfig() (line 292) is called with default/zero parameters, which almost certainly results in invalid or zero-sized message RAM regions, directly causing the persistent ARA (Access to Reserved Address) condition you are observing.

    Finding 4: MCAN_clearIntrStatus Called After MCAN_setOpMode(NORMAL) — Too Late

    From Screenshot 2, line 304:

    MCAN_clearIntrStatus(0x52638250, 0x20000000);
    /* Take MCAN out of the SW initialization mode */
    MCAN_setOpMode(gMcanBaseAddr, MCAN_OPERATION_MODE_NORMAL);

    The interrupt status clear is placed before the transition to normal mode, which is reasonable sequencing. However, because the message RAM is misconfigured (Finding 3), the ARA condition re-asserts immediately once the module begins operating in normal mode.

    Required Fixes — Prioritized

    Fix 1 (Critical): Remove the #if(0) Around Message RAM Configuration

    This is the most likely root cause of your ARA condition. Change:

    MCAN_initMsgRamConfigParams(msgRAMConfigParams);
    #if(0)
    msgRAMConfigParams->lss = APP_MCAN_STD_ID_FILTER_CNT;
    msgRAMConfigParams->txBufCnt = APP_MCAN_TX_BUFF_CNT;
    msgRAMConfigParams->rxFIFO0Cnt = APP_MCAN_FIFO_0_CNT;
    // ...
    #endif

    To:

    MCAN_initMsgRamConfigParams(msgRAMConfigParams);
    /* Configure the user required msg ram params */
    msgRAMConfigParams->lss = APP_MCAN_STD_ID_FILTER_CNT;
    msgRAMConfigParams->lse = APP_MCAN_EXT_ID_FILTER_CNT;
    msgRAMConfigParams->txBufCnt = APP_MCAN_TX_BUFF_CNT;
    msgRAMConfigParams->txFIFOCnt = APP_MCAN_TX_FIFO_CNT;
    msgRAMConfigParams->txBufMode = MCAN_TX_MEM_TYPE_BUF;
    msgRAMConfigParams->txEventFIFOCnt = APP_MCAN_TX_EVENT_FIFO_CNT;
    msgRAMConfigParams->rxFIFO0Cnt = APP_MCAN_FIFO_0_CNT;
    msgRAMConfigParams->rxFIFO1Cnt = APP_MCAN_FIFO_1_CNT;

    Ensure this is done while CCCR.INIT = 1 and CCCR.CCE = 1 (i.e., before calling MCAN_setOpMode(NORMAL)).

    Fix 2 (Important): Remove Error Interrupts from MCAN_RXINTR_MASK_ALL

    Your current definition routes MCAN_IR_EP_MASK and MCAN_IR_BEU_MASK to Line 0 (RX ISR). These will fire continuously if the CAN bus has no termination or no active second node. Redefine to include only true RX events:

    // Before (includes error interrupts — problematic):
    #define MCAN_RXINTR_MASK_ALL (MCAN_IR_RF0W_MASK | MCAN_IR_RF0L_MASK | \
    MCAN_IR_RF1W_MASK | MCAN_IR_RF1L_MASK | \
    MCAN_IR_EP_MASK | MCAN_IR_BEU_MASK | \
    MCAN_IR_TFE_MASK)
    // After (RX data events only):
    #define MCAN_RXINTR_MASK_ALL (MCAN_IR_RF0W_MASK | MCAN_IR_RF0L_MASK | \
    MCAN_IR_RF1W_MASK | MCAN_IR_RF1L_MASK | \
    MCAN_IR_TFE_MASK)

    If you need to handle error conditions, route them to a separate error ISR on Line 1 or handle them by polling.

    Fix 3 (Recommended): Clear All Interrupt Flags Before Enabling Interrupts

    After fixing the message RAM configuration, add a full IR register clear before enabling interrupt lines:

    /* Clear all pending interrupt flags before enabling lines */
    MCAN_clearIntrStatus(gMcanBaseAddr, 0xFFFFFFFFU);
    /* Then enable interrupt lines */
    MCAN_enableIntrLine(gMcanBaseAddr, MCAN_INTR_LINE_NUM_0, (uint32_t)TRUE);
    MCAN_enableIntrLine(gMcanBaseAddr, MCAN_INTR_LINE_NUM_1, (uint32_t)TRUE);

    Fix 4 (Recommended): Verify Bus Termination for PCAN-View Testing

    If testing with PCAN-View as the only other node, ensure:

    • 120Ω termination resistors are present at both ends of the CAN bus
    • The AM263P4 LaunchPad CAN transceiver is enabled (your code does call mcanEnableTransceiver() at line 98 — verify the GPIO logic is correct for your hardware)
    • PCAN-View is configured for CAN FD with matching bit rates (1 Mbps nominal, 4 Mbps data)

    Without proper termination, the CAN controller will enter error passive or bus-off state, continuously asserting error interrupt flags.

    Citations:

    1. MCU+ SDK AM263Px MCAN Driver API Guide
    2. MCU+ SDK AM263Px MCAN Driver API Guide
    3. AM263Px TRM - MCAN Register Description (CFG_IE)
    4. AM263Px Datasheet - MCAN Interrupt Requests Table
    5. AM263Px TRM - MCAN CFG_ILS Register
    6. AM263Px Datasheet - MCAN Module Clocking Requirements
    7. FAQ: AM263P4 Issues with Peripheral Initialization via CCS Gel Files

    Best Regards,

    Zackary Fleenor