作为对使用第三方 OS+自定义驱动程序在自定义电路板上运行 PRU-ICSSG 网络的几个相关问题的后续行动、我们还遇到了另一个问题。
我们的驱动程序已被移植、以支持 TI 提供的 PRU 固件的最新版本、 但是、我们在运行 FW 版本02.02.11.02时遇到主要的稳定性问题-此固件似乎会导致我们在本论坛的其他几个主题(例如 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175207/am6548-pru-icssg-sr-2-0-receive-stalls)中多次或 更少地讨论过的可怕的" RX 路径失速"问题。
有趣的是、我们看到运行 FW 02.02.11.01的结果要好得多。 此版本中尚未观察到 RX 失速问题(尽管我们尚未进行任何大规模测试)。 但是、我们遇到了一个新问题:
我们有一个测试用例、在该示例中、我们在两个 PRU-ICSSG 以太网接口之间发送 UDP 数据包、在本例中为 PRU-ICSSG1.slice0和 PRU-ICSSG2.slice0 (也称为 emac2和 emac4)。 在少数情况下、我们观察到数据包丢失(在1000个来回传输事务中、大约有4-5个)。 通过 Wireshark 检查流量后发现、丢失的数据包确实出现在网络上、但帧的前50-60%消失了。 这包括以太网报头、UDP 报头等(我们在数据部分的最末尾有一个序列号、允许我们从软件角度确认损坏的数据包是我们缺失的数据包)。
一些其他信息:
- 这仅发生在千兆位速度上-我们没有看到任何此类问题以100Mb/s 的速率运行
- 我们已经能够在 MSMC RAM 中找到 TX 帧数据-在这一阶段、损坏的帧看起来完整、正常、即使对于稍后在网络上显示损坏的帧也是如此。
- 这表明损坏在堆栈(PRU FW、HW、MAC->PHY)下发生
- 我们的解释是、这样可以排除以太网驱动程序以及 UDMA 和高速缓存一致性问题
- 这表明损坏在堆栈(PRU FW、HW、MAC->PHY)下发生
- 预期的消息大小为1514字节、包括 EtherNet/UDP 报头-损坏的数据包似乎在高500到高600字节范围内。
- 丢失的数据量似乎是32字节的倍数
- 损坏的帧始终从前端截断(分叉?) -在 Wireshark 中,帧的最后一部分始终显示正确。
希望这是已知解决方案的已知问题-如果不是、我们如何从这里着手?
我很乐意提供网络流量日志、内存转储或任何其他可能需要的调试信息。
同时、我将再次尝试升高到 PRU-ICSSG FW 02.02.11.02。
/Daniel