[参考译文] AM2432：CRC 错误和帧超时

你（们）好、 建宇  

您是否可以共享从 INT 到 OP 的两种方案的 pcap 文件

此致

Pratheesh

除 42-44 之外的所有节点均为 AM2432

全部 #define ENABLE_MULTIAL_SM_ACCESS_IN_SINGLE_DATARO   0

e2e.ti.com/.../26_5F00_datagram_5F00_0.zip

节点 46 和 106 是 #define ENABLE_MULTIAL_SM_ACCESS_IN_SINGLE_DAPLATHER   0

e2e.ti.com/.../24_5F00_datagram0_5F00_2_5F00_datagram1.zip

节点 46 和 106 是 #define ENABLE_MULTIAL_SM_ACCESS_IN_SINGLE_DAPLATHER   0

24_datagram0_2_datagram1.zip

您意味着 enable_multiple_SM_ACCESS_IN_SINGLE_DAPLATHER 在此处设置为 1 — 对吗？ ESC 寄存器 0x2 使用了哪个版本的 PRU 固件？ 将检查在此 pcap 中看到的 LRD 故障。

您表示 enable_multiple_SM_ACCESS_IN_SINGLE_DAPLATHER 在此处设置为 1 — 对吗？

是的。 版本为 ind_comms_sdk_am243x_09_01_00_03

您好、

是的。 版本为 ind_comms_sdk_am243x_09_01_00_03

根据上述主题的讨论、我相信您是从  ind_comms_sdk_am243x_11_00_00_13 中选择了 EtherCAT 固件的？ 对于固件版本、您也可以读取 ESC 寄存器空间中的前 4 个字节

此致、
Aaron

版本为 0x532。 我们将其恢复、因为它似乎与旧版本兼容。

根据上述主题的讨论、我相信您已经从  ind_comms_sdk_am243x_11_00_00_13 中挑选了 EtherCAT 固件？

我们已切换回此版本并于昨晚进行了测试。 测试设置为 86 个驱动器、其中 23 个驱动器为 AM2432。

帧超时如下所示。

CRC 错误

  如果 enable_multiple_SM_ACCESS_IN_SINGLE_DAPLATHER 设置回 0、帧超时和 CRC 错误将在 3 天内为 0。

您好、建宇：

感谢您提供详细信息。 请注意、 仅在 EtherCAT 主设备进行以下访问的情况下才会设置 enable_multiple_SM_ACCESS_IN_SINGLE_DATAG电报：

• 使用来自单个子设备的 LRD/LWR 命令访问多个 FMMU 映射区域的单个数据报
• LRW 访问多个子器件的非交错输入和输出过程数据

因为我们的产品是通用伺服驱动器。 我们无法提前知道我们的客户是否使用 Omron 或 H5U 或任何其他 EtherCAT 主站。 因此、我们希望采用一种可支持所有 EtherCAT 主站的设置。

已测试 0x542 版本。 仍然存在 CRC 错误和帧超时

感谢您发送编修。

将在线进一步讨论上述问题。

此致、
Aaron

您好、

是否有任何关于该问题的更新？

您好、建宇：

如前所述、我们是否可以获得 针对 Omron and Innovance PLC 进行的测试更新（降低了 TX_START_DELAY (0x48) 以及最新的 EtherCAT 固件 (0x0542)

如果您有 Wireshark 日志以及上述测试配置、请提供 ICSSG0 存储器转储 (0x30000000 至 0x30040000)。

此致、
Aaron

如前所述、请使用提供的补丁进行测试、该补丁修复了 链路中断场景中的 TX_START_DELAY 错误。

此致、
Aaron

不工作。 重新连接电缆后、所返回帧中的 WKC 值似乎为 0

e2e.ti.com/.../pru544.zip

再次在节点 1 (XMC4800) 和 2 (AM2432) 之间捕获帧、LRW 命令的 WKC 为 3、OUT 为 0。

ARMW 的 WKC 表示输入直流时间同步帧为 1、输出为 2。

e2e.ti.com/.../reconnect_5F00_1_5F00_2.zip

您好、建宇：

感谢 Wireshark 捕获和状态。

从日志中确认的一点是、您没有观察到 LRW 帧的格式错误的数据包。 这可以确认在链路断开且子器件返回网络时、正确调整了延迟。

基于您共享的日志观察到的几个结果：

1.  
   • 我看到在 reconnecte.pcapng 文件中、frame# 5622 是 LRW 返回 WKC 为 3 的最后一个帧、这可能表明第二个设备网络断开。
   • 在第 5624 帧中、返回帧具有 WKC 6、这表明第二个设备返回网络。
   • 我看到返回 LRW 帧的 WKC 为 6、直至第 5720 帧。
2.  
   • 在第 5716 帧中、第二个器件位于 SAFEOP 中。
   • 在第 5620 帧中、主设备将第二个设备的状态更改为 init、这意味着它不会处理 LRW 帧。

几个后续问题：

1. 您是否在 pru544.zip 中同时使用 AM243x 作为这两个子器件？
2. 主设备 Innovance H5U PLC 吗？
3. 是否可以共享重新连接的器件的 ICSSG 存储器转储 (0x30000000 至 0x30040000)？
4. 我能否详细了解主设备为何将第二个设备设置为初始化状态？

我还将查看 reconnect_1_2.zip 、然后再回来联系您。

此致、
Aaron  

您好、建宇：

另外、我还附加了测试过的日志、以确保在发生链路中断时正确补偿延迟： e2e.ti.com/.../SOEM_5F00_test_5F00_run_5F00_0x544_5F00_link_5F00_break.zip

从第 2235 帧到第 5022 帧、第二台设备脱离网络、即在第 2234 帧断开链路、并在第 5023 帧连接并返回网络。 从第 5023 帧开始、第二个器件会处理传入帧并使 WKC 递增。  

此致、
Aaron  

在 reconnect_1_2.zip 中、需要进行调查。 CRC 和对齐错误位被置位、需要进一步检查。

AM243x 的传入帧将 LRW WKC 设置为 3、将 BRD WKC 设置为 1、预期返回帧应将 LRW WKC 设置为 6、将 BRD WKC 设置为 2、但在这种情况下、LRW WKC 会被清除、看起来不会处理 BRD。 我们需要进一步研究这一点。 如果可能、您能否提供完整的日志、即从网络初始化到此行为。

此致、
Aaron  

您好、建宇：

我想在这里了解的是、一旦断开的设备重新连接回网络、主设备就会建立恢复机制。 我看不到主设备发出的 reconnect_1_2.zip 状态转换命令。 这是了解主设备行为所必需的。

如前所述、在 pru544.zip -> reconnecte.pcapng 中、主设备将第二个器件的状态更改为 在 FRAME# 5620 处初始化、之后观察到 CRC 错误位：

pru544.zip 提供 2 个驱动器的初始化过程。

为了阐明捕获这些日志的环境、两个 zip 文件中的驱动器是否相同？ 此外、两个 zip 文件中的主设备是否相同？ 我问的原因是、在 pru544.zip -> reconnect.pcapng 中、我只看到“ CRC 错误 “位正在设置、但在 reconnect_1_2.zip 中、我看到“ 对齐错误 “和 CRC 错误 “位。

此致、
Aaron

• 您是否在 pru544.zip 中同时使用 AM243x 作为这两个子器件？
• 主设备 Innovance H5U PLC 吗？
• 是否可以共享重新连接的器件的 ICSSG 存储器转储 (0x30000000 至 0x30040000)？
• 我能否详细了解主设备为何将第二个设备设置为初始化状态？

1.已提及

在节点 1 (XMC4800) 和 2 (AM2432) 之间再次捕获帧、

2.是的

3.它在文件扩展名为 dat 的 zip 文件中

4、不知道。 我们只能从软件包中找到线索。

这次、H5U -> CAP 通道 1 ->驱动器 1 (xmc4800)-> CAP 通道 2 ->驱动器 2 (AM2432)

e2e.ti.com/.../init_5F00_reconnect_5F00_0_5F00_1_5F00_2.zip

快速查看时、重新连接第二个驱动器时出现#40533。 WKC 正确增加到 6。

#40725 PLC 尝试重新启动将 0x120 设置回初始化的通信。 在该帧之后、wkc 由 AM2432 复位为 0。

您好、建宇：

这次、H5U -> CAP 通道 1 ->驱动器 1 (xmc4800)-> CAP 通道 2 ->驱动器 2 (AM2432)

init_reconnect_0_1_2.zip

感谢您提供此日志和 ICSS 存储器转储。

快速查看、#40533 是第二个驱动器重新连接的时间。 WKC 正确增加到 6。

是、正确。 这是我之前报告的观察结果、在这里也可以看到。

在此帧之后、wkc 通过 AM2432 复位为 0。

如果主器件在向子器件（此处为 AM243x）发出 INIT 后未清除 FMMU、则会发生这种情况。

在重新连接 (reconnecte.dat) 和 Wireshark 日志后检查存储器转储后、我可以看到 FMMU 和 SyncManager 寄存器未清除：

如果 FMMU (0x600 - 0x67F) 和 SyncManager (0x800 - 0x83F) 未清除、则会观察到 PDO 传输的异常行为。

您好、建宇：

此外、如果您设置  ENABLE_MULTIAL_SM_ACCESS_IN_SINGLE_DAT电报（即将 TIESC_PORT0_TX_DELAY_200_MMHz_clock 设置为 0x98 (760ns))、您能否确认是否观察到此问题？

为了提高清晰度、请确保 应用程序中的 TIESC_PORT0_TX_DELAY_200_MHz_clock 为 0x98、然后执行链路中断和链路重新连接活动、观察 EtherCAT 主设备是否将重新连接的器件设置为 init、然后清除 FMMU 和 SM 寄存器？

此致、
Aaron  

如果 FMMU (0x600 - 0x67F) 和 SyncManager (0x800 - 0x83F) 未清除、则会观察到 PDO 传输的异常行为。

我假定这是一个您需要修复的错误。 如 init_reconnect_0_1_2.zip 中所示、#3017 将驱动器设置为 Init、#3189 将 FMMU 复位。 这似乎是 H5U 在奴隶之间建立沟通的方式。

e2e.ti.com/.../twincat_5F00_reconnect.zip

这是使用 TwinCAT 捕获的另一个软件包。 它会在启动时清除 FMMU。 重新连接时、它甚至不会费心重置 FMMU。

在 TwinCAT 中、在 TwinCAT 将 AM2432 复位为初始化#37693 后、WKC 计数正确。 它会在#54901 中再次更新 FMMU

您好、建宇：

我们通过从 reconnect_1_2.zip 日志回放 Wireshark 帧来重现此行为。 我们确实了解了为什么 LRW WKC 在 EtherCAT 固件中获取的值为 0、以及在 ESL 中设置 CRC 和对齐错误位的原因。

我们正在进行优化修复、以便在各种情况下处理此类边缘情况。

感谢您的耐心。

此致、
Aaron