I'm developing up a project that is designed to run 24/7 (an energy monitor) logging via wifi.

Due to a variety of considerations I've ended up with a design that links an Arduino Nano with an ESP8266-01.

I was considering designing in a watchdog, but had the thought that each of these MCUs could act as the watchdog for the other. My hypothesis is that the likelihood of both going down simultaneously is relatively low, and as both need to communicate with each other regularly, they will know when the other unit has become non-responsive, and they would also be able to initiate a hardware (rather than software) reset on the other device.

Is this a valid/workable approach? Or is there something else I need to consider that would warrant an external watchdog(s)?

EDIT: as there were a few comments re: low-power etc., just wanted to clarify that this will be powered from the 240v supply it monitors (using a switch-mode supply), so this isn't expected to be an issue.

  • If you have not already taken a look at WickedDevice WildFire external watchdog approach I do recommend that: shop.wickeddevice.com/resources/wildfire Jan 12, 2016 at 23:21
  • Thanks Mikael—I had spotted that device, but I'm aiming for a lower overall cost of the unit for this project. It's a nice bit of kit and I suspect will simplify a lot of things for future work/prototyping...
    – Grant
    Jan 13, 2016 at 4:20
  • See my amended reply about devices powered from the mains.
    – Nick Gammon
    Jan 13, 2016 at 10:38
  • I believe both MCU have hardware watchdog timers build into them. I don't see any real advantage in your method. Neither do I see any disadvantage, other than more work to implement. You'd have to run some custom code on the ESP, as opposed to just stock firmware.
    – Gerben
    Jan 13, 2016 at 19:19

2 Answers 2


I had a similar project a while back, including the desire for the watchdog.

My hypothesis is that the likelihood of both going down simultaneously is relatively low ...

Here's the problem. If it is solar powered (or even just battery powered) then the likelihood is quite high that they will both get insufficient power at much the same time (ie. low voltage).

One thing I noticed was that if voltage slowly drops (as it does when the sun goes down, and the battery discharges) then the processor can enter a brown-out situation where it basically just goes dead, without resetting.

Now you can set brown-out detection in the fuses, but the reference voltage generator, needed to make it work, itself increases the power consumption. So you get the situation where the brownout detection drains the battery, causing a brown-out situation, where without brownout detection it might have lasted all night.

Anyway, the net effect was that the design on the linked page wasn't as reliable as I hoped.

To make this answer more complete, here is my watchdog processor schematic:

Watchdog processor schematic

And this was the code for it:

// Reset solar panel watchdog
// Author: Nick Gammon
// Date: 22 March 2015

// Pin 1 is /RESET
//                  +-\/-+
// Ain0 (D 5) PB5  1|    |8  Vcc
// Ain3 (D 3) PB3  2|    |7  PB2 (D 2) Ain1 
// Ain2 (D 4) PB4  3|    |6  PB1 (D 1) pwm1
//            GND  4|    |5  PB0 (D 0) pwm0
//                  +----+


 After reset waits for TIME_TO_WAIT minutes, then brings D0 (pin 5) high for long
 enough to activate a MOSFET and reset the other board.

 Fuses: Low: E2 High: DD

 (Brownout at 2.7V)


#include <avr/sleep.h>    // Sleep Modes
#include <avr/power.h>    // Power management
#include <avr/wdt.h>      // Watchdog timer

const byte MOSFET = 0;          // pin 5 
unsigned long counter = 0;

const float TIME_TO_WAIT = 30; // minutes
const unsigned long SLEEPS_TO_WAIT = TIME_TO_WAIT * 60.0 / 8.0;  // 8 second sleeps

// watchdog interrupt
ISR (WDT_vect) 
   wdt_disable();  // disable watchdog
  }  // end of WDT_vect

#if defined(__AVR_ATtiny85__)  
  #define watchdogRegister WDTCR
  #define watchdogRegister WDTCSR

void setup ()
  pinMode (MOSFET, OUTPUT);
  ADCSRA = 0;            // turn off ADC
  power_all_disable ();  // power off ADC, Timer 0 and 1, serial interface
  set_sleep_mode (SLEEP_MODE_PWR_DOWN);
  }  // end of setup

void loop ()

  if (counter >= SLEEPS_TO_WAIT)
    digitalWrite (MOSFET, HIGH);
    delayMicroseconds (10000); 
    digitalWrite (MOSFET, LOW);
    // our job here is done
    sleep_enable ();       // ready to sleep
    sleep_cpu ();          // sleep                

  goToSleep ();
  }  // end of loop

void goToSleep ()
  noInterrupts ();       // timed sequence coming up
  // pat the dog

  // clear various "reset" flags
  MCUSR = 0;     
  // allow changes, disable reset, clear existing interrupt
  watchdogRegister = bit (WDCE) | bit (WDE) | bit (WDIF);
  // set interrupt mode and an interval (WDE must be changed from 1 to 0 here)
  watchdogRegister = bit (WDIE) | bit (WDP3) | bit (WDP0);    // set WDIE, and 8 seconds delay

  sleep_enable ();       // ready to sleep
  interrupts ();         // interrupts are required now
  sleep_cpu ();          // sleep                
  sleep_disable ();      // precaution
  }  // end of goToSleep 

The design intention here was that the watchdog processor would reset overnight (when the solar panel lost power and the supercapacitor eventually discharged) and in the morning it would power up, wait 30 minutes (for the sun to rise and the voltage to become stable) and then unconditionally reset the other processor from whatever state it was in.

as there were a few comments re: low-power etc., just wanted to clarify that this will be powered from the 240v supply it monitors (using a switch-mode supply)

Yes, well I also live in a country with 240V power. Today during 41°C heat the power failed a number of times for very short intervals. Various computers reset or behaved strangely. Like with a low voltage battery, a brown-out, or brief failure, of the mains power could simultaneously strike all your devices, including the watchdog device.


As a watchdog mechanism to protect against software lockup type issues then using one processor to detect issues and reset the other is an economical idea. However, I would completely agree with Nick that if you want protection from hardware issues like brown outs or slow rise time of the power supply then both micros could share the same vulnerabilities that a dedicated watchdog device would be able to address. How significant this is depends on your power arrangements.

The other case to consider is now much does the software of one device interact with and depend on that of the other device such that it is conceivable that one device locking up in some way could impact the other defeating the watchdog functionality.

Personally I've seen too many situations where an internal micro watchdog failed to detect and recover an issue so would always go for an external device in any professional product. Even there I would advise the use of a devices which requires the watchdog to be kicked within a time window rather than just within a maximum time period - otherwise if things contrive to go wrong in such a way that the watchdog is permanently getting kicked it will not recover the situation. [I saw the micro pin responsible for kicking a simple external watchdog accidentally reconfigured by runaway code as a timer output once.]

I suspect that if you are thinking that your product needs a watchdog then it is worth doing properly with an external one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.