Could some say why Particle is not using the watchdog system found in the nRF5280?
Or is the Gen 3 firmware using it already?
1 Like
Actually nRF52840!!!
Thank you! Very interresting: https://youtu.be/Xb6dkEHLASU
1 Like
Tried this watchdog approach on an Argon with 0.9.0 and 1.2.0 beta1, and it does seem to work for some cycles, but left running it appears to end up in DFU mode (yellow blinking) within 5 minutes:
int aThing = 60;
int led2 = D7;
void setup() {
pinMode(led2, OUTPUT);
if (System.resetReason() == RESET_REASON_WATCHDOG) {
// TBD
}
Log.info("Hello");
//Particle.publish("log", ("Hello"), PRIVATE);
WatchDoginitialize();
}
void loop() {
digitalWrite(led2, HIGH);
delay(1000);
digitalWrite(led2, LOW);
delay(1000);
static unsigned long lastTime = 0;
if (millis() - lastTime >= 30*1000){
lastTime = millis();
Log.warn("while(1)");
Particle.process();
while(1);
}
WatchDogpet();
}
// https://youtu.be/Xb6dkEHLASU
#define WATCHDOG_TIMEOUT_MS 30*1000
#define WDT_RREN_REG 0x40010508
#define WDT_CRV_REG 0x40010504
#define WDT_REG 0x40010000
void WatchDoginitialize() {
*(uint32_t *) WDT_RREN_REG = 0x00000001;
*(uint32_t *) WDT_CRV_REG = (uint32_t) (WATCHDOG_TIMEOUT_MS * 32.768);
*(uint32_t *) WDT_REG = 0x00000001;
}
#define WDT_RR0_REG 0x40010600
#define WDT_RELOAD 0x6E524635
void WatchDogpet() {
*(uint32_t *) WDT_RR0_REG = WDT_RELOAD;
}
Is there some system check for multiple resets within a certain timeframe or similar, that will send the device into DFU mode eventually?
It could probably be worked around by letting the watchdog reset startup detection use a pin to pull the physical RST pin. Then it is not a repeat watchdog reset.
But sadly, while maybe finally having that HW watchdog I have sought for so long, only power cycling will actually keep the platform running for sure:
Hello @thrmttnw. A question about connectivity.
I am testing Boron LTE.
During the non-connected Particle Cloud…Do you know if you can send/receive UDP packets?
Or is all connectivity gone?
Don’t know, but my best guess is yes, as the startup seems normal, so an initial cloud handshake seems to indicate all is well, when afterwards it is actually not so.
It could be an experiment to send logging wo. the cloud to check this next time, but for our application we need to reconnect to the cloud for OTA updates - it is a main point.
0.9.0 is the third sw release where pressing RESET does not bring back the cloud on Argon, but power cycling is needed. I only tried the RST pin and EN pin on 0.9.0, as a hardware watchdog is obviously needed for a remote product.
Since reconnecting to the cloud has been the recurring problem for the Argon here, putting this in the code above, might be an effective alternative to an external power cycling watchdog:
if (System.resetReason() == RESET_REASON_WATCHDOG) {
Particle.publish("spark/device/session/end", "", PRIVATE);
}
Now, if there is another reason why the watchdog would be activated repeatedly this could rake up the bill on a GSM device quickly though.
Maybe relevant for this thread, is why we have decided at work not to use this discovery here or anything like it, and instead apply an external watchdog or drop the platform as a viable part of a product at work.
(At home I love to play around with this a lot, only mesh is still a bit to dicy for my applications).
During recent events it became clear that Particle management seems likely to only use HW watchdogs internally for system monitoring to ensure system integrity. Fair enough.
As product designers with a Particle module included, we are obligated to decide for our selves in our designs, how to monitor the functionality of the wider system, and when and how to power up/down and reset different parts of the board including this module with our App on it. I am used to the main MCU having a HW watchdog for this.
The Particle system can never know what functionality the App is aiming to achieve in the wider system, the situational importance of it to the users of that functionality, and therefore what is considered acceptable, critical or fatal in that context. Only the App made by the product designer on the module can “know” those specifics.
So when the platform do not expose a HW watchdog to this App, it should be fair to openly discuss external watchdogs on this forum, and how to achieve product design goals with it.
Sorry, if this is obvious to everyone else, but I just recently realised this after many many weeks on the forum and the docs this and earlier years, trying to find out why there was no HW watchdog exposed to the application, why pulling the RST pin or now the EN pin do not always get the module online again, and what it takes to achieve it.
So far this is the best approach I have seen on the forum for the needs of the projects I am looking at now:
3 Likes
Hi There, did you ever figure out a fix for this? I am having the same issue using Hardware Watchdog on the Particle Argon. It runs for a few cycles and then goes back into dfu mode also.
I spent some hours going through the source trying to find the handling of this without luck. As far as I have seen, no one have received answers to questions related to the HW watchdog topic for months, so unfortunately it seems to be a banned topic.
I have tried this.
First by means of a soft(ware) System.reset() line in the code that was executed in case a Hardware Watchdog Reset was detected after start-ip. This did not work.
Then by driving a pin LOW that is externally connected to the RST pin of the Argon. Same result...
In both cases the system eventually locks up in dfu-like state (fast blinking yellow RGB LED).
The only way to get out of this state is Power Down -> Power Up.
It appears that the nRF52840 'somewhere' keeps track of the previous Hardware Watchdog reset action and does not clear this track when going through a pin (or system) reset.
Anyone there understanding what is really going on?
If you had some external means to pull EN low both the nRF controller and the NCP will be depowered.
IIRC, the NCP reset pin is not tied in with the RST pin on the device.
How about combining the 2 comments/quotes below?
Could the device self-trigger the EN Pin Shutdown (w/ a GPIO Pin to EN) during Start-up, if the Hardware Watchdog Reset was detected after start-up?
I know a Boron can self-perform an EN Pin "full reboot".
On Argon and Xenon pulling EN low will kill the entire 3.3V rail so you need to make sure that when the pin is pulled low some other 3.3V source will pull it back up to restart the device.
Typically there is also a minimum time required the pin needs to be held low to ensure a proper de-powering of the entire system so any internal GPIO will not work without extra circuitry.
2 Likes
I know slightly off topic but until the HW capability is exposed through DeviceOS, here is a simple external WD idea that will work in most use cases - if you are designing your own PCB carrier then this is a quick addition
1 Like
Yesterday I did not have anymore time to work and think on this problem. In the mean time shanevanj pointed to a hardware solution previously developed and in detail described by rickkas7: DeepReset ( GitHub - rickkas7/DeepReset: Tutorial for power cycling an Argon, Boron, or Xenon using the EN pin ).
This will most certainly work for Particle Gen3 devices (as for many others), but it requires extra hardware. Thus it seems that for the time being there is not a nice Hardware WatchDog solution for Gen3 devices as there is for the Photon using the STM32F2’s IWDG like in this library: photon-wdgs by Kevin Kasal, Alexander Partsch (2015).
Great to see tangible info on what actually works (enable pin for 30s).
Mmm. I have tried this on Argon 0S 1.5.0. and it’s been running for an hour without problem.
1 Like
I’ve been using WCL’s HW WDT for over 6 months. No problems.
1 Like