# nRF52840 Hardware Watchdog Question

**URL:** <https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197>\
**Category:** Hardware\
**Tags:** boron, argon, xenon\
**Created:** [April 19, 2019, 10:48am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197 "2019-04-19T10:48:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![pmjackson](https://avatars.discourse-cdn.com/v4/letter/p/59ef9b/32.png) [@pmjackson](https://community.particle.io/u/pmjackson)\
**Post date:** [April 19, 2019, 10:48am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/1 "2019-04-19T10:48:28Z")

</div>

Could some say why Particle is not using the watchdog system found in the nRF5280?  
Or is the Gen 3 firmware using it already?

---

<div class="post-metadata">

**Author:** ![pmjackson](https://avatars.discourse-cdn.com/v4/letter/p/59ef9b/32.png) [@pmjackson](https://community.particle.io/u/pmjackson)\
**Post date:** [April 21, 2019, 11:32pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/2 "2019-04-21T23:32:58Z")

</div>

Actually nRF52840!!!

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 3, 2019, 11:40am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/3 "2019-05-03T11:40:38Z")

</div>

Thank you! Very interresting: [https://youtu.be/Xb6dkEHLASU](https://youtu.be/Xb6dkEHLASU)

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 7, 2019, 11:43am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/4 "2019-05-07T11:43:20Z")

</div>

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:

```auto
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?

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 8, 2019, 9:49am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/5 "2019-05-08T09:49:11Z")

</div>

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:

> [@Argon breathes cyan but can't be signaled nor flashed](https://community.particle.io/t/argon-breathes-cyan-but-cant-be-signaled-nor-flashed/47859/38):
>
> Same experience again with a stand-alone Argon running 0.9.0. Was about to update it. Again a hardware reset does not get it online. Surprisingly the EN pin did not get it online either … In both cases the Argon restarts and blinks green for a few seconds then signalling that it is online breathing Cyan. But the console show it as offline - even after reloading. Can’t ping or signal. Also it is not performing it’s function (AC control). After a short while the Argon blink cyan for a few seco…

> [@Over 20 Devices just went down](https://community.particle.io/t/over-20-devices-just-went-down/49489):
>
> We have over 20 test devices running, all of them went down at the same time today. Around 3PM. Did something happen?!

---

<div class="post-metadata">

**Author:** ![pmjackson](https://avatars.discourse-cdn.com/v4/letter/p/59ef9b/32.png) [@pmjackson](https://community.particle.io/u/pmjackson)\
**Post date:** [May 8, 2019, 12:33pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/6 "2019-05-08T12:33:14Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 8, 2019, 1:01pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/7 "2019-05-08T13:01:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 8, 2019, 9:49pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/8 "2019-05-08T21:49:03Z")

</div>

> [@How to force a handshake for OTA updates](https://community.particle.io/t/how-to-force-a-handshake-for-ota-updates/36836/32):
>
> Have you tried Particle.publish("spark/device/session/end", "", PRIVATE); Publishing this event will disconnect your session and force a new session to be created. Don’t call it too often, as it will use several K bytes of data to re-authenticate and create a new session, but it should work for force it.

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:

```auto
    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.

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [May 10, 2019, 8:02pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/9 "2019-05-10T20:02:07Z")

</div>

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:

> [@Boron / Xenon / Argon Carrier for Outdoor Applications](https://community.particle.io/t/boron-xenon-argon-carrier-for-outdoor-applications/48750):
>
> All, I will be creating a carrier board for the Boron to support outdoor use. Here are the main items I plan to include: Temp sensor in case I need to control LiPo charging External watchdog timer - connect to either Enable or !RST Single - button on / off so you can leave the battery and power plugged in The ability for the device to power-cycle itself ESD and fuse protection Headers for i2c, SPI and IO Big capacitor on DC-IN to support Solar Powered use case Please take a look. Comments a…

> [@Low-Power Boron LTE, using the EN Pin](https://community.particle.io/t/low-power-boron-lte-using-the-en-pin/46257):
>
> After testing various small Solar Panels for the Boron LTE in this [post](https://community.particle.io/t/boron-lte-w-solar-trials/46014), I decided to figure out how to operate a Low Powered Boron while we are awaiting Sleep Modes for Gen3. (Special Thanks to @Rwb for your help!) The answer is the EN (Enable Pin), which works for all Gen3 Mesh Devices. I’m now running 2 more field Trials: Boron LTE, 0.5-watt Solar Panel, 2,000 mAH Li-Po, external Timer for EN Pin to Shutdown Boron between scheduled Publishes @ 5 minutes, TMP36 to monitor temperatures i…

---

<div class="post-metadata">

**Author:** ![searobea](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@searobea](https://community.particle.io/u/searobea)\
**Post date:** [August 17, 2019, 3:35pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/10 "2019-08-17T15:35:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [August 19, 2019, 10:54am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/11 "2019-08-19T10:54:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Jack\_v\_D](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/jack_v_d/32/11342_2.png) [@Jack\_v\_D](https://community.particle.io/u/Jack_v_D)\
**Post date:** [September 10, 2019, 3:10pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/12 "2019-09-10T15:10:18Z")

</div>

> [@thrmttnw](#):
>
> 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.

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?

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [September 10, 2019, 3:56pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/13 "2019-09-10T15:56:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Rftop](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rftop/32/16896_2.png) [@Rftop](https://community.particle.io/u/Rftop)\
**Post date:** [September 10, 2019, 5:13pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/14 "2019-09-10T17:13:14Z")

</div>

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".

> [@Jack\_v\_D](#):
>
> 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-up.

> [@ScruffR](#):
>
> If you had some external means to pull EN low both the nRF controller _and_ the NCP will be depowered.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [September 10, 2019, 5:28pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/15 "2019-09-10T17:28:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![shanevanj](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/shanevanj/32/21186_2.png) [@shanevanj](https://community.particle.io/u/shanevanj)\
**Post date:** [September 11, 2019, 4:23am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/16 "2019-09-11T04:23:11Z")

</div>

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

> **[rickkas7/DeepReset](https://github.com/rickkas7/DeepReset)**
>
> Tutorial for power cycling an Argon, Boron, or Xenon using the EN pin - rickkas7/DeepReset

---

<div class="post-metadata">

**Author:** ![Jack\_v\_D](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/jack_v_d/32/11342_2.png) [@Jack\_v\_D](https://community.particle.io/u/Jack_v_D)\
**Post date:** [September 11, 2019, 2:12pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/17 "2019-09-11T14:12:37Z")

</div>

> [@shanevanj](#):
>
> rickkas7/DeepReset

Yesterday I did not have anymore time to work and think on this problem. In the mean time [shanevanj](https://community.particle.io/u/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](https://github.com/rickkas7/DeepReset) ).

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).

---

<div class="post-metadata">

**Author:** ![thrmttnw](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/thrmttnw/32/13878_2.png) [@thrmttnw](https://community.particle.io/u/thrmttnw)\
**Post date:** [September 11, 2019, 3:07pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/18 "2019-09-11T15:07:28Z")

</div>

Great to see tangible info on what actually works (enable pin for 30s).

---

<div class="post-metadata">

**Author:** ![iandaintith](https://avatars.discourse-cdn.com/v4/letter/i/5f8ce5/32.png) [@iandaintith](https://community.particle.io/u/iandaintith)\
**Post date:** [May 15, 2020, 6:18pm UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/19 "2020-05-15T18:18:09Z")

</div>

Mmm. I have tried this on Argon 0S 1.5.0. and it’s been running for an hour without problem.

> **[wcltalkstech/videos](https://github.com/wcltalkstech/videos/tree/watchDogTimers)**
>
> Contribute to wcltalkstech/videos development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![TheBigKahuna](https://avatars.discourse-cdn.com/v4/letter/t/ee7513/32.png) [@TheBigKahuna](https://community.particle.io/u/TheBigKahuna)\
**Post date:** [May 26, 2020, 7:02am UTC](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197/20 "2020-05-26T07:02:33Z")

</div>

I’ve been using WCL’s HW WDT for over 6 months. No problems.

[Next page](https://community.particle.io/t/nrf52840-hardware-watchdog-question/49197.md?page=2)