主题中讨论的其他器件：HALCOGEN、 TMS570LS3137
您好！
在 EMAC 停止接收数据直至下一次 MCU 重启之前、我们很少发生事件(每天一次)。
经过一些调查、我们发现 EMAC 和 MCU 内核之间存在未记录的竞态条件。
请参阅 TRM 文档 SPNU563第 32.2.6.2章发送和接收描述符队列
本文档中的引用：
在可能存在竞争条件的情况下，EMAC 可能会在中将描述符的“next”指针读取为 NULL
应用程序之前的瞬间通过修补指针将附加描述符附加到列表中。 这种情况
案例由软件应用程序处理、始终检查所有 EOP 的缓冲区描述符标志
数据包、查找称为队列结束(EOQ)的特殊标志。 EOQ 标志由上的 EMAC 设置
当描述符的“下一个”指针为 NULL 时，数据包的最后一个描述符。 这就是 EMAC 的方式
向软件应用程序表明它认为它已到达列表的末尾。 软件时
应用程序会看到 EOQ 标志集、此时应用程序可能会提交新列表或部分
通过将新列表指针写入启动的相同 HDP 而错过的附加列表
过程。
但有一些新的比赛条件。 当 EMAC 从下一个指针已经读取 NULL 时、MCU 可以读取 EOQ=0。 在这种情况下、SW 未重启当前接收缓冲器指针。 结果在下一次重新引导之前停止数据接收。
用于生成泛洪数据包并重现此行为的测试代码示例，您可以在附件(flood.pl)中找到该示例
我们尝试将数据包泛洪到该接口。 在统计中、TRM 中描述的和在 HalCoGen EMAC 驱动程序中使用的缓冲器下溢操作只有在9996个10000的情况下才能够正常工作。 其余4种情况导致接收最终停止。
看起来、内核和 EMAC 之间的芯片上存在一些时域同步问题。 我们不知道是否可以通过将 ISB/DSB/DMB 指令添加到代码中来解决该问题、而无需您进行调查。
对于这个问题、我们尝试制造补丁(在附件中、您可以找到 HalCoGen 生成 的 HL_EMAC.c 文件的版本)。 该代码在处理接收到的数据期间再次检查 EOQ 标志、因为此时我们确信该标志有效。
这看起来与针对 TX 讨论的 EOQ 问题类似。 请访问 e2e.ti.com/support/microcontrollers/hercules/f/312/t/526697#pi239031350或 e2e.ti.com/support/arm/sitara_arm/f/791/t/543686#pi316653
我们能够重复 EOQ 问题的两种变体(此处介绍了 TX 和新 RX)。 TX 变量已知时间超过2年、但在 HalCoGen 生成的代码中没有勘误表和修复。 请记住、Hercules 的设计是为了安全而设计的、我们等待了2年以上。 我个人在等待一年后出现此问题的 TX 型号(e2e.ti.com/support/microcontrollers/hercules/f/312/t/583653 CQ 票：SDOCM00122906)太糟糕了！
这种行为对我们当前的所有项目都有很大影响、请给予 解决此问题的最大优先级。
Jiri Dobry
e2e.ti.com/.../8306.HL_5F00_emac.c.diff e2e.ti.com/.../5381.flood.pl.txt
