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.

[参考译文] RM46L852:即使禁用了硬件重新传输、引导加载程序也会卡在重新传输环路中。

Guru**** 2393275 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/970560/rm46l852-bootloader-gets-stuck-in-retransmit-loop-even-though-hardware-re-transmit-is-disabled

器件型号:RM46L852

我们有任何使用 TI CAN 引导加载程序示例作为 CAN 引导加载程序基础的应用。 当我们向器件发送第一条消息、并在 CAN 总线上接收到识别器件的返回确认消息时、器件会开始快速重复发送相同的消息、并且永不停止、这是一个问题。 我们确实会反复观察到2个填充错误、而不是同一条消息。

我们在启用和禁用硬件重发送的情况下进行了测试:

CANREG1->CTL = 0x000000000000U | 0x00000020U | 0x00021443U; // IE0和 IE1都是1*/

CANREG1->CTL = 0x000000000000U | 0x000000000000U | 0x00021443U; // IE0和 IE1都是1*/

但这并没有改变行为。 我们已经检查了总线上的阻抗、它大约为56-58欧姆。

奇怪的是、当我们在同一个基于 Hercules 的器件上运行应用代码时、这种情况永远不会发生。 所有卡都使用相同的时钟、1MHz 的 CAN 总线速度、我发现唯一不同的设置是引导加载程序上的中断设置:

CANREG1->INTMUXx[0U]=0x00000011U

在应用中:

CANREG1->INTMUXx[0U]= 0x00000000U

是否有任何可能导致此问题的软件设置、我不知道或可能错过了这些设置?

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

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

    您好!

    带有引导加载程序的 CAN 节点(将其定义为节点#1)正在等待来自另一个节点的消息(将其定义为节点#0)。 CAN 节点#1是数据消息接收器、CAN 节点#0是发送器。 禁用 CAN 节点#1的重传特性(使用引导加载程序)不会影响 CAN 节点#0的重传。

    节点#1 (带引导加载程序)是否在接收到正确的数据(消息帧138.077398)后发送 ACK 位? 在 CAN 节点#0从节点#1接收到 ACK 位后、它应该发送一条新消息。  

    如果 ACK 正确,则问题可能是由节点#0中的代码引起的。

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

    重复发送消息的节点是节点#1、它是其重复发送的 ACK、因此我接收触发 ACK 的数据包、并从该点起反复返回 ACK、不会停止。 节点#1是节点 I 禁用重新传输打开、这就是我提出此问题的原因。

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

    在我看来、数据为"00 06 00 01 00 01"的消息是由节点#1有意传输的。 只有当错误发生或仲裁丢失时才会触发重新传输。  

    您可以共享您的引导加载程序代码吗? 示例引导加载程序不会将数据传输到其他 CAN 节点。

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

    我的结果是我们做了一些我认为不符合 CAN 协议立场的事情,我很抱歉在原来的帖子中没有提到这一点。 我们在总线上有两个器件正在进行更新、两个引导加载程序都使用相同 ID 的消息进行回复。 这会导致仲裁问题、从而导致该结果。 我们将通过更改每个器件的 ACK ID 来修复它。