Woof woof
Here is the article my boss has been waiting for and the actual trigger for my blog. One single article was not enough from my point of view, so I started to write articles about all my work with the RevPi.
The RevPi Connect has a built-in watchdog that works independently of the main controller. In addition, there is the integrated relay output, which optionally switches when the watchdog is triggered.
If you have already looked at our tutorial for the Watchdog (https://revolutionpi.com/en/tutorials/ubersicht-revpi-connect/watchdog/) and just thought: “huh?“. At first, I felt the same. After a little bit of trial and error and reading the schematic, you get behind it quite quickly.
How the Watchdog works
The watchdog is deactivated in the delivery state. This is done by connecting input WD to ground (0V). If this connection is released, the watchdog is armed. Therefore, do not touch the wire for the time being. Or who is like me and must have seen everything first, just try it out. If you still have a revision 1.0 of the RevPi Connect, like me, you have an eight-pin connector with more wire bridges. These are for the power supply of the RevPi, so keep your hands off. Starting with revision 1.1 these wire bridges are omitted.
So how does the Watchdog work? Here is a simple drawing. It does not exactly match the schematic. But it doesn’t matter from the user’s point of view. If you still want to know exactly, here you can find the schematic.
The RevPi Connect is equipped with a watchdog timer, which is configured to set its output after 60 seconds if it is not reset in time. In the drawing, the timer is simply marked with T. The watchdog reset is done by toggling the reset input of the timer (WD-Reset). However, the timer only triggers a reset of the RevPi when the input WD of the & becomes true. For this, it is sufficient to disconnect the WD input from 0V and leave it open.
How do you get WD-Reset now? It is well hidden on bit 7 of RevPiLED. Why RevPiLED? Originally one byte was reserved in the process image for the LEDs on the core. In addition, there was the third LED, the relay and the watchdog on the connect. The name has remained. Maybe I can motivate my colleagues to come up with a nicer name for it.
A demo program for the Watchdog
I have named my example program RevPiWatchdog. As basis, I used the sample program RevPiTestOutput from a previous article. I replaced the for loop with an endless while loop and bit 0 with bit 7, because I want to reset the watchdog and not switch any LED. I also set the sleep time to 10s. This is quite enough because the watchdog triggers after 60.
SPIValue spiValue = {0, 0, 0};
spiValue.i16uAddress = spiVariableOut.i16uAddress;
spiValue.i8uBit = 7;
spiValue.i8uValue = 1;
while(true){
spiValue.i8uValue = spiValue.i8uValue^0x01;
piC.SetBitValue(&spiValue);
sleep(10);
}
For testing, I started the program by hand and fiddled the cable on the terminal, which is a bit cumbersome while the program is running. One should not actually do that. If you have tried to remove the wire before, you can see now that it works. It works until the program is finished. Then it takes another 60s and the RevPi resets itself.
systemd
To avoid having to start the program manually every time, it makes sense to start it automatically at startup. Usually, it should be sufficient if the watchdog program is started “sometime” by systemd. Then it is sufficient to copy the systemd service from the last article.
For the sake of clarity I copied the executable file of the program back into ~/projects. Then I created the systemd service file in /etc/systemd/system. For this I simply copied the existing revpiblink.service
sudo cp revpiblink.service revpiwatchdog.service
With sudo nano revpiwatchdog.service I edited the file and replaced in the line ExecStart, revpiblink with revpiwarchdog, so
ExecStart=/home/pi/projects/revpiwatchdog
After saving the file you have to update systemd and activate revpiwatachdog.
Systemctl daemon-reload Systemctl enable revpiwatchdog
Now RevPiWatchdog will be started automatically at every start of the RevPi and will also run with open cable bridge.
When things take a bit longer
My Connect+ needs about 35s until an application is started via systemd with multi-user target. So we have enough time until the 60s have expired after the start and the watchdog triggers. But if you increase the load on the RevPi during startup and you come close to or even exceed the 60s for a complete startup, the moment comes when you have to deal with systemd. In our example, the default for systemd is that our program needs it from the multi-user target. Exactly when to start is in systemd’s hands. If time is short, you have to start earlier.
Practical applications
As it is shown in the example, the program makes no sense in reality, of course. The watchdog should react when the system stops responding. In the case of the example, the watchdog would of course only react if the watchdog program was no longer running. If any other process has started to slip, the watchdog will not notice this. So you either have to build the watchdog directly into your target application or design the watchdog program to monitor the function of the other processes. The latter is of course much more extensive. But if you have several processes running in parallel, this is a reasonable solution. As long as the actual watchdog program is running, you also have the chance to restart processes that have hung up or to perform a soft reboot in the case of an error.