[参考译文] TMDXIDK5718：TMDXIDK5718：SOF/SyncManager 抖动-适用于 AM571x_idk 的 PRU-ICSS-EtherCAT 从站

你(们)好
您能否尝试探测电路板上的 Sync0/1输出信号和 PDI IRQ 信号(通过 EDIO 映射到 SOC 引脚)？  

此致
Dhaval

您好 Dhaval、

感谢您的支持。 我已邀请客户参加讨论。

此致、

Marvin

为此、您还必须配置 PDI ISR DIGIO 引脚选择寄存器(0x0E0A)。 如 PRU ICSS EtherCAT 从控制器寄存 器列表中0x0E0A 的寄存器说明所述、"PDI ISR DIGIO 引脚选择寄存器、选择 pr1_edio_data_outN 引脚之一作为 PDI ISR HW 引脚、配置255以禁用。 将相应的位掩码设置为启用。 应用需要正确配置引脚多路复用器才能使其正常工作"

此致
Dhaval

您好 Dhaval、

感谢您的支持。  我将研究探测这些信号。  自原始查询以来、我们进行了一些调试、发现 SOF 信号对软件中发生的实际中断具有大约20us 的延迟。  为此、我们通过引脚 D7 (vout1_d10)和软件初始化中的引脚多路复用器进行了测量。  SOF 信号到达我们预期的时间、但直到硬件中断的延迟约为20us。

您好 Dhaval、

只需检查一下、看看您是否对我上周提供的 SOF 信号测量有任何输入。   我仍在等待我们团队的一些硬件支持来获取这些其他测量结果。

我还想问的一点是、您注意到使用信号 pr1_edio_data_outN 进行测量。  根据我对 TMDXidk5718板的理解、未组装 PRU1以实现 EtherCAT 功能。 因此、在本例中、我们将 PRU2用于开发目的。  只是想检查这是否正确。

你(们)好

如 https://software-dl.ti.com/processor-industrial-sw/esd/docs/indsw/EtherCAT_Slave/01_00_10/PRU_ICSS_EtherCAT.html#running-ethercat-slave-application 中所述、"要在 AM571x IDK 上使用 PRU-ICSS1、需要在[install-DIR]/protocols/ethercat_slave/include/tiesc_soc.h 文件中将#define PRUICSS_instance 设置为 PRUICSS_instance_one。"

此致
Dhaval

您好 Dhaval、

是的、我以前曾尝试过、但它对我不起作用。  一段时间后、有一个论坛帖子、另一位客户有类似的问题。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1089006/am5718-idkam571x-ethercat-slave-on-pru-icss1

此外、检查 SDK 源代码时、注意到 hat PRU1 eth0未针对默认 IDK 进行连线。  在 SDK 源代码中注释掉了 PINMUX 选项。

你(们)好

如果您使用 的是 PRU-ICSS-EtherCAT_Slave_01.00.10.00，您是否尝试 过 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1047677/tmdxidk5718-pru-icss-ethercat-slave-for-am571x_idk---lines-crossed-error 中提供的修补 程序？

此致
Dhaval

是的、我们一直在使用为交叉错误行提供的补丁。

您好 Dhaval、

仍在努力获取 Sync0/Sync1/PDI 测量值。  不确定您是否对 PRU1为什么即使使用所提供的补丁程序也不能为我工作有任何了解？

此外、我想提出另一个我们认为与帧起始时序相关的测量观察结果。

首先介绍一些背景信息。  我们使用次级周期模式运行 EtherCAT。  Sync0以55us 的速率运行、Sync1以220us 的速率运行。  因此、我们有4个 Sync0事件与每个 Sync1事件的比率。

在测量事件时、我们注意到控制器启动期间存在差异。

在从器件接收同步中断的开始、我们可以看到以下内容。 第一个完整周期(红色)包含5个 Sync0脉冲和1个 Sync1脉冲。 后续周期(黄色)的运行方式符合我们的预期、只有4个 Sync0脉冲至1个 Sync1脉冲。

我对一些 EtherCAT 寄存器进行了读取操作、并看到了以下内容。 从左到右、我将读取0x910系统时间、下一次读取0x990 Sync0、下一次读取0x998 Sync1。

 

在粉色中、我在接收任何 Sync0脉冲之前的55us 周期内对这些寄存器执行了8次读取。 请注意、下次在此处设置 Sync0、但下次不设置 Sync1。

 

下面的红色/蓝色/绿色对应于上面波形中标记的位置。 蓝色是我们的第一个 Sync0脉冲、此时、Sync1下一次仍不更新。

 

直到我们的第一个 Sync1脉冲以绿色出现时、我们才看到该寄存器更新。 我们想知道、您是否知道 Sync1下次(0x998)寄存器的更新位置、以及为什么直到现在才更新。 如果提供黑盒、我就知道德州仪器的 PRU EtherCAT 固件。  是否可以访问源代码以了解为什么在启动期间不更新该寄存器？

您好 Dhaval、

只是想在我之前的询问中办理入住手续。  谢谢！

你(们)好
我们将对此进行研究。 我将在本周结束前提供进一步的答复。

此致
Dhaval

你(们)好

我再次验证了这一点。 通过更改 tiesc_soc.h 文件中的宏、我还可以使它在 PRU-ICSS1实例上工作。

请注意、IDK 上的 J51必须打开才能正常工作。 请参阅以下 IDK 用户指南摘录：

"AM571x IDK EVM 支持多达四个连接到 PRU-ICSS 的100Mb 工业以太网端口
子系统和连接到集成以太网交换机的多达两个千兆位(1000Mb)以太网端口。
可用端口的最终数量取决于配置选择：
•4端口以太网模式：提供两个100Mb 工业以太网端口和两个千兆位(1000Mb)
以太网端口。
•6端口以太网模式：提供4个100Mb 工业以太网端口和2个千兆位(1000Mb)
以太网端口。
这些以太网模式之间的选择由接头 J51控制。 在接头 J51上安装分流器
将这些引脚短接在一起可启用4端口以太网模式。 从这些引脚上移除分流器
启用6端口以太网模式。 仅当选择4端口以太网模式时、LCD 输出才可用。"

此致
Dhaval

你(们)好

您能更详细地解释一下吗？ 如果预计 SOF 到 Sync0在主器件侧为55us、它是否指向主器件侧的问题？

在测量事件时、我们注意到控制器启动期间存在差异。

在从器件接收同步中断的开始、我们可以看到以下内容。 第一个完整周期(红色)包含5个 Sync0脉冲和1个 Sync1脉冲。 后续周期(黄色)的运行方式符合我们的预期、只有4个 Sync0脉冲至1个 Sync1脉冲。

您能否确认您是否在启动期间仅看到此情况一次、而在稍后未看到此情况？

此致
Dhaval

您好 Dhaval、

感谢您的回应、我们非常感谢您的帮助。  下面我列出了一些答案。

PRUICSS 实例1

好的、我已经删除了 J51标头、并将 DEFAULT_PRUICCS_Instance 更改为 PRUICSS_instance_one。  主器件报告 总线扫描错误"总线配置不匹配(0x9811001e)"、找到0个从器件。  是否可能还需要修改 SDK 以启用 PRU1 eth0 Pinmux、如上一帖子中所述？



SOF 抖动
我们将直接测量来自电路板的引脚 D7 Vout1_d10上的 SOF 信号。  SOF 信号按预期从主器件到达的时间、比下一个 Sync0提前55us。  但是、  在看到 SOF 信号20us 后、我们才会看到 PDI_ISR/SyncManager 的硬件中断。  因此、尽管 SOF 达到预期的时间、但直到20us 后、我们才在软件中接收中断。  在引脚 D7上测量该值如下所示。



 启动时的 Sync0时序
是的、我们只会在第一个周期中看到这种情况发生、之后进行了更正。  值得注意的是、由于 LatchInputSync0Counter 变量、这是一个问题。  该变量在每个 Sync0中断处递增、并用于指示何时应发生 PDO 输入映射。  Sync1中断将重置此计数器、因此我们仅在启动时看到问题、因为意外的额外 Sync0中断、从而导致及早发生输入映射。  但是、它会在所有后续周期中自行校正。  

你(们)好

PRUICSS 实例1

好的、我已经删除了 J51标头、并将 DEFAULT_PRUICCS_Instance 更改为 PRUICSS_instance_one。  主器件报告 总线扫描错误"总线配置不匹配(0x9811001e)"、找到0个从器件。  是否可能还需要修改 SDK 以启用 PRU1 eth0 Pinmux、如上一帖子中所述？

我没有为此修改 PDK 中的任何内容。 您使用的是哪个 PDK 版本？

此致
Dhaval

PROCESSOR_SDK_RTOS_am57xx_06_03_02_08
pdk_am57xx_1_0_18

Dhaval、

另外、我们还考虑了 Sync0/Sync1时序的启动问题。  虽然我只在启动时观察到这个问题、但我无法肯定它不会在运行时的稍后阶段发生、因为我们的日志包括数千个周期。  我们只是希望能够准确地了解 PRU 固件中设置这些寄存器的内容。

你(们)好

它看起来像是一个问题。 我们将研究此问题并提供更多详细信息。

我们认为、我们需要使用硬件引脚对 Sync0/Sync1/PDI 进行配置、而不是使用 ISR 中的 GPIO 进行配置。 我们知道、在使用 SYNC 和 edio 引脚执行性能评测时存在挑战。 我们将在一边尝试、并提供更多详细信息。

此致
Dhaval

您好 Dhaval、

感谢您的更新。  您能否提供有关使用 HW 引脚测量 Sync0/Sync1/PDI 中断的正确方法的其他信息？  D7 vout1_d10是否不是为 PDI 执行此类测量的正确方法？

此外、您是否确认要使用哪个版本的 PDK 来使 PRUICSS1正常工作？

谢谢、
Ryan

你(们)好

我们将再次讨论这个问题。

我使用了 PDK 版本  1.0.18.

此致
Dhaval

你(们)好

使用硬件引脚测量 Sync0/Sync1/PDI 事件比使用相应的 ISR 更准确。 在 EtherCAT 封装的默认示例中、我们也未在 HW 引脚中看到事件。 此问题正在调试中、当他更新需要哪些更改才能使其正常工作时、我们将发布响应。

Ryan Hodgman 说：

此外、您是否确认要使用哪个版本的 PDK 来使 PRUICSS1正常工作？

我使用了 PDK 版本  1.0.18.

您是否能够使用此版本测试备用 PRU-ICSS 实例？

此致
Dhaval

你(们)好

此外、检查 SDK 源代码时、注意到 hat PRU1 eth0未针对默认 IDK 进行连线。  在 SDK 源代码中注释掉了 PINMUX 选项。

您提到的代码不用于 IDK 版本1.3。 您使用的是哪个版本？

如前所述、请注意、IDK 上的 J51必须打开才能使 PRU-ICSS1正常工作。 请参阅以下 IDK 用户指南摘录：

"AM571x IDK EVM 支持多达四个连接到 PRU-ICSS 的100Mb 工业以太网端口
子系统和连接到集成以太网交换机的多达两个千兆位(1000Mb)以太网端口。
可用端口的最终数量取决于配置选择：
•4端口以太网模式：提供两个100Mb 工业以太网端口和两个千兆位(1000Mb)
以太网端口。
•6端口以太网模式：提供4个100Mb 工业以太网端口和2个千兆位(1000Mb)
以太网端口。
这些以太网模式之间的选择由接头 J51控制。 在接头 J51上安装分流器
将这些引脚短接在一起可启用4端口以太网模式。 从这些引脚上移除分流器
启用6端口以太网模式。 仅当选择4端口以太网模式时、LCD 输出才可用。"

关于 SYNC/PDI 硬件引脚、它正在调试中、我将在开始工作后提供详细信息。

此致
Dhaval

你(们)好

以下是有关如何在 AM571x IDK 上启用 SYNC 和 PDI 输出的详细信息：

1. 您需要为 pinmux 添加以下代码
   

   // PRU-ICSS1 SYNC0输出的引脚多路复用器(引脚 D2、信号、VIN2A_D4、地址0x4A003578、多路复用模式0xB)
   (((CSL_padRegsOvly) CSL_MPU_CORE_PAD_IO_Registers_regs)->PAD_VIN2A_D4 = 0x2000B；

   // SOF 的引 脚复用(引脚 F4、信号 VIN2A_D5、地址0x4A00357C、多路复用模式0xB)
   (((CSL_padRegsOvly) CSL_MPU_CORE_PAD_IO_Registers_regs)->PAD_VIN2A_D5 = 0x2000B；

   // PRU-ICSS1 EDIO OUT1的引脚多路复用 (引脚 G2、信号 VIN2A_DE0、地址0x4A003558、多路复用模式0xD)
   (((CSL_padRegsOvly) CSL_MPU_CORE_PAD_IO_Registers_regs)->PAD_VIN2A_DE0 = 0x2000D；

2. 在 tiescbsp.h 文件中将 PDI_ISR_EDIO_NUM 更改为1、因为我们在这里使用的是仿真1输出。

之后、您可以探测 IDK 上的以下引脚

• SYNC0：J21的引脚54
• PDI ISR： J4中的引脚3
• SOF：J21的引脚56

我们还提出了一些后续问题：

• 从 SOF 到 Sync0的预期时间设置为55us

(Q1)您能否在此处分享有关该预期时间计算方式的更多详细信息？

(Q2)您是指 SOF 到 SYNC0还是 SM 到 SYNC0、正如在原始消息中、您对 SM 到 SYNC0使用了55us？

(Q3)您是否使用 TwinCAT 尝试过类似的测量？ 您知道、SOF 取决于主器件发送的数据包的时序、因此主器件可能会在 SOF 和 PDI/SM 更新方面引起抖动。

此致
Dhaval

您好 Dhaval、

感谢您的更新、希望我能帮助回答您的问题并在下面进行澄清。  如果有任何不清楚的地方，我可以尝试进一步阐述。

有关 PRU1的 IDK Pinmux 的说明。   好的、我现在知道、我们的电路板版本是1.3。  但是、我仍然无法使 PRU1正常工作、但 J51已打开、并且我已在 ities_SoC.h 中将 PRUICSS_DEFAULT_Instance 设置为 PRUICSS_instance_one  您能想到我能看到的其他东西吗？

感谢您提供 PINMUX 选项、我将尝试使用这些选项进行信号测量。

Q1：预期时间由主堆栈计算和设置(如前所述、我们将使用 Acontis)。  使用从器件作为参考时钟将主器件设置为 BusShift 模式。  因此、主器件控制以从器件为基准的发送时序、以获得55us 的预期值。

使用探头迹线进行测量。  SOF 信号在引脚 D7 (位于电路板上的 U103上)上测量。  这里的 SyncManager 和 Sync0时序是从软件中的中断测量的。  

Q2：我所指的测量是 SYNC0中断的 SyncManager 中断(PDI_ISR)。  此处测量的时序为36us。  但是、当我们直接测量发送到 SYNC0的 SOF 信号时、时序为预期的55us。  我的理解是 SOF 向 SyncManager 中断发出信号、因此接收到的 SOF 与在软件中看到 SyncManager 中断之间存在抖动。  

总结一下：
SOF 到 Sync0中断(在软件中)= 55us
Syncmanager (在软件中)到 Sync0中断(在软件中)= 36us

Q3： 我们尚未尝试使用 TwinCAT。  我们已经尝试使用不同的 ESC 器件(EL9800)、并且我们还在此器件上将 SOF 测量为 Sync0、使其为55us。

你(们)好

我们将对此进行检查。 您使用 的是 https://www.ti.com/tool/TMDXIDK5718? 我正在使用它、这些更改对我来说已经足够了。

我们无法保证 SOF 和 PDI ISR 之间的固定间隔(由于 SM 更新引起)。 根据数据包长度的不同、它将发生变化。  此外、SM 的缓冲区切换仅在 CRC 验证之后发生在 EOF 之后。 在任何情况下、最好测量来自硬件信号的时序。

是否可以使用 TwinCAT 尝试此操作？


此致
Dhaval

您好 Dhaval、

感谢您的参与、这无疑有助于澄清我们所看到的 SM 时间安排。  我正在调试 PRU1以使其正常工作、因此我可以通过提供的引脚多路复用选项进行测量。

我们还想知道在启动时 Sync1 Next Time 0x998寄存器是否有任何更新。

Dhaval、

我检查了原理图、看起来引脚 G2的 EDIO_Data1实际上位于 J4引脚4上、而不是引脚3上。  假设我现在正在测量 PDI 的正确引脚、我的结果可在下面找到。

对于此测试、我使用的是从 SOF 到 Sync0的预期延迟 为10us。

SOF 引脚 F4至 Sync0引脚 D2符合预期、大约 10us。   

SOF 引脚 F4至 EDIO 输出引脚 G2约为15us。  这是我们之前关注的抖动、它仍然通过直接引脚测量显示。  我了解到、如前所述、在我们之前使用软件中的 GPIO 切换进行测量时、处理数据缓冲器可能会影响此延迟。  对于使用硬件信号进行的测量、该陈述是否仍然正确？

你(们)好

执行这些测试时的数据包大小是多少？

SOF 和 PDI ISR 不会同时发生。 因此、我们无法将其视为抖动、因此预计会有一些延迟。

此致
Dhaval

您好 Dhaval、

考虑到我们有不可解释的原因、延迟是可以接受的。  如果您说它与数据包大小或处理数据大小相关、我认为我们可以解决这一问题。  

根据我对数据包大小的理解、最大大小为1514字节：14字节以太网标头、2字节 E88A4标头、10字节 EtherCAT 标头、1486字节 EtherCAT 数据和2字节 EtherCAT 工作计数器。

在我最近的测试中、我们有1个主器件1从器件。 72字节输出处理数据到从机、72字节输入处理数据到主机。  因此、假设我对该计算的理解是正确的、这会将数据包大小设置为172字节。  

您好 Dhaval、

想要检查启动时 Sync1启动时间寄存器问题是否有任何更新？

Ryan

这可能需要更改 PRU-ICSS 固件。 修复程序可用后、我将与您分享。

此致
Dhaval

Ryan
很抱歉耽误您的回答。

在这种情况下、您能否检查主器件何时更新 SYNC1周期时间(0x09A4-0x09A7)寄存器？ 在0x998寄存器中读取0x0时是否已经完成？

此致
Dhaval

您好 Dhaval、

我明白解决这些问题的时间间隔不是一件简单的事情。

是0x09A4 SYNC1周期时间寄存器在我读取0x998寄存器中的0x0之前的某个时间进行更新。  请参阅随附的图像、0x09A0和0x09A4已初始化周期时间。  0x0910系统时间正在更新、0x0990 Sync0下次时间设置为在指定的将来时间发生、但0x0998仍读为0。