I'm trying to test the application watchdog

Troubleshooting
22

@peekay123: I am no expert in freeRTOS but doesn’t this link suggest freeRTOS does support the watchdog? https://github.com/DuinOS/FreeRTOS/blob/master/FreeRTOS/Demo/MB96340_Softune/FreeRTOS_96348hs_SK16FX100PMC/Src/watchdog/watchdog.c

@ftideman: Also my implementation of a watchdog (which is based on a common system timer which in turn is based on SparkIntervalTimer) is not fool proof. I have had situations where the system crashed but the dog never barked. This stuff is hard to trace. My gut tells me that I have a stack overrun condition possibly caused by a few interrupt handlers that may be a tad too long. I can fix those things but the problem is I need proof that this was the problem. A long test period without failures is … sadly… not proof.

Anyway, since the watchdog in particle is flakey or cumbersome to implement so that it operates a guaranteed 100%, I decided to provide my own in hw on my own board. Far from ideal but the only practical thing I can do now.

1 Like
23

@joost, I am not 100% sure about FreeRTOS but I remember there was an issue with using the STM32 hardware watchdog. Perhaps @rickkas7 can recall? An external watchdog is THE most reliable way of doing this IMO.

24

Yeah I hear you, you can wait a long time for these dogs to bark…

We’re looking into either trying to use what’s featured on the Electron OR add an external watchdog, to have a 100% reliable fail safe in place. Based on these discussions it sounds that going with the latter is the way to go.

25

@ftideman, the cost of a single GPIO is a good investment IMO. An external watchdog can also help with holding the Electron in RESET mode when the Vcc is too low preventing (possibly) some of the weird flash erasure issues.

1 Like
26

I was finding a long interrupt was causing the system to lockup and the watchdog wouldn’t operate.

I had the priority for the interrupt set one below the default…maybe that is why it had a more adverse effect?