Can you tell us what the current situation of Particle OS using nRF52840’s internal watchdog circuit may be?
hi, maybe this video can be of help? Posted by a fellow (and very sharp) community member.
Thank you @gusgonnet,
I have seen this, but wonder why Particle has not officially adopted `use of the hardware watchdog. It would seem to be easily implemented in Particle OS.
Is there an issue behind it.
@pmjackson, actually, implementing a hardware-based watchdog is not as easy as that. The same request was made for implementing the Photon/Electron H/W watchdog:
The reasons for not implementing it then still apply. The current Software Application Watchdog, implemented with FreeRTOS, still is not a true watchdog as it get “petted” during
delay() and other long DeviceOS operations and, as such, is not truly under user control.
Thank you @peekay123,
That post was insightful.
Question? The post was started almost two years ago with the last comment around 6 months ago.
Do you know what Particle’s road map might be towards implementing H/W watchdog?
I appreciate that Particle’s OS and RTOS are complex and multi-threaded.
However, as a hardware/software designer, hard fault protection is a most critical issue.
Or is it suggested for users to implement their own external H/W at the moment?
@pmjackson, I don’t believe Particle’s focus is on implementing the hardware watchdog anytime soon. I would suggest using an external watchdog, as many have, which can also power off the entire device (via EN pin), not just reset the MPU. Many have chosen the TPL5110 but I am sure there are other devices you could use.
As an alternative to the TLP5110, I’ve used other AVR chips such as the atmega328 and attiny85 as watchdogs for my particle MCU’s. I handshake over I2C with the AVR chips to the particle chips and they both have the ability to reset each other in case of an unrecoverable condition. Sort of a double watchdog technique. What’s great about this method is a completely custom timing mechanism for watchdog mechanics based on millis() timers.
While slightly off topic from your post, a technique like this could help you while we wait for the firmware inclusion of the Gen3 hardware watchdog.
Have you used this technique with Boron LTE to recover cellular connection?
I have not. I focus mostly on the photon and argon. From what I’ve read, pulling the rst and en pins on the boron won’t recover the connection 100% of the time… only a complete power cycle. Here’s something I’ve done successfully in the past for situations like that. Wire the pin you’re using to reset the boron from your external watchdog to a transistor setup like the ULN2308a to “lift” the ground from the boron in order to power cycle it. This is far from ideal because it means your boron ground is not directly connected to your pcb ground. This is just meant as a stop gap measure until all the connection issues get sorted.