neilh10
commented
3 years ago This is the log of the watchdog that fired. It was a stability load that had been running for a couple of days, being monitored through an FTDI based connection, modified to not cause a reset. The monitor had been disconnected for 24hrs, as the monitoring computer was used for another purpose.
Looking at the reporting on https://monitormywatershed.org/sites/tu_rc_test06/ it had been running for some days, and hadn't reset before this event. For this load, the extended watchdog timeout is WATCHDOG ISR barksUntilReset 149 <--WatchDogAVR
When the monitoring computer was plugged in, it just happened to catch it at WATCHDOG ISR barksUntilReset 75 <--WatchDogAVR
Then this was the trace: tty210201-1711test06cont.txt
If the watchdog fires, there is no context to it. It would be valuable to have some bread crumbs as to how it got to the point it fired.
Background: In later stages of 0_27_5 testing, with the watchdog enabled, it "woofed" and the processor reset. But no context for it. The watchdog is useful for preventing a lock up of the processor ~ and this has worked. However, to debug, it would be nice to know some context to what happened. It could be done rather simply with a unique label on the watchdog call.
The watchdog is part of the class Logger ~ - and has a large timeout as not every subsystem has access to it. So a secondary issue is how to make the watchdog call more accessible.