[参考译文] AM2432：使用 EnetDma_submitTxPktQ 时研究 EtherCAT 接收中断停止（约 350ms）

您好、  

我已将此主题指派给相应的专家进行进一步调查。 如果您没有收到星期二的回复、请在此处 Ping。

此外、从上述说明中、您正在尝试使用 enet_layer2_icssg 实现以 500us 的周期时间实现 EtherCAT 主设备演示。 我的理解是否正确？
如果可能、还请共享 Wireshark 日志、这有助于进行详细调查。

此致、
Aaron

您好：

另外、如果使用 EnetQueue_enq 同时发送第二个和第三个帧、则此问题尚未发生。 （我运行了大约 16 小时。）[/报价]

您能否澄清一下、当 3 个数据包无延迟发送时是否出现问题、而当第一个数据包和第二个数据包之间存在延迟时、是否未出现问题？ 此外、请提供有关任务优先级和应用程序设计的更多详细信息？ 我们将尝试在我们这边复制行为、以便更好地理解问题。

此致、
Teja,

我学到了一些新知识、所以我将更新信息。

350ms 暂停似乎不是由三个帧的发送方式引起的。
接收任务调用 ClockP_usleep (1)；接收帧并完成 DMA 传输后、
但有时需要很长时间才能退出此功能、可能是因为节拍未更新。
此外、在暂停 ClockP_usleep (1) 后、接收任务在 350ms 内似乎无法正常工作。
我尝试使用如下所示的手动忙循环：

IRQ_busy_wait = GTC_getCount64() + 150;
	while(IRQ_busy_wait > spent_time){
		spent_time = GTC_getCount64();
}

不再出现暂停。

我是否错误地使用了 ClockP_uSleep？

配置

接收任务：TaskP_PRIORITY_MAXIMUM
发送任务：TaskP_PRIORITY_MAXIMATE-1

发送任务会调用此代码三次：

EnetQueue_initQ(&txSubmitQ);

/* Retrieve TX packets from driver and recycle them */
EnetMp_retrieveFreeTxPkts(perCtxt);

/* Dequeue one free TX Eth packet */
txPktInfo = (EnetDma_Pkt *)EnetQueue_deq(&gEnetMp.txFreePktInfoQ);

/* Fill the TX Eth frame with test content */
txFrame = (EthFrame *)txPktInfo->sgList.list[0].bufPtr;

/* make send frame */
pre_fill_ecat_frame(txFrame);
fill_ecat_frame1(txFrame);

txPktInfo->sgList.list[0].segmentFilledLen = txFrame->payload[0]+16+(txFrame->payload[1] & 0x07)*256;
txLen = txPktInfo->sgList.list[0].segmentFilledLen;
txPktInfo->sgList.numScatterSegments = 1;
txPktInfo->chkSumInfo = 0U;
txPktInfo->appPriv = &gEnetMp;

EnetDma_checkPktState(&txPktInfo->pktState , ENET_PKTSTATE_MODULE_APP , ENET_PKTSTATE_APP_WITH_FREEQ , ENET_PKTSTATE_APP_WITH_DRIVER);

/* Enqueue the packet for later transmission */
EnetQueue_enq(&txSubmitQ, &txPktInfo->node);
status = EnetDma_submitTxPktQ(perCtxt->hTxCh[0], &txSubmitQ2);// 2024/8/20 status=0 を繰り返している

我还附加了 Wireshark 日志、因为它在 350ms 内无法运行。

第一帧发送漂移补偿 (CMD：ARMW)、
第二个帧发送 LRW、第三个帧也发送 LRW。

该数据是使用 profishark1G 捕获的、
如您所见、第三个帧未被正确捕获。
（profishark 选项会传输 CRC 错误、KeepCRC32 和 Capture full 帧处于启用状态。）

这可能是我应该提出的问题、但因为分析仪中似乎不太可能出现错误、
我想首先消除任何可能、例如 API 使用问题。

是否对使用 EnetDma_submitTxPktQ 有任何限制？
例如、发送后、我是否需要在发送下一个数据之前接收数据？

附录：我无法从 Wireshark 附加数据包捕获、因此我粘贴了图像。

您好、

接收任务调用 ClockP_usleep (1)

ClockP_uSleep 的最短时间周期为 1ms (1000usec)。 任何小于此值的操作都将使用基于循环的调用来 完成睡眠任务。 这样就无法提供一致的结果。 如果您的应用需要 1us 的精度、我们建议您改用计时器。

从 Wireshark 日志映像中、我无法找到差异为 350ms 的数据包。 要共享 pcap 文件,您可以压缩捕获文件,并附加到帖子。 这将有助于我们更好地分析流量。

是否对使用 EnetDma_submitTxPktQ 有任何限制？
例如、发送后、我是否需要在发送下一个数据之前接收数据？

使用  EnetDma_submitTxPktQ API 背对背使用它没有限制。 它也可用于只传输流量的应用。 如果您使用此命令以独占方式发送单个数据包、则也可以使用 EnetDma_submitTxPkt、它用于一次提交单个数据包。

使用 ClockP_usleep 的替代方法、您是否仍存在间歇性延迟问题？

此致、
Teja。

使用  EnetDma_submitTxPktQ API 背靠背使用它没有任何限制。

我明白。谢谢。  

采用 ClockP_usleep 的替代方法、您是否仍存在间歇性延迟问题？

当我将 BUSY 循环与 GTC 而非 ClockP_USleep 结合使用时、不再出现此问题。

由于 1-2us 的精度足以保持信号正常运行、因此这不是问题、
但我想知道防止其再次发生的原因。

我对这里的调试构建进行了一些研究、似乎在 uint64_t ClockP_getTimeUsec (void) 内没有更新节拍、
更新之前会有延迟。

你知道为什么会发生这种情况吗？

如前所述、优先级设置为接收任务的最大值、
我不使用任何中断禁用函数、如 HwiP_disable/HwiP_disableInt/HwiP_析 构特。
（我正在使用 MCU+SDK API，因此这里可能在使用它们。）

e2e.ti.com/.../packetcapture.zip

您好、

从捕获结果来看、我观察到大约 250us 的跳跃、但如前所述、没有 350ms 的跳变。 您是否也可以从您这边确认这一观察？

我现在无法测试 ClockP_usleep () API 的行为。 正如您在代码中已经看到的那样、ClockP_USleep API 不会进入睡眠状态、而是在函数中花费时间来实现小于 1ms 的延迟。 请让我在我们的测试设置中分析 API、这样便可以了解问题所在。  

我将发布有关结果的主题。 请在本周结束前收到回复。

谢谢。此致、
Teja。

在捕获中、我观察到大约 250 μ s 的跳跃、而不是前面提到的 350 毫秒。 您是否也可以从您这边确认此观察？

感谢您的确认。

抱歉、我没有提到一些信息。

请注意 Wireshark 数据中的数据编号 501-1901。

即使它们是 EtherCAT 帧、也无法捕获返回帧。

我认为这就是接收任务无法运行 350ms 的原因。

就在这一 350ms 问题发生之前、ClockP_usleep (1) 会延迟几十微秒、之后我们不再能够观察到任何返回帧。
略微改变测量环境、从主器件（定制电路板）-slave1（定制电路板）-slave2 (ti AM243xEVAboard) 改为
Master（定制板）-slave1（定制板）-slave2（定制板）或
主设备（定制板）-slave1 (ti AM243xEVAboard)-slave2 (ti AM243xEVAboard)
不再观察 350ms 间隔、但 ClockP_usleep (1) 开始无限循环。

重现问题大约需要 5-10 分钟。

ClockP_getTimeUsec 函数还包含以下注释、这让我怀疑设置优先级是否存在任何限制。
/**检查计时器是否溢出。
*这是为了处理使用从关键部分调用此函数的情况
*中断被禁用,因此`gClockctrl.tks`即使在情况下也不会递增
*计时器计数中的溢出。
*当 ISR 递增`gClockctrl.tks`时,它将清除溢出状态。 */

您好、

当两个从器件都是 am243x 板时、如果不对应用进行任何更改、就不会出现问题。 这可能会是与接收帧相关的设置问题。 您可以将读取点从 master 和 slave1 (master-profishark-slave1) 转移到 2 个 slave1 (slave1-profishark-slave2) 之间吗？ 我也希望得到一个澄清,这一观察是针对 am243x EVA 板的。  此外、请提供 ICSSG 端口的统计信息、以便了解链路状态和应用的更多详细信息。  

请我们的专家了解计时器实现方法。 但计时器溢出不太可能导致 350ms 的延迟。 但是、应用程序不同部分的某个关键部分可能会导致递增节拍出现一些延迟。  

我会很快回复测试结果。

此致、
Teja。

您能否将读取点从 master 和 slave1 (master-profishark-slave1) 转移到 2 个 slave1 (slave1-profishark-slave2) 之间？

至于 350ms 问题、我们在这里无法再重现、这可能是由于我们使用的定制电路板所致、因此很难进一步追踪。
如果这种情况再次发生、我将收集信息并返回给您。

相反、我想确认 uSleep 延迟的原因。
我使用以下方法创建了一个环境：TIBoard (master)(TMDS243EVM)-- TIBoard (slave)(TMDS243EVM)-- TIBoard (slave)(TMDS243EVM)

我附上了用于测试目的的各个项目。
如有必要、请在此处进行检查。
延迟发生在 ClockP_usleep (1) 处；在主源代码 enet_layer2_icssg.c 的第 3944 行
开始操作几分钟后出现延迟。

您好、

很高兴知道这个问题现在不会持续存在。 感谢您的更新。 由于内部承诺,我现在无法测试计时器行为。 我将尝试在一周内完成此操作、并在此主题中更新相同内容。

此致、
Teja。

您好、

我将尝试在一周内完成此操作、并在此主题中更新相同内容。

我正在联系您以询问进展情况。
您能告诉我当前的情况吗？

您好、

由于内部承诺、我还无法对此进行测试、但目前正在跟踪。 我将 在一周内发送分析详细信息。 请告知我们此时间表是否 适合您。

谢谢。此致、
Teja。

您好、

如果可能的话、我想在本月底 (9/30) 之前了解结果。

此致、
西森市。

您好、

我不能保证 9 月 30 日,但我将尝试给你一个更新的再现性,因为这是一个短的星期,印度队.  

谢谢。此致、
Teja。

您好、

我明白。 谢谢。
我期待着你的答复。

此致、
西森市。

您好、

感谢您的理解。 我将按 9/30 的 EOD 更新此主题。  

此致、
Teja。

您好、

我们运行了测试来分析 ClockP_usleep API 以及后台以太网流量、但无法重现问题。 现在、我们将尝试按照您在睡眠时所遵循的相同顺序发送数据包、以尝试重现问题、从而复制您的设置。  

一个怀疑是、CPSW 驱动程序内的统计模块可能导致了峰值。 但是、由于在数据包传输之间使用睡眠方法时没有观察到这一点、因此这不是问题。 我们仍在努力了解原因。 如果有更多详细信息、我将更新此主题。

此致、
Teja。