[参考译文] TMS320F28075：清除 CAN 邮箱中 MsgLst 位的序列

Demis、

我现在要查看此帖子。

Demis、

           在您的帖子中概述的方法中、似乎存在无意中清除 NewDat 的风险。 该规范不指示清除 MsgLst 位的任何其他方法。

我假设您在接收 ISR 中检查 MsgLst 位的值、并仅在该位被置位时将其清零。 因此、您将讨论一种同时设置 NewDat 和 MsgLst 位的情况、这意味着在 CPU 有机会传输数据之前、先前接收到的消息已被覆盖(丢失)。 现在、在清除 NewDat 和 IntPnd 位和清除 MsgLst 位的指令之间、确实可以想象一条新消息会到达窗口。 您是否验证了中断是否仍然有效、如果仍然有效、INTxID 字段是否指向已断言中断的邮箱？ 我知道 IntPnd 位与 MsgLst 位一同清零。 尽管如此、当 IntPnd 处于活动状态且应接收中断时、仍有一个窗口

您好、Haresh、
感谢您的分析。

[引用 user="Haresesh J"]
我很好奇您为什么会遇到 MsgLst 情况。 您的应用程序是否已使用所有邮箱？ 或者无法足够快地读取它们？
[/报价]
我不会偶然遇到 MsgLst 情况、而是要特别检查 MsgLst 位是否变为高电平、并了解如何在不影响其他位的情况下清除它。

[引用 user="Haresesh J"]
在修改步骤之前(但在读取步骤之后)、向同一邮箱发送一个帧、并确保 NewDat 和 IntPnd 位为1。 现在、执行写入步骤并验证这些位是否确实清零。
[/报价]
我已经进行了测试、我看到在读取和修改步骤之间接收到帧后、NewDat 和 IntPnd 位为1。 然后、写入步骤之后、NewDat 和 IntPnd 位被清零。

[引用 user="Haresesh J"]
我假设您在接收 ISR 中检查 MsgLst 位的值、并仅在该位被置位时将其清零。
[/报价]
你是对的。

[引用 user="Haresesh J"]
因此、您将讨论一种同时设置 NewDat 和 MsgLst 位的情况、这意味着在 CPU 有机会传输数据之前、先前接收到的消息已被覆盖(丢失)。
[/报价]
再次出现。

[引用 user="Haresesh J"]
现在、在清除 NewDat 和 IntPnd 位和清除 MsgLst 位的指令之间、确实可以想象一条新消息会到达窗口。 您是否验证了中断是否仍然有效、如果仍然有效、INTxID 字段是否指向已断言中断的邮箱？
[/报价]
我已经验证、如果在读取和修改步骤之间收到新消息、INT0ID 字段将指向正确的邮箱(我在测试中使用 INT0中断线路)。 然而、写入步骤之后、INT0ID 被清零、就像 NewDat 和 IntPnd 位一样。

[引用 user="Haresesh J"]
我知道 IntPnd 位与 MsgLst 位一同清零。 尽管如此、当 IntPnd 处于活动状态且应接收中断时、仍有一个窗口
[/报价]
写入步骤后、我清除 CAN_GLB_INT_FLG 寄存器中的 INT0_FLG、这样就不会再发生中断。

无论如何、我已经做了进一步的测试：我已经将代码更改为在 NewDat 和 IntPnd 清除之后清除 INT0_FLG、但在读取步骤之前清除 INT0_FLG。 如果在读取和修改步骤之间收到新消息、INT0ID 字段将指向正确的邮箱、并且 INT0_FLG 再次设置为1。 然而、写入步骤之后、INT0ID 字段被清零、而 INT0_FLG 仍然为1。 所以另一个中断被置为有效、但是 INT0ID 等于0、所以我无法识别中断的原因！

实际上、我认为在中断例程结束之前清除 INT0_FLG 是正确的、如 TI 驱动程序示例所示。

[引用 user="Haresesh J"]
在您的帖子中概述的方法中、似乎存在无意中清除 NewDat 的风险。 该规范不指示清除 MsgLst 位的任何其他方法。
[/报价]
在我们的考虑和测试之后、我认为没有办法避免这种风险、对吧？

感谢您的宝贵支持。

此致、

演示