Repository navigation
node.nmt.wait_for_bootup misses boot message if a bootmessage is immidiately followed by another heartbeat message #560
Description
Activity
This problem seems to be related to how close a "real" heartbeat follows a boot message. The following works very inconsistently
(2025-02-24 10:04:07.801501) can0 RX - - 70C [1] 7F (2025-02-24 10:04:20.469853) can0 RX - - 70C [1] 00 (2025-02-24 10:04:20.470673) can0 RX - - 70C [1] 7F(note how the first heartbeat was <1ms after the boot message)
But this sequence always works as expected:(2025-02-24 10:06:40.321521) can0 RX - - 70C [1] 7F (2025-02-24 10:06:40.404523) can0 RX - - 70C [1] 00 (2025-02-24 10:06:50.094791) can0 RX - - 70C [1] 7F(Time between boot and heartbeat is almost 10 seconds).
Just speculating here: I think that the relevant condition (node.nmt.state_update) gets notified twice with so little time in between that wait_for_bootup never gets the chance to check if self._state_received was ever zero.
I think this is a pretty simple bug, but haven't investigated deeply.
The check for
self._state_received == 0happens after the condition has been released, thus the next PRE-OP heartbeat could already have been processed (which sets the attribute back to 127). Try moving the check within thewith self.state_update:block, see if that fixes the issue.The suggestion by acolomb does not solve the issue.
Adding a new debug statement on line 167 shows that in case two messages come in really close together, the notification does not lead to code execution in wait_for_bootup.
So I believe that self.state_update.notify_all() does not guarantee that all listeners get CPU time immediately, and therefore another CAN message could be handled first, so that _state_received updates twice without wait_for_bootup ever getting CPU time. So I think a separate condition for just boot messages would be required to solve this.
- changed the title
[-]Node boots twice, second boot message cannot be waited for.[/-][+]node.nmt.wait_for_bootup misses boot message if a bootmessage is immidiately followed by another heartbeat message[/+]on Feb 27, 2025 @jackodirks Do you have a specific improvement in mind that solves this problem? Please open a PR in that case. I don't know how to proceed from my side.
- added a commit that references this issue
on Oct 4, 2026
CANopen version 2.3.0
I have this CANopen node that boots twice during an update. Here is the relevant code:
Waiting for the first bootup message always works exactly as expected. Waiting for the second one fails randomly. What is weird is that the second boot message is definitely there:
But it gets ignored, somehow? Eventually the second wait_for_bootup times out.
As said, sometimes this works, but most often it does not seem to work.