Cheap Of-the-Shelf Raspberry Pi Hardware Watchdog
<-Hardware Watchdog - Need Information

Back in October I asked for any help about a less common hardware watchdog meant for cryptocurrency mining rigs. Here is an image of the device.

That plea generated exactly zero (0) replies. There could be three reasons for this.

None of these explanations is particularly pleasing. No matter, let's put on a brave front and plod on. After the timing tests done with an ESP8266 as described in a previous post, I did some electrical tests. Take what follows with a grain of salt as I am definitely not an expert. My test equipment is pretty much limited to a cheap digital voltage, current and resistance meter.

The reset pins that are connected directly to the poles of the relay. Some describe such a relay as having dry contacts. It means that they are completely isolated and can be connected to a Raspberry Pi without problem. The HDD LED connector is an input but I nevertheless tested and found only a very small voltage across the pins. Surprisingly, neither pin is directly connected to the USB connector ground, which I guess is also a good thing. The more obvious problem is the operating voltage of that input. The two mystery chips on the little board are connected to 5 volts. Will a 3.3 volt signal be sufficient?

I dug up an old 2nd generation Pi to run some tests; no point in endangering a more recent Raspberry Pi. In truth, the likelyhood of anything bad happening seemed pretty low. After installing Raspbian Buster Lite, I upgraded the OS which gave me just about enough time to write a first draft of this post. Then a virtual Python environment was created and two Python modules with pip: RPi.GPIO (0.7.0) and gpiozero (1.5.1) for handling the Pi GPIO pins were added to the environment. A very simple Python script, named wdfeed.py emulates a computer hard disk drive activity indicator.

pi@oldpi:~ $ ve .syspy (.syspy) pi@oldpi:~ $ cd .syspy (.syspy) pi@oldpi:~/.syspy $ pip install rpi.gpio ... Successfully installed rpi.gpio-0.7.0 WARNING: You are using pip version 19.3; however, version 19.3.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. (.syspy) pi@oldpi:~/.syspy $ pip install --upgrade pip ... Successfully uninstalled pip-19.3 Successfully installed pip-19.3.1 (.syspy) pi@oldpi:~/.syspy $ pip install gpiozero ... Successfully installed colorzero-1.1 gpiozero-1.5.1 (.syspy) pi@oldpi:~/.syspy $ nano wdfeed.py

Note how I dutifully followed the advice to update pip before proceeding with installing the second module. Below is the content of /home/woopi/.syspy/wdfeed.py.

from gpiozero import LED from time import sleep led = LED(4) while True: led.on() sleep(0.1) led.off() sleep(0.1) led.on() sleep(0.1) led.off() sleep(1)

I then connected the watchdog HD+ to pin 7 of the Raspberry Pi GPIO header (that is BCM pin 4 or GPIO4) and the HD- to pin 9 (GND) of the header. After inserting the watchdog USB jack into one of the RPi USB ports, the script is started.

(.syspy) pi@oldpi:~/.syspy $ python wdfeed.py

While it was initially heartening to see the double flash of red every second between the orange relay and the HDD LED connector, it was disconcerting to hear the relay click a couple of minutes later on. Clearly, the watchdog was not being "fed". The instructions about the polarity connecting the HDD activity pins were ambiguous. Inverting the lines meant the LED no longer flashed but the relay was blissfully quiet. So that confirmed that HIGH signal from the Raspberry Pi which is nominally 3.3 volts but could be as low as 1.6 volt was decoded correctly by the watchdog which runs at 5 volts. Time to move on to the real test.

The first step was to add an entry in the root schedule of tasks to start the script at boot time.

pi@oldpi:~ $ sudo crontab -e

The @reboot command instructs cron to execute the following command (as root) every time the Raspberry Pi is booted.

... # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command @reboot /home/pi/.syspy/bin/python /home/pi/.syspy/wdfeed.py &

It is important to use the Python in the virtual environment to run the script because the needed gpiozero module is not installed in Buster Lite (it may be installed in the Desktop versions of Raspbian Buster). The trailing &, which leaves the script running in the background, must not be forgotten.

There is provision for a hardware reset button on the Raspberry Pi although the two pin header has to be soldered in. After that, it was a simple matter to connect the two RST pins of the watchdog to the Raspberry Pi reset pins. There is no polarity to respect, this is just a switch.

Pi with connected watchdog The yellow arrow points to the Raspberry Pi reset connector.
Also connected to the header is a dusk sensor based on the LDR visible above the case.

The photograph shows the "mining rig watchdog" getting its power from the Raspberry Pi model 1. This did not work on a Raspberry Pi model 3 B. I assume that the USB connector is powered up by the boot sequence which is never launched because the relay is normally closed when the watchdog is not powered. Hence the RUN button remains shorted to ground. Using a normally closed relay was a design flaw in my estimation. The hardware watchdog must have an independent power supply.

Power was applied to the Raspberry Pi with everything wired up and with the watchdog connected to the USB port. The Pi had plenty of time to complete its boot sequence, including starting the watchdog feeding script so that the watchdog did nothing. I did verify that it was running using htop.


htop showing script

The script uses up 0.6%-0.7% of the CPU time when writing to the GPIO port for a few milliseconds every second and 0% when sleeping.

The fork bomb shell script is a good way to test the effectiveness of the watchdog. Here is the script saved under the name forkbomb.sh.

#!/bin/bash swapoff -a :(){ :|:& };:

To see what was happening, htop was left running in one ssh session while the "bomb" was launched in another.

pi@oldpi:~ $ sudo bash forkbomb.sh

Almost immediately, htop froze. Then the session in which forkbomb was launched became unresponsive and eventually the connection was interrupted.

pi@oldpi:~ $ sudo bash forkbomb.sh pi@oldpi:~ $ pi@oldpi:~ $ pi@oldpi:~ $ pi@oldpi:~ $ packet_write_wait: Connection to port 22: Broken pipe

After a couple of minutes, the watchdog began to turn the relay on and off and after a bit more than a minute, it turned the relay off (open) for long enough leaving the Raspberry Pi enough time, 150 seconds to reboot and start feeding the watchdog. Success!.

In summary, the cheap (fake) USB watchdog can be used with a Raspberry Pi. Run a script that toggles GPIO pin XX every second or so and then connect the four watchdog header pins to the Raspberry Pi as shown below.

WatchdogRaspberry Pi
RST1RUN connectorno polarity
RST2RUN connector
HD-GPIO Pin XXflip the connectors if the LED between the connector and the relay begins to flash
HD+Ground Pin
On older models the RUN or P6 connector provided one pin connected to ground, and a second pin connected to the RUN pin on the SOC which is pulled to 3.2 V by a voltage divider across the 5V rail. Be careful with newer 3 B+ and 4 models as the pin connections have been changed. According to the RPi 3B+ schematic, pin 1 is connected to the GLOBAL_EN input of the XR77004 pmic and pin 2, labelled RUN, is connected to PG2 of the same power management chip. Both are pulled to approximately 3.3 V, pin 1 through a voltage divider across the 5 V rail, pin 2 through a 10 K resistor connected to the 3.3 V rail. I would assume that these pins should not be shorted. To ground the RUN pin, it will be necessary to connect a wire to one of the ground pins on the GPIO header. The RPi 4 schematic shows that the RUN header has three pins, Pin 1 is again labelled GLOBAL_EN, Pin 2 is Ground and Pin 3 is labelled RUN_PG2. The following note appears to the right **NOTE RUN IS 3V3, GLOBAL_EN IS 5V**. Indeed, the connection for the GLOBAL_EN is pulled to 5 V through a 100 K resistor, but it could be grounded by a MOSFET controlled by a GLOBAL_RESET signal that I know nothing about. However it looks like pins 2 and 3 could be used directly as described here. I have verified none of this as I do not have either model of the Raspberry Pi. Also, I have no idea what to make of GLOBAL_EN and its relative merit to the RUN_PG2 input. Search on the Raspberry Pi Forum for "RUN reset header" for more information.

While this device works, it is not perfect. A hard reset could corrupt the SD card; it is the equivalent to abruptly turning the power off and then back on. Not only does the watchdog initiate a hard reset without first attempting a reboot, it actually performs about 8 resets before finally giving the Raspberry Pi a time enough to boot.

There is another little "gotcha". If you issue a shutdown command or something equivalent, then you have only a minute or two to manually remove power from the Raspberry Pi. Otherwise, the watchdog will reset the computer and it will reboot.

I will use this device for the time being. Another retiree with a penchant for this kind of stuff with whom I have the pleasure of corresponding is planning to use a Raspberry Pi Zero as a watchdog. I am sure he will be able to do something rather better with attempts at rebooting before resorting to a single hard reset if nothing else works. I may imitate him but I am still hoping that my supplier sends the ubiquitous USB watchdog with two relays ordered months ago. So far the promised replacement for the plastic jewellery shipped instead of the watchdog has not materialized.

<-Hardware Watchdog - Need Information