I am using the code that has been referred to on this forum to enable the internal hardware watchdog (not the fake OS-level software-based ApplicationWatchdog class from Particle) on the Boron.
It invariably winds-up in DFU mode after resetting with the hardware watchdog.
Therefore, rather than guaranteeing stability, the hardware watchdog does the frustrating opposite.
It guarantees that your Boron will boot-back-up into an irreparable manual-reset-requring DFU mode, requiring you to drive hours or send a team to your remote site where you were expecting to use the Boron for remote monitoring.
I can find one other person who has reported this: nRF52840 Hardware Watchdog Question - #12 by Jack_v_D
Yet the Particle documentation still says:
The application watchdog requires interrupts to be active in order to function. Enabling the hardware watchdog in combination with this is recommended, so that the system resets in the event that interrupts are not firing.
https://docs.particle.io/reference/device-os/firmware/boron/#application-watchdog
So Partcle officially recommends me to do something that is proven with 100% repeatability to make my device enter a permanent useless, broken state requiring a manual human reset? Great!
This is particularly concerning because of all the cellular reconnection problems I have proven Particle has re-introduced into the Boron sometime after 1.3.1-rc1. (Proof: Stable cellular reconnection newly ruined with Boron 2.0.0-rc1, and perhaps earlier - #4 by robc)
I am having Borons randomly die and need power cycling in far-away, remote locations, and Particle's product's hardware watchdog is failing, because it works but then the Particle OS decides to put the device in dead DFU mode.
I understand @chipmc has a supervisory circuit board, but after reading that long thread, it is totally not a solution. That project apparently 1) never was finished, 2) never had a working external watchdog, and 3) never made it on the retail site where you could order one and they would fully assemble it (not the one just to get the boards, but with the components pre-built).
If I had that level of expertise and time I would simply hook up a literal power relay to a small Atmega and forcibly unpower-repower my failing Boron as required - totally defeating the point of the internal hardware watchdog.
Why doesn't Particle's flagship product have OS software on it that declines to render the hardware watchdog of the chip itself totally useless, by choosing to put the device into DFU mode on start? It seems like a cruel trick. It seems like the Particle code is saying upon such reboots, "Ah, so you activated the internal hardware watchdog instead of using our failing software-based timer watchdog, huh? You're trying to actually use our hobbyist product for high-reliability applications by thinking you can bypass our untested OS code's flaw by power-cycling with the internal hardware watchdog, aren't you, huh? Well take THIS proceeds to boot Device OS into useless DFU mode as if to mock and frustrate the user"
This wouldn't be so pressing if Particle's flagship product had a stable product that would reconnect to the cloud and not enter permanent states of disconnectivity with perfect power and cellular signal (e.g., this morning I had the embarassing experience of having to text a client at a remote site to open up the enclosure and power-cycle the never-reconnecting flashing-green-for-three-days 1.5.0 Boron, which resulted in an instant and perfect connection after the manual power cycle).
But given Particle's disastrous killing of their Boron product post-1.3.1-rc1 by making it enter states of permanent disconnectivity, the hardware watchdog is a must. The software watchdog I have tested, and does NOTHING to recover Borons in such states, unlike power cycle and I'm assuming hardware watchdog.
The following code puts Boron LTE into permanent, endless, yellow-flashing DFU mode on just a few WDT restarts:
SYSTEM_MODE(MANUAL); SYSTEM_THREAD(ENABLED);
void setup() {
WatchDoginitialize();
WatchDogpet();
RGB.control(true); RGB.color(255,0,0);
delay(2000); //Red LED for 2s on startup to indicate correct startup, not having been killed into DFU mode
}
void loop() {
RGB.control(true); RGB.color(255,255,0); delay(1000);
RGB.color(255,0,255); delay(1000); //Alternate colors until 10s HWDT triggered
}
#define WATCHDOG_TIMEOUT_MS 10*1000
#define WDT_RREN_REG 0x40010508
#define WDT_CRV_REG 0x40010504
#define WDT_REG 0x40010000
#define WDT_RR0_REG 0x40010600
#define WDT_RELOAD 0x6E524635
void WatchDoginitialize() { // https://youtu.be/Xb6dkEHLASU
*(uint32_t *) WDT_RREN_REG = 0x00000001;
*(uint32_t *) WDT_CRV_REG = (uint32_t) (WATCHDOG_TIMEOUT_MS * 32.768);
*(uint32_t *) WDT_REG = 0x00000001;
}
void WatchDogpet() { *(uint32_t *) WDT_RR0_REG = WDT_RELOAD; }
Why is this happening? Is there anyway to make this not happen, so that it will never reboot to DFU mode but rather start normally, so we can use the hardware watchdog?
...... verses the possibility of overflowing the tank during a Telemetry Failure.