This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RM57L843:EOQ 的 EMAC 延迟状态会导致竞态条件

Guru**** 2333840 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/595952/rm57l843-emac-delayed-state-of-eoq-leads-to-race-conditions

器件型号:RM57L843

我在安全关键型应用中使用 RM57 EMAC、我们希望避免使用中断驱动的 I/O  因此、代码正在监视 CPPI 描述符上的 EOQ 标志、以标识 CPPI 状态机的状态。  似乎正在发生的情况是、CPPI 状态机在帧完成传输之前不会更新 EOQ 标志、但在内部已经决定停止处理。

故障排除案例:

  该实现方案始终会将新描述符附加到活动 CPPI 链的尾端。  然后、它会检查尾端 EOQ 的状态、以确定是否需要设置状态机 HDP。  CPPI 链间歇性停止、在早期描述符中显示 EOQ、并且永远不会更改后续描述符的所有者标志。   这在接收和发送 CPPI 链上都发生。

作为变通办法,我正在监视 HDP 值,当它的值为0时,我将使用 CP->NEXT 重新启动链。  这似乎是一种明智/安全的方法吗?

或者、我有另一种权变措施(针对 RM57 EMAC EOQ 竞争条件的权变措施)。  但是,我从未得到关于这种做法是否合理的明确答案。

由于这是一个安全关键型应用、我想了解 TI 对 EMAC 运行的建议。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    斯蒂芬

    我已将您的帖子转发给我们的 EMAC 专家之一。 他们应在接下来的几天内与您联系。

    另请注意、由于责任相关问题、我们无法真正评论您的代码的安全性。 我们只能就您的实施是否在实施模块的限制范围内运行发表意见。 我知道这是一个语义问题、但是有关安全实施的必要免责声明。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    EMAC 专家是否提供任何更新?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    除了您在 e2e.ti.com/.../526697中有关该主题的原始帖子中发现的内容 以及 在 Sitara E2E 上的此主题 e2e.ti.com/.../543686中发布的内容之外、我认为实际上没有任何其他更新。 一般而言、我认为您正在谈论的是寻找一种方法来解决器件中内置的行为、并在 TRM 中将其描述为已知行为。 对于您的具体实施、我建议根据您的特定应用需求验证您的解决方案、并进行详尽的验证工作、以确保解决方案涵盖您打算使用的所有特定用例。 如果它通过了所有这些情况、那么它应该可以在您的系统中使用、尤其是在使用时、它符合所提供的文档(TRM、数据表等)。