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.

[参考译文] DRA821U-Q1:在 Linux 中发送或接收带 ACK 错误的 CAN FD 帧

Guru**** 2466550 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1467731/dra821u-q1-send-or-receive-can-fd-frames-in-linux-with-ack-error

器件型号:DRA821U-Q1

工具与软件:

各位专家、您好!

对于定制电路板、我们使用 TJA1462作为 canfd 收发器、使用 Linux SDK  10_01_08_01中的默认 dts。 此外、它可以发送和接收 CAN 帧、正常。 但是、我无法从总线发起和接收任何 CAN FD 帧、并显示内核错误消息"检测到数据相位错误"。  ACK 错误"。

我使用以下命令配置 main_mcan0:

ip link set main_mcan0 down
ip link set main_mcan0 type can bitrate 500000 dbitrate 2000000 fd on berr-reporting on
ip link set main_mcan0 up

并使用以下命令发送 canfd:

cansend main_mcan0 143##1AAAAAAAAA

实际上、我会看一下相应 Linux SDK 文档中的所有内容。  

我检查了 MCAN MCAN_PSR 寄存器、还发现了 ACK 错误。

如何调试? 谢谢

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

    您好!

    CAN-FD 可以发送64位的倍数、而传统 CAN 可以发送8位的倍数。 您是否可以尝试"cansend main_mcan0 143##1AAAAAAAAAAAAAA"而不是"cansend main_mcan0 143##1AAAAAAAAAAAAAAAA"、其中少一个?

    此致、

    Takuma

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

    感谢您的答复。 是的、我的错误是忘记检查文档中的命令。 我重新检查后发现它可以发送 FD 消息、但无法从外部接收 FD 消息。 外的 FD 设备的发送者可以用独木舟工作。 和当前错误消息、如:

    Protocol error in Arbitration fail
    Data phase error detected

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

    您好!

    从错误消息中、我怀疑问题与仲裁有关。 也许仲裁比特率(由命令中的"比特率"参数设置)与发送方的仲裁比特率不同?

    作为一个实验、如果您的电路板上有多个 CAN 端口、那么您可以执行环回、并使用完全相同的参数设置两个 CAN 端口、但一个将发送、另一个将接收。

    此致、

    Takuma

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

    我很抱歉在春节假期这么晚才作出回应。 是的、我们的板上有多个 CAN 端口。 我直接连接两个 CAN 端口、都可以发送和接收、但不能在网络上与其他端口一起工作。 例如 、还有另外两个 CAN FD 节点:节点1:STM32 F103、节点2:带有 MCP2518FD 的 RPI4。 我们的电路板和 RPI 启动时、使用相同的命令(在我之前的帖子中)可以接收到 RPI4通过 STM32发送的相同 CAN FD 消息、但我们的命令无法接收。 此外、还有有关该问题的更多信息:

    1.如果我们的板以标准 CAN 模式运行,就能正常工作

    2.如果我们的板以 FD 模式运行,而 STM32板继续发送 FD 帧而不停止:

       1)我们的电路板报告有关填充错误的错误、但可以在几十秒或几百秒内长时间接收一个帧

      2)如果我们电路板的链路断开,我们的电路板可以接收一些 FD 帧采样正常,然后输入1)场景,当我重新连接电路板的链路到网络。

     此问题始终可以重现。

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

    您好!

    我懂了。 目前我在出差、因此无法在板上进行测试。 我将在下周回来进行实验。

    同时、您能否在实验期间分享为标准 CAN 模式设置的比特率以及 CAN FD 模式设置的数据比特率+仲裁比特率?

    此致、

    Takuma

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

    我使用命令:

    ip link set main_mcan0 up type can bitrate 500000 dbitrate 2000000 restart-ms 1000 berr-reporting on fd on

    用于我们的电路板和 RPI (改用 CAN0)。 因此、数据比特率应该为2000000、仲裁比特率应该为500000

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

    您好!

    您能否分享为标准 CAN 模式设置的比特率、而不是使用 CAN-FD?

    为什么我问,是有一个实验,我想让你尝试。 本实验将比特率设置为与比特率相同、并将其设置为与您在标准 CAN 模式下使用的任何速率相同的速率。

    例如、如果对标准 CAN 模式使用以下比特率:

    • IP 链路设置 MAIN_MCAN0类型 CAN 比特率500000

    然后、对于 CAN-FD 模式、请尝试设置为:

    • ip link set main_mcan0 up type can bitrate 500000 dbrate 500000 restart-ms 1000 berr-reporting on FD on

    这两个命令在功能上应该相同。

    但在任何情况下、我都想知道您要针对标准 CAN 模式进行哪些测试。

    此致、

    Takuma

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

    我使用命令"ip link set main_mcan0 up type can bitrate 500000 dbrate 500000 restart-ms 1000 berr-reporting on FD on"对我们的电路板测试 FD 模式、并使用样本参数配置其他两个 FD 节点、然后所有三个节点都可以成功地相互通信。

    看来我们的主板通常无法接收信息,而不是50万个小鸟

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

    您好!

    似乎我们的主板无法正常接收消息、而不是50万个小鸟

    您能再做一次试验吗?

    对于所有三个节点、请将 CAN-FD 配置为:

    • ip link set main_mcan0 up type can bitrate 200000 dbrate 500000   restart-ms 1000 berr-reporting on FD on

    然后、测试是否可以进行通信。

    这样、我们应该能够判断问题是 由于其他节点的 最大速率约为500kb/s、还是由于仲裁进程从较低频率(200kb/s)过渡到较高频率(500kb/s)所致。

    此致、

    Takuma

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

    根据您的建议,我测试了以上大多数比特率,发现只有 RPI 可以与我们的板工作正常,所以,我开始怀疑 STM32发送器和 SPI 接收器,并发现问题是采样点不匹配作为其用户手册,它是0.75,但我们的板和 rpi4与默认采样点0.875。 那么、我将电路板的采样点更改为0.75、这样三个节点都可以正常运行。

    虽然仍有一个奇怪的地方、即 rpi4可以 在默认采样点0.875处使用采样点0.75的器件运行、但我们的电路板却无法运行。