Blog Post Actions
Group Actions
Engagement
  • Author Author: mistertee
  • Date Created: Date Created
  • Views 1128 views
  • Likes 1 like
  • Comments 19 comments
Related
Recommended

Watchdog Timer for the Raspberry Pi

mistertee

Like all PCs the Raspberry Pi is likley to hang up during operation due to unexpected events not being catered for in the code. In an unattended application where the program automatically starts this can be a problem as there is no one around to restart the RPi. If there is no keyboard or HDMI monitor this is by power cycling. The Raspberry Pis internal watchdog timer has a poor reputaion - there are many comments about it being unreliable. This post presents a simple external watchdog timer.

 

Although there are dedicated power supply monitoring chips this solution uses components that are likley to be in most electronic hobbyists kit - based around the popular 555 timer.

 

 

The programme has to supply a Hi going pulse every few seconds. If there is no pulse for more than about 60 seconds the 555 output on Pin 3 will go low. This is coupled through to the on-board reset pin of the Raspberry Pi through a capacitor to issue a low going pulse which resets the Pi.

 

A capcitor is used here so that only a pulse going from Hi to Low will reset the raspberry Pi. A constant Lo voltage which is present while the raspberry Pi is starting up will have no effect.

 

If a shorter time is required then either reduce the value of R1 (1Mohm) or reduce the value of C1 (100 uF).

 

The LED pulses every time a Hi Pulse is issued to provide a visual indication to the user that everything is fine. The 555 timer does not easily provide a retriggerable monostable function that is required for a watchdog timer. Diode D1 is used to discharge the capacitor every time a pulse is received.

 

The reason the delay before a reset is set at more than 60 seconds is that the Raspberry Pi takes more than 30 seconds to start up.

 

Click here for a guide to setting the Raspberry Pi to autostart.

 

 

The image above shows the connection to the Reset pin of the Raspberry Pi.

 

Summary

 

Althogh the Raspberry Pi has an in-built watchdog timer, this has a poor reputaion. This watchdog timer is a reliable way of resetting the Raspberry Pi in remote applications where there is a risk of it hanging up due to the code not handling unexpected events correctly.

Anonymous

  • Hello found your hardware schematic watchdog was looking for this for extra protection io control.

     

     

    When you control eg heater with relay trough raspberry control. Extra safety  is never bad. I like your control with pulse. However reading other comments , instead of resetting pi.

    Catch via input in rasp (output from your timer) running in separate program fault from to restart processes or reboot .

     

    for io control Why not cutoff output or supply to output using your schematic?

    If your rasp is still frozen at least your outputs are disabled.

    If you use different powersupply for io your setup with 555 timer is excellent to cutoff power to all active outputs. eg heater control rasp freezes  outputs stay high. Not a situation that we want.

  • This circuit looks very good ! And the function is not obscured by too much documentation and tons of sw code.

     

    While I agree, there should be no sw-error left, ;-) : this watchdog should catch any remaining error.

     

    Good design !

     

    (One improvement would be very nice : Watchdog get's active only after the first trigger pulse. Would allow to make it's use optional.)

  • in reply to mcb1

    Hi Mark,

     

    Unfortunately I've more experience on other platforms, not Pi, and on those platforms I've never managed to make the Linux kernel die through user space apps (which is what Seggy would be doing, provided he's not writing his own drivers), and I wouldn't say I'm a super-careful programmer, just a "normal" programmer. A good system will generate logs as you say, capture any debug needed and then send alarms, and then do a graceful shutdown, and all this can be done as a process running on Linux (i.e. doesn't need external hardware, regardless of how hung/frozen the user app is). The apps I worked on were mainly sold to run on Solaris, which is famed for rock-solidness, but we had customers who ran it on Linux too and today I've no doubt about the reliability of Linux (which can be further enhanced through system-level redundancy, or load-sharing, etc).

     

    An add-on watchdog isn't useless, it would be useful if the kernel is hanging (which could happen if there were brown-outs or hardware failure issues) but this is different to dealing with buggy Python application code. The watchdog won't perform the steps mentioned above, so it is like a extremely last resort, and if there were such issues I'd want to get to the bottom of each one again, i.e. resolve power issues, replace memory, etc. A hardware watchdog that kicks in for a user application failure (while the kernel is still running) could cause more harm than good, because (a) if the kernel is still running then a software process is more useful because it can capture logs as mentioned and (b) there is a risk of data corruption if other processes are busy writing to storage.

     

    But a software solution too shouldn't kick in regularly either, if it is, then the application code needs a lot more effort..

    In practice, even if it is not life-threatening and there is no agreed up-time, it still at most should only occur infrequently enough that there is plenty of time to debug each restart (across all your customers) caused in this manner, i.e. to minimise customer loss and bad sentiment, and still have time to develop the next great feature/project.

  • in reply to shabaz

    Shabaz

    In theory the python part should be the only part stopped.

    Is it possible to write to a log to show that a forced restart was triggered, and then execute a graceful shutdown via the serial port.

    This avoids the corruption roblem, which could definately cause more issues.

     

    While I agree that software should really handle all the unexpected, and run off to a error handler to stop it locking up, as the Op has pointed out it is during testing that this 'supervisory' device and software could be employed.

    The log should allow it to be run and then checked for restarts.

     

    I'm thinking that this would be a useful add-on for the Pi.

    Mark

  • in reply to mistertee

    You are quite right about the 555, and I used them for all sorts of applications until getting into small micros.

    Ask someone who wasn't raised in the 80's what a 555 is they most likely will need to search the internet and not be able to do two scheamatics from their head.

     

    I have looked at a few because I wan't then for Arduino applications in a critical situation, so the answer is no.

    It's been on my list of projects to add a watchdog timer so it can be used in designs, hence the brown-out detector as well.

     

    Mark.