[参考译文] AM2432：IND-COMMS-SDK：ICSSG1 上 EtherCAT 子设备的三路缓冲器似乎已损坏

尊敬的 Martin：

感谢您提供上述详细信息。

ICSSG1 上的 EtherCAT 子设备具有 修订版/类型：x0690,内部版本：x0542,固件版本：6.5.66

在使用较旧的 EtherCAT 固件时、比如版本 6.5.54（来自 ind_comms_sdk_am243x_11_00_00_13） 或 6.5.50（来自 ind_comms_sdk_am243x_09_00_02_24）、您 是否会遇到类似的问题？

另外、请告知我们与您分享的最新 EtherCAT 固件的状态。

此致、
Aaron

您好 Aaron、

我们切换到了 6.5.66,因为我们希望这可以解决这个问题,我们以前使用了 6.5.54。 在某些时候  ,我们使用 6.5.50,但我不再记得为什么我们改变了  6.5.54.

总结：
6.5.54 和 6.5.66 也有同样的问题。
对于 6.5.50、 我不知道。

此致、
Martin

尊敬的 Martin：

总结如下：
6.5.54 和 6.5.66 也有同样的问题。
对于 6.5.50 、我不知道。

感谢您的澄清。 我们将查看 可能导致此类行为的 PRU 实现中的特定部分。

此致、
Aaron

尊敬的 Martin：

另一个问题、我能否获得有关测试环境的更多详细信息？ 与使用的 EtherCAT 主设备一样、它的配置、拓扑或您认为可以帮助我们更快地重现问题的任何其他细节 ？

此致、
Aaron

您好 Aaron、

我已经给你写了一封电子邮件。 但是、您可以随时询问更多详细信息。

此致、

Martin

谢谢 Martin。 将查看您提供的详细信息。

此致、
Aaron

您好 Aaron、

很抱歉我反应迟来了,但我上周生病了。  

目前我们有 3 个测试设置：

设置 1 的拓扑：


设置 2 和 3 的拓扑：

2 和 3 之间的区别在于 EtherCAT 子器件（= EtherCAT 耦合器）上连接了不同的模块、即 PDO 数据大小不同。

安装程序 1 最常产生错误、但安装程序 2 过去也产生过几次错误。

几天前,可悲的是设置 1 现在再次产生了错误的 FW  6.5.72.我附上了 Wireshark 日志 (1)。 这实际上是我们遇到的帧重复错误。 帧为 0 的错误可能是不相关的、我们至少之前从未见过。

在这里您可以看到数据包 76 和 86 在连接 2 之间的错误、另请参见附件 (1)：

我还附加了 Wireshark 日志 (2)、您可以在其中看到设置 1 的同步管理器配置。

 自上周星期二以来、测试设置 2 和 3 一直在运行、到目前为止未出现错误。  当前安装程序 2 具有最复杂的日志记录。

我们计划在接下来的步骤中执行以下操作：

• 将日志记录从设置 2 移至设置 1（在我们给设置 2 多一些时间之后，可能也会产生错误）、因为在设置 1 上、错误似乎更一致。 由于缺少跟踪设备、无法对所有设置进行完整的日志记录。
• 由于设置 2 也产生了错误,因此可以在没有分离器的情况下尝试设置 1 并查看是否存在差异。
• 我将发布一个项目、进行第 4 次测试设置、只需使用 AM243x Launchpad 和 EtherCAT 主设备、因此将在接下来的几小时/天内完成同步管理器设置。 但是、到目前为止、它尚未产生该误差。

正如我已经说过的,这是一个有点 困难,我们的设置非常运行经常多个星期之前发生错误,所以它可能需要相当长的时间来看到它。 目前这是巧合我,设置 1 似乎有错误后一个星期（如果我们忽略可能不相关的 0 问题）.

e2e.ti.com/.../_2800_2_2900_-setup.7z.txte2e.ti.com/.../_2800_1_2900_-fsoe_5F00_error.7z.txt

（这两个文件是 7z 文件、只是重命名为.txt 以绕过文件过滤器）

感谢您的支持。

此致、

Martin

尊敬的 Martin：

因此、我们计划在接下来的步骤中执行以下操作：

感谢您提供详细信息和后续步骤。 我遇到的一个问题是,这是看到没有 FSoE 交易吗? 我的意思是假设没有 FSoE Master、说 TwinCAT free run 是否出现了交换问题？  

帧为 0 的错误可能是不相关的、我们至少以前从未见过。

是、正确。 从您提供的日志中、根据数据报 WKC 值、子设备/节点似乎已脱离网络。

此致、
Aaron

您好 Aaron、

只需快速回答您的上一个问题：
在没有 FSoE 连接的情况下也会出现此错误。 错误基本上是、较新的数据在前一个周期中已经存在后、从一个子器件读取较旧的输入数据。 因此、如果您只使用计数器而不是 FSoE 数据包、则错误如下所示：0、1、2、3 、2、 5、6、...
我们仅使用直流同步模式测试、而不使用 FreeRun 测试。

但是, 昨天我 在“hw_EscWriteIsr ()“和“hw_EscReadIsr ()“内进行了日志记录的一个设置能够重现该错误:

• 设置为拓扑 2。
• 连接到同一总线耦合器的两个 FSoE 主设备（= EtherCAT 子设备）之间的 FSoE 连接发生错误。 这很好、因为这样我们就可以在同一子设备的输入和输出数据中看到故障的 FSoE 连接。
• 输入数据 bsp_write () 写入地址 0x2400、0x24EC 和 0x2476。
• 输出数据 BSP_READ () 从地址 0x1400、0x149C 和 0x144E 读取。
• 通常、该地址在一个常量模式中每个周期切换、例如： 0x2400、 0x24EC  、0x2476、0x2400、0x24EC 、  0x2476、 0x2400、...
• 但在输出数据中观察到错误之前（同样，在输入和输出数据中出现此特定 FSoE 连接 (0x360003590200)/(0x3600BD6B0200)) 、当输入数据通过 bsp_write () 写入时、bsp_get_proce_data_address () 连续两个周期返回相同的地址、因此模式为：0x24EC、0x2476、0x24EC 0x24EC、0x2400、0x2476、0x24EC、0x2400 0x2476、0x24EC、0x2400。
• 因此、有两件看起来有缺陷的事情：
  • 连续周期两次 0x24EC 看起来就像错误。
  • 模式从[0x2400、0x24EC、0x2476]更改为[0x2400、0x2476、0x24EC]。
• 与有问题的 FSoE 连接一起、如下所示：
  • 输入数据：
    (8) 0x2476、 0x3600BD6B0200  （最新数据包）
    (7) 0x2400、  0x3600BD6B0200
    (6) 0x24EC、0x3600BD6B0200
    (5) 0x24EC、0x3600BD6B0200
    (4) 0x2400、 0x3600BD6B0200
    (3) 0x2476、 0x360003590200
    (2) 0x24EC、0x360003590200
    我们在此处可以看到 FSoE 数据从 0x360003590200 合法更改为 0x3600BD6B0200、以及 0x24EC（有故障）重复。
  • 输出数据：
    (8) 0x1400、0x3600BD6B0200  （最新数据包）
    (7) 0x144E、 0x3600BD6B0200   
    (6) 0x149C、 0x360003590200
    (5) 0x1400、 0x3600BD6B0200
    (4) 0x144E、 0x360003590200
    (3) 0x149C、 0x360003590200
    (2) 0x1400、 0x360003590200
    此处、地址[0x1400、0x149C、0x144E]按预期运行。 但是我们可以在这里看到、当 FSoE 数据从 0x360003590200 变为 0x3600BD6B0200 时出现错误、与输入数据一样应该是平滑的（因为这基本上是刚刚由同一从器件发送到主器件后从主器件发送回从器件的输入数据）。
• 我现在非常有信心,根本原因是 bsp_get_proce_data_address () 在两个连续周期内返回相同的地址 0x24EC。 这是不是真的?“
• 下面我的原始测量做了 Saleae（解释使用逻辑 2 ）将作为照片的集合和 .Sal 文件。
• 特别是图 3 对时间/时间关系感兴趣,但我可以告诉你,没有什么 突出的。 时序看起来应该是这样的。 我们有 1ms 的 EtherCAT 总线周期时间、每次调用  PDO_InputMapping () 和 PDO_OutputMapping () 中的 hw_EscWriteIsr () 和 hw_EscReadIsr () 之间的距离约为 1ms (+- 10us )。
• 我还会附上 tiescbsp.c 文件的代码、它是来自最新 SDK 的文件。 您 为 ICSSG1 内的代码发送了新的头文件、但从不是较新的 tiescbsp.c 或 tieschw.c、希望您不要忘记。
• 我还会从最新的 SDK 附带 tieschw.c 文件。
• 如果在文件中搜索 DEBUG_FSOE_TRACE、您将看到我的日志记录位置。 此外、还预计文件中会发生一些可忽略的更改、例如头文件路径。
• 我没有用于此测试设置的 Wireshark 日志、但我认为不需要它。

总结一下、您能向我解释以下内容吗：

• 为什么 bsp_get_proce_data_address() 在两个连续周期内返回相同的地址？ 这是一个错误吗?
• 为什么 bsp_get_proce_data_address() 的实现方式是这样的、如果意图只是在 3 个地址之间交替？

附件：
Picutre 1：

图 2：


图 3：

Saleae（逻辑 2）日志：
e2e.ti.com/.../finally_5F00_bug_5F00_short2.sal.txt


tieschw.c：
e2e.ti.com/.../tieschw.c

tiescbsp.c：
e2e.ti.com/.../tiescbsp.c

感谢您的支持。

此致、
Martin

尊敬的 Martin：

感谢您提供更多详细信息。 我会回顾一下、然后由星期一回复您。

同时、是否可以从子器件侧共享 ESC 错误计数器 (0x0300 - 0x030D)、以及在发生此缓冲区切换问题时是否可以监测来自主器件侧的帧丢失或 CRC 错误？

如果数据包传输（主设备到子设备传输）出现错误、缓冲区切换可能会失败。

此致、
Aaron

您好 Aaron、

当然、我们可以再记录几件事情、但我个人怀疑帧丢失了、因为、如果您还记得以前显示相同错误的 Wireshark 日志、我们从未在 Wireshark 日志中看到任何表明帧丢失或被误解的内容。 或者您在 Wireshark 日志中发现了什么内容？
然后缓冲区切换失败发生在输入数据上（即 SubDevice --> MainDevice）  。

但是、我会将 EtherCAT 分析器移至设置 2、因此下次会因为相同的错误在同一器件上产生 Saleae 日志和 Wireshark 日志。 另外、我还将尝试记录 ESC 错误计数器和其他可能有趣的事情、现在我知道设置确实再现了错误。  

还有一些可能 对您感兴趣的其他事情：

• EtherCAT：在 SYSCFG 中、ICSSG1 内核时钟设置为 200MHz。 IEP 时钟同步已启用、因此 IEP 时钟也为 200MHz。
• SIGMATEK 自定义总线：在 SYSCFG 中、ICSSG0 内核时钟设置为 333MHz。  IEP 时钟同步已启用、因此 IEP 时钟也为 333MHz。
• 在 OP 期间、我们确实广泛使用了 VOE（供应商特定于 EtherCAT）。 因此假设除了负责 PDO 的同步管理器外、邮箱（同步管理器 0 和 1）也很忙。

感谢您的支持。

此致、
Martin

PS:因为我再次偶然发现它: 200MHz 为 ICSSG1 和 333MHz 为 ICSGG0 似乎不兼容较新的 SYSCFG 工具。 不过、据我观察、ICSSG0 为 333MHz、ICSSG1 可能默认为其他某个频率。 从之前的支持问题中、我记得 EtherCAT FW 会检测到其 Clore 时钟频率并自动适应。 这仍然是正确的、是吗？ 然而、考虑到 ICSGG0 位于 333MHz、您建议为 ICSSG1 使用哪个时钟频率？

尊敬的 Martin：

我相信您在为 ICSSG0 和 ICSSG1 使用 2 个不同的频率时收到了这个错误：

观察 PRU-ICSSG 集成图 (TRM 中的图 6-20 和 6-21)、ICSSG0 和 ICSSG1 都共享来自 PLL 块 (PLL0、PLL2) 的公共时钟源输入。

SYSCFG 约束意味着两个 ICSSG 实例必须配置为使用 相同的时钟源选择 （例如，来自 MAIN_PLL0_HSDIVX_CLKOUT 的时钟源）。

对于您的配置：
-如果 ICSSG0 位于 333MHz、则应配置 ICSSG1 以同时选择 333MHz

错误中引用的 TRM 部分 6.4.3 应提供有关 PRU-ICSSG 有效时钟源组合的更多详细信息。

此致、
Aaron

尊敬的 Martin：

继我前面的声明之后、还需要注意的几点是、ICSSG0 和 ICSSG1 无法在不同的频率下使用相同的 PLL。 仅允许 ICSSG0 和 ICSSG1 的以下时钟频率组合：

希望这样可以清楚地说明配置。

此致、
Aaron

您好 Aaron、

非常感谢您 的澄清。 具有讽刺意味的是、我们已经计划将所有 ICSSG 频率设置为 333MHz、但三缓冲器故障延迟了该步骤。 但是、希望它能如此简单地解决。 我将为测试设置打补丁、让我们看看接下来的几周会带来什么。 我会等待几周、然后将问题标记为已解决。 我觉得这还可以。

感谢您的支持。

此致、
Martin

尊敬的 Martin：

但是、希望它能如此简单地解决问题。 我将为测试设置打补丁、让我们看看接下来的几周会带来什么。 我会等待几周、然后将问题标记为已解决。 我觉得这还可以。

是的、当然可以。 但是、您是否认为 ICSS 实例之间的时钟频率不匹配会导致三路缓冲器问题？ 我只是想了解这里的测试场景。

此致、
Aaron

您好 Aaron、

如果两个 ICSS1 都配置了有效频率、那么我希望它可以正常工作而不会出现问题（因此，200MHz 和 300MHz 应该可以正常工作）。 但是、ICSSG0 必须设置为 333MHz。 因此、只有 225MHz、300MHz、333MHz 可以用于 ICSSG1。 在 tiescbsp.h 文件中、有针对 333MHz 的 TIESC 的各种定义（例如 TIESC_PRUICSS_CLOCK_FREQUENCY_333_MHz）、250MHz 和 200MHz。 但不是 225MHz 或 300MHz 的单一定义、因此我现在假设 225MHz 和 300MHz 根本不是 ESC 的合法频率、但我假设您知道这比我（？）更好。 这就是我们计划使用 333MHz 的原因。

然后、在旧的 syscfg 工具 ICSSG1 设置为 200、ICSSG0 设置为 333 时、旧工具没有这方面的问题、但我假设 ICSSG1 从未真正设置为 200、而是以静默方式设置为某个其他频率。  当您将旧的 syscfg 工具配置为 200 和 333 时、您可以亲自测试 PLL 和 MUX 寄存器中的最终值。 也许 ICSSG1 的频率静默设置为例如 225、即（不是？） ESC 允许使用。

然后、syscfg 工具确实为 ICSSG Clore 时钟和 IEP 计数器定义了一些频率、这些频率设置为 200、考虑到最终频率可能不是 200、这也可能是出现故障的原因。

然后、我们已经从另一个支持主题中了解到、建议将 IEP 设置为与 ICSSG 内核时钟相同的频率、否则很难正确读取 IEP 的 64 位计数器（有相关的芯片勘误表）。 由于 200MHz 设置无效、我不确定 ICSSG1 是否就是这种情况。

一般来说、ICSSG0 和 ICSSG1 不相互交互、只有 Beckhoff SSC 与 ICSSG1（在内核 R0 上运行）交互、R1 上只有自定义代码与 ICSSG0 交互。

因此总结：我确实希望将所有设置为 333MHz 可能会解决这个问题、但如果没有发生任何变化、我不会感到惊讶。  

基本上、我理解了您上次的答复、您认为不同的频率可能是一个问题、因此您希望解决方案可能如此简单。

如果您想了解更多信息、请随时提问？ 目前、我仍在尝试使用 Saleae 日志和 Wireshark 重现三缓冲器故障、以便我们可以查找丢失帧等、但目前我们的测试设置不会产生任何错误、 如前所述、有时这可能需要数周的时间。

感谢您的支持。

此致、
Martin

您好 Aaron、

我们有两个测试设置正在运行。 时钟均设置为 333MHz。 一个安装程序使用了默认固件、另一个安装程序使用了已修补的固件。 两者都不会产生错误。 因此、我假设使用 333MHz 足以解决该问题。

谢谢、很抱歉耽误您用 200MHz 运行 EtherCAT 内核的时间。 200MHz 只是默认值、 如果另一个 ICSSG 时钟设置为 333MHz、则忽略了必须将其更改。

此致、
Martin

您好 Aaron、

遗憾的是、几天前、在固件 6.5.74 且 ICSSG1 时钟设置为 333MHz 的其中一个测试设置（设置 2）中再次发生了此错误。 因此、在我们开始讨论 ICSSG1 时钟频率之前、您仍然可以选择该线程中的所有内容有效。

特别是,如果 bsp_get_proce_data_address() 返回的地址不一致,则三重缓冲区可能会失败。 失败意味着数据 2 个周期会发送旧数据（发送到主器件）、尽管在上一个周期中已经发送了新数据。  

我包含以下信息的帖子很好地提醒了实际发生了什么（我不知道如何引用帖子）：

• 与有问题的 FSoE 连接一起、如下所示：
  • 输入数据：
    (8) 0x2476、 0x3600BD6B0200  （最新数据包）
    (7) 0x2400、  0x3600BD6B0200
    (6) 0x24EC、0x3600BD6B0200
    (5) 0x24EC、0x3600BD6B0200
    (4) 0x2400、 0x3600BD6B0200
    (3) 0x2476、 0x360003590200
    (2) 0x24EC、0x360003590200
    我们在此处可以看到 FSoE 数据从 0x360003590200 合法更改为 0x3600BD6B0200、以及 0x24EC（有故障）重复。
  • 输出数据：
    (8) 0x1400、0x3600BD6B0200  （最新数据包）
    (7) 0x144E、 0x3600BD6B0200   
    (6) 0x149C、 0x360003590200
    (5) 0x1400、 0x3600BD6B0200
    (4) 0x144E、 0x360003590200
    (3) 0x149C、 0x360003590200
    (2) 0x1400、 0x360003590200
    此处、地址[0x1400、0x149C、0x144E]按预期运行。 但是我们可以在这里看到、当 FSoE 数据从 0x360003590200 变为 0x3600BD6B0200 时出现错误、与输入数据一样应该是平滑的（因为这基本上是刚刚由同一从器件发送到主器件后从主器件发送回从器件的输入数据）。
    
    

当前我正在尝试创建一个解决方法:如果我们看到 bsp_get_proce_data_address () 返回的地址 有任何不一致,我们尝试操作 bsp_get_proce_data_address ( ), bsp_read ()/bsp_write (), bsp_proce_data_access (),只希望将三个内部缓冲区的 3 个内部缓冲区更新为有效数据。 请随时提出更好的解决方法建议。 或者、关于这个主题、您有什么新的意见吗？

我对这又是一个问题感到非常抱歉和沮丧。

此致、
Martin

尊敬的 Martin：

所以,这一次,它需要更长的时间（几个月）看到这个问题?

在 Setup1（默认固件和 333MHz）中、未观察到问题？

请随时提出更好的解决方案。 或者您对此主题有任何新的意见吗？

我将在内部讨论这一点。

此致、
Aaron

您好 Aaron、

安装程序 2 在运行 1 个月后失败。 设置 1 当前未激活。 由于缺少设备、我们无法让设置始终仅为观察此错误而运行。 在多个设置运行超过 3 周后、我们只是认为此错误已消失、因此将设置用于其他目的。

感谢您再次查看此内容。

此致、
Martin

尊敬的 Martin：

感谢您提供详细信息。 我将在特定时序下回顾缓冲器旋转逻辑中的边缘情况固件。

同时、您是否还可以共享该实现方案的 MPU 设置以及 ESC 错误计数器 (0x0300 - 0x030D)。

此致、
Aaron

您好 Aaron、

感谢您的支持。

我附上了 R5_0 和 R5_1 的 syscfg.xml 文件。 R5_0 负责 EtherCAT。 MPU 设置与  最初来自 IND_SDK_09_02_00_24 的示例 EtherCAT_subdevice_Beckhoff ssc_demo 中的设置类似。 没什么特别的。

e2e.ti.com/.../alx.syscfg.txt
e2e.ti.com/.../alx.syscfg.txt

错误计数器的地址。 每次我检查到目前为止它们都是 0。 如果您想在三路缓冲区发生故障后了解它们、我会将它们添加到日志记录中、然后我们需要等到下一个故障发生。 但我假设它们也将为 0、因为 Wireshark 日志从未显示丢失的帧、我们应该在 Wireshark 中看到丢失的帧、或者我们不应该吗？

此致、
Martin

谢谢 Martin、我将查看您分享的文件。 对延迟响应表示歉意。

我们将尝试在我们一方模拟类似的环境来重现这个问题。 由于您提到邮箱事务的大量使用（对于 FSoE）、我们将尝试类似的邮箱应力并查看它是否会影响缓冲区交换。

此致、
Aaron

您好 Aaron、

感谢你的努力。 当前设置正在运行、没有出现错误、我们正在等待下一个错误。 我们现在已经实现了 0x0300 - 0x030D 的日志记录。  

主设备丢失帧计数器现在由我们的操作系统部门正确实施、因此现在我知道每小时丢失几个帧。 我不知道为什么 EtherCAT 在理论上应该能够准确地解决这个问题。

如有任何其他问题、请随时提出。

此致、
Martin

您好 Aaron、

一天前 问题再次出现。  

0x0300 - 0x030D 读取全部为零。

下面您将看到我们对通过 EtherCAT 诊断消息记录的三路缓冲区地址的跟踪。 每次预期周期中断时都会发出一条警告。 与通常的三重缓冲地址一样,我们从 bsp_get_proce_data_address() 得到的地址是 9,387,921695589387,...但有时这个模式会在 9558 之后中断。 目前、我们最好怀疑这会导致从三重缓冲区读取过时的数据。

请注意、并非以上图像中的每个警告都会导致三路缓冲区失败、但如果失败、则总是在 bsp_get_proce_data_address () 返回的地址中断前一个模式时出现。

您可能会纠正我、但我通常希望三路缓冲区始终保持一致、无论我们读取或写入/写入它的时间点如何。 还是有我们应该知道的时机。 但是、我们显然通过 EtherCAT SSC 使用正常时序（例如，如果 EtherCAT 总线周期为 1ms 等、则每毫秒读取/写入 PDO 数据）、我会问一下以防万一。

感谢您的支持。 你到目前为止有新消息吗？

此致、

Martin