Embedded Canopen节点卡在preop状态

我使用canopen在can总线上有2个节点（x和y）。使用临时节点“z”，我发送一条nmt消息，将所有节点置于预操作状态，然后发送一条命令，将y置于操作状态。然后，我在总线上为节点y发送一组扩展id消息，节点x在其字典中不知道这些消息。在发送到y的过程中，节点x上的节点监视表示它处于preop状态。一切似乎都很好。在完成向节点y发送数据后，我发送一个命令，将所有节点置于操作状态。根据节点x的nmt状态代码，节点x处于preop状态。调试时我发现canopen x中的rx fifo溢出。在preop模式下，它应该忽略所有这些扩展消息吗？我甚至在停止模式下尝试了同样的结果。这是怎么回事？

对于任何CAN总线节点，您都必须连续读取所有传入消息，忽略不感兴趣的消息。CAN控制器中的过滤器设置可能会有所帮助，但要构建坚固的应用程序，您必须始终做好准备，任何ID的CAN消息都可以随时出现。确保这一点的最佳方法是始终连续读取rx fifo缓冲区，并在每次读取时保持读取直到其为空

---

只要存在错误，CANopen节点就会保持预操作状态。或者，它可以发送一条EMCY消息，告知错误的性质，然后在清除错误时发送另一条消息，将所有位设置为零。在这种情况下，NMT主机应等待EMCY clear消息，然后再发送start remote node。

谢谢Lundin。假设我处于canopen NMT状态，例如preop或stopped自动忽略所有消息，但状态允许的其他消息除外，即preop忽略PDO，这是错误的吗？在任何情况下，我都会通过中断处理所有can消息，因此缓冲区永远不会满。。。我没有看到任何埃姆西的消息。。。也许我还有其他问题要解决。如果通过EMCY发送错误，则通过发送NMT消息（如go to reset communication？）清除错误的唯一方法是@Michael Rx FIFO overflow的级别低于CANopen，位于CAN驱动器和CANopen堆栈之间的某个位置。可能在堆栈中对某个控制器进行自适应。CANopen堆栈确实应该在预操作模式下忽略PDO，但这是在应用程序级别。正如我所说，EMCY消息是可选的。但如果您预期会出现某些错误，它们可以帮助控制流量。应该以合理的方式清除错误。如果节点中存在内部错误，其他节点无法清除该错误，但需要处理该错误。事实证明，为STM32提供的CANopen驱动程序假定任何扩展id消息都通过硬件筛选器过滤掉。这导致我的扩展ID消息被读取为未初始化的标准ID消息，该消息的ID=0，也称为NMT消息。这导致了不寻常的行为。谢谢你的指导。@Michael好吧，这太奇怪了。总的来说，我听到了一些关于ST's CAN车手的坏消息。显然有很多虫子。