• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 127 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.

AM263P4-Q1: Inquiry About CAN Automatic Retransmission Behavior When DAR Is Enabled

Imaoka Daisaku
Intellectual 430 points

Part Number: AM263P4-Q1

We are currently evaluating CAN communication on our development board and have encountered an issue whose root cause is unclear. We would appreciate your feedback and analysis.

The following test setup and observations were made:

  • CAN0, CAN1, and CAN2 are externally connected together on the same bus to perform a loopback test.
  • CAN0 is controlled by Core0-0, while CAN1 and CAN2 are controlled by Core1-1.
  • The following CAN IDs are transmitted every 5 ms:
    ID Channel
    -------------------------
    0x600 CAN0
    0x500 CAN1
    0x400 CAN2
    0x1C006000 CAN0
    0x1C005000 CAN1
    0x1C004000 CAN2
  • When monitoring the bus traffic, only the extended ID 0x1C005000, which should be transmitted from CAN1, is missing.
  • If only CAN0 and CAN1 are connected together, 0x1C005000 is transmitted correctly.
  • If only CAN1 and CAN2 are connected together, 0x1C005000 is not transmitted.
  • If we change the following setting in MCAN_initOperModeParams():initParams.darEnable = TRUE; -> FALSE;
  • then 0x1C005000 is transmitted successfully even when CAN0, CAN1, and CAN2 are connected together on the same bus.

My understanding is that when automatic retransmission is disabled (darEnable = TRUE), a CAN frame that loses arbitration may not be retransmitted. Therefore, if multiple CAN controllers start transmission at the same time, a lower-priority message may never appear on the bus.

Is this understanding correct?

If so, could you please explain why only the extended ID 0x1C005000 is affected? We would expect arbitration to impact any lower-priority message, but in our case only this specific extended ID is consistently missing.

We are using MCU+ SDK AM263Px version 9.2.00.56.

  • 0
    TI__Mastermind 40903 points

    Hi Imaoka,

    Yes, when DAR (Disable Automatic Retransmission) is enabled (darEnable = TRUE), frames that lose arbitration are not automatically retransmitted. The TRM confirms: "In DAR mode all transmissions are automatically cancelled after they started on the CAN bus" — meaning once a Tx Buffer loses arbitration, its pending request is cleared and the message is discarded 1.

    Setting darEnable = FALSE (DAR bit = 0) enables automatic retransmission, allowing messages that lose arbitration to retry until successful 2.

    Why Only 0x1C005000 Is Affected

    The behavior is consistent with CAN arbitration rules combined with your specific timing and topology:

    Priority analysis of your extended IDs:

    ID Priority (lower = higher) Channel
    0x1C004000 Highest CAN2
    0x1C005000 Middle CAN1
    0x1C006000 Lowest CAN0

    Key observation: CAN1 and CAN2 are both controlled by Core1-1, meaning their 5ms transmission triggers are likely very tightly synchronized. When both attempt to transmit simultaneously:

    1. 0x1C004000 (CAN2) always wins arbitration over 0x1C005000 (CAN1) because it has a numerically lower ID.
    2. With DAR enabled, the lost arbitration on CAN1 causes 0x1C005000 to be permanently discarded — no retry occurs.
    3. This repeats every 5ms cycle, so 0x1C005000 never reaches the bus.

    Why 0x1C006000 (CAN0) is not similarly affected: CAN0 runs on a different core (Core0-0), introducing enough timing offset that it doesn't consistently collide with CAN2's transmission at the exact same instant.

    Why it works with only CAN0+CAN1: Without CAN2 on the bus, there is no higher-priority extended ID to beat 0x1C005000 in arbitration (0x1C006000 from CAN0 is lower priority).

    Additional Concern: Multicore MSG_RAM Access

    Since CAN1 and CAN2 share Core1-1, this is less of a concern in your case. However, if you ever split CAN peripherals across cores, be aware that concurrent MSG_RAM access requires the SPINLOCK IP for arbitration between cores to prevent data corruption 3.

    Recommendations

    1. If your application requires DAR mode, stagger the transmission timing of CAN1 and CAN2 (even a small offset of ~1ms) to avoid persistent arbitration collisions.
    2. If message delivery is critical, set darEnable = FALSE to allow automatic retransmission — this is the default hardware behavior and the standard approach for reliable CAN communication 4.
    3. Verify with MCAN_TXBCF register: You can confirm arbitration loss by checking the Cancellation Finished bits — if CFx is set without TOx being set, the frame was aborted due to lost arbitration 1.

    Follow up: Have you checked the MCAN Protocol Status register (MCAN_PSR) or the Tx Buffer Cancellation Finished register (MCAN_TXBCF) on CAN1 to confirm whether 0x1C005000 is indeed losing arbitration versus failing to transmit for another reason (e.g., a timing or scheduling issue in your Core1-1 task)?

    1. AM263Px TRM - MCAN DAR Mode
    2. AM263Px TRM - CCCR Register DAR Bit
    3. E2E: Multicore MCAN Peripheral Usage
    4. E2E: Automatic Retransmission After Arbitration Loss

    Best Regards,

    Zackary Fleenor