Hey All,
Just wondering whether anyone has gotten the new watchdog working with timeouts over 131 seconds. I’ve discovered what is appearing to be an integer maths error somewhere down in the guts of the OS code, but I’m not sure whether it’s just that I’m doing something wrong.
Initial Issue - I was using the std::chrono literals to try and set a 5 minute timeout (either 5min or 300s). When I stopped refreshing the watchdog to check my timeouts, I was getting reboots after ~35 seconds rather than the requested 5 minutes.
Minimal test case looks something like this (only valid on OS 5.3):
void setup(){
Watchdog.init(WatchdogConfiguration().timeout(300s));
Watchdog.start();
}
void loop(){
/* Uncomment this line for normal operation.
Commented out to force-trigger WDT resets.
Resets after ~35 seconds, although specified timeout is 5 min */
// Watchdog.refresh()
}
After a fair bit of digging, I have uncovered that a 131 second timeout works as expected, but a 132 second timeout gives a pretty much constant watchdog resets.
I believe the root cause is that the timeout is being passed around as a uint32, which is fine if working in milliseconds, but when it’s multiplied up by the 32.768 kHz watchdog tick frequency, it hits an integer overflow at ~131.07 seconds: 2^32 / 32768 = 131,072 mSec, so it needs to be promoted to a uint64 before the multiply happens (or the 32768 constant needs to be UL’d).
Given that the WatchdogConfiguration().timeout() method only takes a system_tick_t argument, which is casting to a uint32 for me, does anyone know whether there’s a way I can fix this at an application layer, or will it need a Device OS patch to fix (and does anyone know how long that would be likely to take)?