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:查询启用 DAR 后 CAN 自动重新传输行为

Guru**** 2988510 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1663128/am263p4-q1-inquiry-about-can-automatic-retransmission-behavior-when-dar-is-enabled

器件型号: AM263P4-Q1

我们目前正在开发板上评估 CAN 通信、但遇到了根本原因不清楚的问题。 我们非常感谢您的反馈和分析。

测试设置和观察结果如下:

  • CAN0、CAN1 和 CAN2 在同一总线上从外部连接在一起以执行环回测试。
  • CAN0 由 Core0-0 控制、而 CAN1 和 CAN2 由 Core1-1 控制。
  • 以下 CAN ID 每 5ms 发送一次:
    ID 通道
    ----------------------------
    0x600 CAN0
    0x500 CAN1
    0x400 CAN2
    0x1C006000 CAN0
    0x1C005000 CAN1
    0x1C004000 CAN2
  • 在监控总线流量时、仅 缺少应从 CAN1 传输的扩展 ID 0x1C005000。
  • 如果只有 CAN0 和 CAN1 连接在一起、则 0x1C005000 被正确发送。
  • 如果只有 CAN1 和 CAN2 连接在一起、则  不发送 0x1C005000。
  • 如果我们在 MCAN_initOperModeParams():initParams.darEnable = true;-> false 中更改以下设置;
  • 即使 CAN0、CAN1 和 CAN2 在同一总线上连接在一起、也会成功发送 0x1C005000。

我的理解是,当自动重传被禁用时 (darEnable = TRUE),失去仲裁的 CAN 帧可能不会重传。 因此、如果多个 CAN 控制器同时开始传输、则总线上可能永远不会出现优先级较低的消息。

这种理解是否正确?

如果是、您能解释为什么扩展 ID 0x1C005000 只 受影响? 我们期望仲裁会影响任何优先级较低的消息、但在本例中、始终缺少这个特定的扩展 ID。

我们使用的是 MCU+ SDK AM263Px 版本 9.2.00.56。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Imaoka、

    是、当启用 DAR(禁用自动重新传输)(darEnable = TRUE) 时、丢失仲裁的帧 不会自动重新传输。 TRM 确认:“在 DAR 模式下、所有传输在 CAN 总线上启动后都会自动取消“、这意味着一旦 Tx 缓冲区失去仲裁、其待处理的请求将被清除并丢弃消息 1.

    设置 darEnable = FALSE (DAR 位= 0) 将启用自动重新传输、允许丢失仲裁的消息重试、直至成功 2.

    为什么只有 0x1C005000 受到影响

    该行为与 CAN 仲裁规则以及特定的时序和拓扑相一致:

    扩展 ID 的优先级分析:

    ID 优先级(较低=较高) 直接通信
    0x1C004000 最高 CAN2
    0x1C005000 中间 CAN1
    0x1C006000 最低 CAN0

    关键观察结果: CAN1 和 CAN2 都由 Core1-1 控制、这意味着它们的 5ms 传输触发器可能非常紧密同步。 当两者都尝试同时传输时:

    1. 0x1C004000 (CAN2) 始终在 0x1C005000 (CAN1) 的仲裁中胜出、因为它具有数值较小的 ID。
    2. 启用 DAR 后、CAN1 上的仲裁丢失会导致 0x1C005000 永久丢弃 —不会重试。
    3. 这每 5ms 周期重复一次、因此 0x1C005000 绝不会 到达总线。

    为什么 0x1C006000 (CAN0) 不会受到类似的影响: CAN0 在不同的内核 (Core0-0) 上运行、引入足够的时序偏移、以至于它不会在完全相同的瞬间与 CAN2 的传输发生冲突。

    为什么它仅适用于 CAN0+CAN1: 如果总线上没有 CAN2、则没有更高优先级的扩展 ID 在仲裁中优于 0x1C005000(来自 CAN0 的 0x1C006000 具有较低优先级)  。

    其他问题:多核 MSG_RAM 访问

    由于 CAN1 和 CAN2 共享 Core1-1、因此这在您的情况下不是问题。 但是、如果在内核之间拆分 CAN 外设、请注意并发 MSG_RAM 访问需要 SPINLOCK IP 来在内核之间进行仲裁、以防止数据损坏 3.

    建议

    1. 如果您的应用需要 DAR 模式、请错开 CAN1 和 CAN2 的传输时序(甚至~1ms 的微小偏移)、以避免持续的仲裁冲突。
    2. 如果消息传递至关重要、则设置 darEnable = FALSE 为允许自动重新传输—这是默认的硬件行为、也是实现可靠 CAN 通信的标准方法 4.
    3. 使用 MCAN_TXBCF 寄存器进行验证:您可以通过检查取消完成的位来确认仲裁丢失 — 如果设置了CFx 但未设置 TOx、则帧因仲裁丢失而中止 1.

    后续: 您是否检查了 CAN1 上的 MCAN 协议状态寄存器 (MCAN_PSR) 或 Tx 缓冲区取消完成寄存器 (MCAN_TXBCF)、以确认 0x1C005000 是否确实丢失仲裁、而不是由于其他原因(例如,您的 Core1-1 任务中的时序或调度问题)而无法传输?


    1. AM263Px TRM - MCAN DAR 模式
    2. AM263Px TRM - CCCR 寄存器 DAR 位
    3. E2E:多核 MCAN 外设使用
    4. E2E:仲裁失败后自动重传

    此致、

    Zackary Fleenor