[参考译文] AM3359：EtherCAT：读取 SII 时 BUSY 位未复位

您好、Chris、

Unknown 说：

在 SSC 或 PRU 固件中哪个位置发生 BUSY 位复位？ 什么会触发复位？

• ESI EEPROM 忙碌位由 EtherCAT PRU 固件清零。 这是由固件根据主机使用 bsp_send_command_to_firmware()发送的命令完成的、其中 bsp_pruss_cmd_intfc_write_word ()写入 DMEM、固件从该内存读取并 确认命令。
• 一个可能的问题是向固件发送命令所花费的时间比预期长？

这是我们可以从我们这边重现的吗？ 您是否正在尝试 TI 提供的默认示例、或者它是定制应用？

此致、
Aaron

您好 Aaron、

非常感谢您的快速答复! 这是 Linux 上的定制应用程序(我知道您并不正式支持)、因此很遗憾、我无法在 TI 的官方示例上提供复制内容。

根据您的建议、我们研究了代码并看到以下调用链：

EEPROM_CommandHandler (..) 在 ecatappl.c 中：最后、这会调用
-> HW_EscWriteWord (..) 在 tieschw.c 中
-> bsp_pdi_write_indication (..) 在 tescbsp.c 中
-> bsp_eeprom_emulation_command_ack (..)
-> bsp_send_command_to_firmware (CMD_DL_USER_EEPROM_CMD_ACK、0、0)

这是最后一个会导致 BUSY 位清零的调用吗？ 您能否详细说明一下您认为这可能需要比预期更长的时间？

相对而言、在哪个位置设置繁忙位？ 这是由 PRU 固件在没有主机干预的情况下、在收到对 SII 控制/状态寄存器0x502的 EtherCAT 写入并设置 ReadOperation 位后完成的吗？ 我们想知道是否因为某种原因调用 EEPROM_CommandHandler 太晚了。

提前感谢您的任何见解!

您好、Chris、

Unknown 说：

这是最后一个会导致清除繁忙位的调用吗？

• 是正确的、 固件将确认使用 CMD_DL_USER_EEPROM_CMD_ACK 命令的最后一次调用以清除 BUSY 位。

Unknown 说：

您能否详细说明您认为这可能需要比预期更长的时间？

• 我的语句基于这样一  个事实：固件将根据主机发送 CMD_DL_USER_EEPROM_CMD_ACK 的时间清除该位。 由于固件依赖于此命令、因此看起来这是晚于预期触发的、从而导致固件在超时窗口丢失。

Unknown 说：

最近、在哪个点设置繁忙位？ 这是由 PRU 固件在没有主机干预的情况下在收到对 SII 控制/状态寄存器0x502的 EtherCAT 写入并设置 ReadOperation 位时完成的吗？

• 我必须对此进行检查。 请你给我一些时间,我检查一下这个,然后回到你那里。

Unknown 说：

我们想知道、是否因为某种原因而将 EEPROM_CommandHandler 调用得太晚了。

• 这也是可能的。 此外、是否可以尝试不同的 EtherCAT 主设备来查看此问题是否取决于 SOEM 流？ 如果我们有一个工作情景、那么我们可以使用工作情景来描述时间。

此致、
Aaron

我必须对此进行检查。 请你给我一些时间,我检查一下这个,然后回到你那里。

谢谢、Aaron、我很感谢。 知道何时设置 BUSY 位可能有助于我们找到设置和发送 CMD_DL_USER_EEPROM_CMD_ACK 之间的延迟。

此外、是否可以尝试不同的 EtherCAT 主设备来查看此问题是否取决于 SOEM 流？

我尝试了从 EtherCAT 一致性测试工具读取 EEPROM、但无法重现问题。 该问题很可能取决于 SOEM 产生的特定流。 因此,不幸的是,我还不能提供一个明确的工作场景。

我们还尝试了 TwinCAT 作为主器件、但在这里我们看到了不同的(但可能相关？) 问题。 ESC 无法返回数据链路层环路状态(ESC 寄存器0x111)、即器件不会增加工作计数器。

这是一个具有两个相同读取命令的帧、一个发送到 Beckhoff 终端、另一个发送到我们的器件：

如第三个数据报所示、其他寄存器也可以返回。

从终端成功读取寄存器0x111后、TwinCAT 将继续使该子器件进入 PREOP 状态、但对于我们的器件、它此时停止。

您是否希望 TI PRU-ICSS-ETHERCAT-SLAVE 01_00_10_00支持该寄存器？

您好、Chris、

请期待 EOD Friday 的回复、因为这是今天的假期。

Unknown 说：

您预计 TI PRU-ICSS-ETHERCAT-SLAVE 01_00_10_00会支持该寄存器吗？

• 是、该寄存器对于将 DL 状态 与 EtherCAT MDevice 进行通信至关重要。 我没有看到固件不确认此寄存器偏移的情况。 我来检查一下、要确认此寄存器是否依赖于主机端(我预计不会这样做)、这样 SOEM 问题也可能与该问题类似。  
• 此外、您能否共享与 TwinCAT 问题相关的完整 Wireshark 日志？

此致、
Aaron

您好 Aaron、

我将附加在重新启动 TwinCAT 主站时获取的 Wireshark 日志。 布线如下：

   |Master|--|Beckhoff EK1814|--|AM3359器件|

在第178帧中、主器件为 Beckhoff 终端设置配置的站地址、然后继续将其启动。 我们的器件刚刚重复读取寄存器0x111的尝试失败。

e2e.ti.com/.../twincat_5F00_master_5F00_restart.zip

谢谢 Chris 的日志。 我将对此进行分析、然后返回。

此致、
Aaron

背景： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1511164/am3359-am335x 中的后续行动

您好、Chris、

Unknown 说：

知道何时设置繁忙位可能有助于我们找到两者之间的延迟、即 CMD_DL_USER_EEPROM_CMD_ACK 发送之间的延迟。

• 的 BUSY 位(位15)  EEPROM 控制/状态  当主器件对同一寄存器(寄存器0x0502或0x0503 - EEPROM 控制/状态 )。

此致、
Aaron

您好、Chris、

Unknown 说：

在第178帧中、主器件为 Beckhoff 终端设置已配置的工作站地址、然后继续将其启动。 对于我们的器件、刚刚重复的读取寄存器0x111失败。

• 发生该问题时、您能否共享 ICSS 存储器转储？ 从固件的角度来看、当主设备从该寄存器读取数据时、我看不到任何特殊的处理。

此致、
Aaron  

您好 Aaron、

的 BUSY 位(位15)  EEPROM 控制/状态  当主器件对同一寄存器(寄存器0x0502或0x0503 - EEPROM 控制/状态 )。

非常好、这肯定会帮助我们更好地找到误差。

发生该问题时、您能否共享 ICSS 存储器转储？

不幸的是、我们仍在准备寄存器和内存转储。 但一旦我们有了这些、您就会知道。

当然、Chris。

此致、
Aaron