Wag the watchdog

Launched in January 1994, NASA's Clementine spacecraft spent two successful months mapping the moon before leaving lunar orbit to head towards near-Earth asteroid, Geographos.

A dual-processor Honeywell 1750 subsystem handled telemetry and various spacecraft functions. Though the 1750 could control Clementine's thrusters, it did so only in emergency situations; routine thruster operations were under ground control.

On May 7, the 1750 experienced a floating-point exception. This wasn't unusual; some 3,000 prior exceptions had been detected and handled properly. But immediately after the May 7 event, downlinked data started varying wildly and nonsensically. Then the data froze. Controllers spent 20 minutes trying to bring the system back to life by sending software resets to the 1750; all were ignored. A hardware reset command finally brought Clementine back on-line.

Alive, yes, even communicating with the ground, but with virtually no fuel left.

The evidence suggests that the 1750 locked up, probably due to a software crash. While hung, the processor turned on one or more thrusters, dumping fuel and setting the spacecraft spinning at 80 RPM. In other words, it appears the code ran wild, firing thrusters it should never have enabled. They kept firing until the tanks ran nearly dry and the hardware reset closed the valves. The mission to Geographos was abandoned.

Use of the Arduino Internal WatchDogTimer is problematic at best. The Arduino WatchDog Timer has a Wto of 8 seconds so if you are downloading a new sketch and the old sketch has the WatchDog enabled, then you can get into an infinite reboot sequence. This is called “soft bricking”. The Arduino is then pretty much worthless (without a lot of work), but it is still running. WatchDog expires, bootloader starts, bootload works for a while, WatchDog expires, etc., etc. etc. Some boot loaders now disable the WatchDog appropriately, but beware there are a lot of Arduinos out there that still don’t work. You can update the bootloader but it is not an easy job.

Basically there are 2 types of  Watchdog timers: Hardware and Software. Software WDT’s... , they work, but as the very goal of a WDT is to reset in case of software failure, using a software WDT seems a bit counterintuitive.

From that point of view an External Hardware WDT might be a better option. If you dont need it anymore, or made a mistake, you simply disconnect it.

There are specific  WDT chips available, but the good old NE555 can be used as well.

The workings are as follows:

In this circuit the 555 is configured as an astable oscillator. When free running it will charge C2 till about 2/3rds of Vcc (so about 3.33V) and then generate a negative pulse on pin 3 that is connected to the RST of the Arduino (or other chip). Diode D1 is not essential, but it does protect the Arduino.

The frequency, and thus period of the oscillator is determined by R2, R3 and C2. In its current config the time period til reset is about 69 seconds. At the end of that period the  circuit will generate a LOW pulse that  will reset the attached microprocessor. As the duty cycle of the circuit is far from symmetrical, the LOW pulse will take some 15 mSec which is a useful time.

However, we do not want the processor to restart every 69 seconds, we just want it ro  do its thing unless it hangs and therefore we let the processor restart the  555 oscillator continuously to signal that it is still alive and kicking. We do that by discharging C2 via R1 and we do that simply by using an output pin that we make LOW. So if during each loop of the firmware in the processor we pull that Output pin LOW, the Watchdog knows the processor is still doing its work and only when the program hangs, the watchdog will do a reset after 69 seconds.

It is not sufficient to just make the Output pin LOW to restart the timer, but afterwards it needs to be set HIGH again. However, even if an output pin is HIGH, there still is an internal impedance that could drain C2. Therefore after setting it as OUTPUT and LOW, we set it back to INPUT mode again, because as input the I/O pins of the Arduino have a fairly high impedance.

R1 limits the current that can flow through the sinking pin to abt 9mA (in reality some 6mA). Of course R1 adds to the  time needed to discharge C2, but that does not pose a problem here. (If not given enough time though, the Watchdog will need less than 69 seconds before it is able to send a reset signal again.)

int HeartbeatPin = 8;

  void heartbeat() {// Sink current to drain C2

  pinMode(HeartbeatPin, OUTPUT);

  digitalWrite(HeartbeatPin, LOW);

  delay(300);// Set pin back to High Impedance

  pinMode(HeartbeatPin, INPUT);

}

 

void setup() {

  // Send an initial 

  heartbeat.heartbeat();

}

 

void loop() {

  //your code

  heartbeat();

}