Editing Watchdog timer

{{Short description|Electronic timer used to detect and recover from computer malfunctions}}
[[File:Watchdog timer IC.jpg|thumb|A watchdog timer [[integrated circuit]] (Texas Instruments TPS3823). One pin receives the timer restart ("kick"{{efn|name=fn1}}) signal from the computer; another pin outputs the timeout signal.]]

A '''watchdog timer''' ('''WDT''', or simply a ''watchdog''), sometimes called a ''computer operating properly timer'' (''COP timer''), is an electronic or software [[timer]] that is used to detect and recover from [[computer]] malfunctions.<ref name="ti_appnote"/> Watchdog timers are widely used in computers to facilitate automatic correction of temporary hardware faults, and to prevent errant or malevolent software from disrupting system operation.

During normal operation, the computer regularly restarts the watchdog timer to prevent it from elapsing, or ''[[timeout (computing)|timing out]]''. If, due to a hardware fault or program error, the computer fails to restart the watchdog, the timer will elapse and generate a timeout signal. The timeout signal is used to initiate corrective actions. The corrective actions typically include placing the computer and associated hardware in a safe state and invoking a computer [[reboot]].

[[Microcontroller]]s often include an integrated, on-chip watchdog. In other computers the watchdog may reside in a nearby chip that connects directly to the [[CPU]], or it may be located on an external [[expansion card]] in the computer's chassis.

==Applications==

[[File:NASA Mars Rover.jpg|thumb|Watchdog timers are essential in remote, automated systems such as this [[Mars Exploration Rover]]]]

Watchdog timers are commonly found in [[embedded system]]s and other computer-controlled equipment where humans cannot easily access the equipment or would be unable to react to faults in a timely manner. In such systems, the computer cannot depend on a human to invoke a reboot if it [[hang (computing)|hangs]]; it must be self-reliant. For example, remote embedded systems such as [[space probe]]s are not physically accessible to human operators; these could become permanently disabled if they were unable to autonomously recover from faults. In [[robot]]s and other automated machines, a fault in the control computer could cause equipment damage or injuries before a human could react, even if the computer is easily accessed. A watchdog timer is usually employed in cases like these.

Watchdog timers are also used to monitor and limit software execution time on a normally functioning computer. For example, a watchdog timer may be used when running untrusted code in a [[sandbox (computer security)|sandbox]], to limit the CPU time available to the code and thus prevent some types of [[denial-of-service attack]]s.<ref name="grenade"/> In [[real-time operating system]]s, a watchdog timer may be used to monitor a time-critical task to ensure it completes within its maximum allotted time and, if it fails to do so, to terminate the task and report the failure.

==Architecture and operation==

===Restarting===
[[File:WatchdogWindow.png|thumb|300px|Some watchdog timers only allow kicks during a time window. Kicks occurring outside the window have no effect on the timer and may be treated as faults.]]
The act of restarting a watchdog timer is commonly referred to as ''kicking''{{efn|name=fn1|Various terms are used for the act of restarting a watchdog timer. Some (e.g. ''kick'', ''pet'', ''feed'', ''tickle'') draw a connection to [[guard dog]]s, whereas others (e.g. ''tag'', ''ping'', ''reset'') do not. This article uses ''kick'' for consistency.}} the watchdog.<ref name="ESD"/><ref name="SMSWT"/> In electronic watchdogs, kicking is typically done by writing to a watchdog control [[Memory-mapped I/O|port]] or by setting a particular bit in a [[hardware register|register]]. Alternatively, some tightly coupled{{efn|A ''tightly coupled'' watchdog timer is effectively a built-in extension of the processor and, as such, may be accessed by special [[machine language]] instructions which are specific to it.}} watchdog timers are kicked by executing a special [[machine language]] instruction. An example of this is the CLRWDT (clear watchdog timer) instruction found in the instruction set of some [[PIC microcontroller]]s.

In computers that are running [[operating system]]s, electronic watchdog restarts are usually invoked through a [[device driver]]. For example, in the [[Linux operating system]], a [[user space]] program will kick the watchdog by interacting with the watchdog device driver, typically by writing a zero character to {{mono|/dev/watchdog}} or by calling a KEEPALIVE [[ioctl]].<ref name="LinuxWatchdogApi"/> The device driver, which serves to abstract the watchdog hardware from user space programs, may also be used to configure the time-out period and start and stop the timer.

Some watchdog timers will only allow kicks during a specific time window. The window timing is usually relative to the previous kick or, if the watchdog has not yet been kicked, to the moment the watchdog was enabled. The window begins after a delay following the previous kick, and ends after a further delay. If the computer attempts to kick the watchdog before or after the window, the watchdog will not be restarted, and in some implementations this will be treated as a fault and trigger corrective action.<ref name="oracle"/>

===Enabling===
A watchdog timer is said to be ''enabled'' when operating and ''disabled'' when idle. Upon power-up, a watchdog may be unconditionally enabled or it may be initially disabled and require an external signal to enable it. In the latter case, the enabling signal may be automatically generated by hardware or it may be generated under software control.

<gallery class="center" mode="nolines" heights="220" widths="280" Caption="Watchdog state diagrams">
File:Watchdog timer state diagram with autostart.svg|Unconditionally enabled watchdog
File:Watchdog timer state diagram with enable.svg|Watchdog with ''enable'' input signal
</gallery>

When automatically generated, the enabling signal is typically derived from the computer reset signal. In some systems the reset signal is directly used to enable the watchdog. In others, the reset signal is delayed so that the watchdog will become enabled at some later time following the reset. This delay allows time for the computer to boot before the watchdog is enabled. Without this delay, the watchdog would timeout and invoke a subsequent reset before the computer can run its application software — the software which kicks the watchdog — and the system would become stuck in an endless cycle of incomplete reboots.

===Single-stage watchdog===
Watchdog timers come in many configurations, and many allow their configurations to be altered. For example, the watchdog and CPU may share a common [[clock signal]] as shown in the block diagram below, or they may have independent clock signals or in some cases the watchdog may have no clock signal at all. A basic watchdog timer has a single timer which, upon timeout, typically will reset the CPU:

[[File:SimpleWatchdogTimer.gif|300px|center|alt=Block diagram of a simple, single-stage watchdog timer. The common clock is characteristic of basic watchdog microcontrollers.]]

===Multistage watchdog===
Two or more timers are sometimes cascaded to form a ''multistage watchdog timer'', where each timer is referred to as a ''timer stage'', or simply a ''stage''. For example, the block diagram below shows a three-stage watchdog. Depending on the design, this may be implemented with multiple timers, or by emulating multiple timers with a single timer and additional logic.

In a multistage watchdog, only the first stage is kicked by the processor. Upon first stage timeout, a corrective action is initiated and the next stage in the cascade is started. As each subsequent stage times out, it triggers a corrective action and starts the next stage. Upon final stage timeout, a corrective action is initiated, but no other stage is started because the end of the cascade has been reached. Typically, single-stage watchdog timers are used to simply restart the computer, whereas multistage watchdog timers will sequentially trigger a series of corrective actions, with the final stage triggering a computer restart.<ref name=SMSWT/>

[[File:Watchdog3stage.gif|550px|center|alt=A three-stage electronic watchdog timer.]]

===Time intervals===
Watchdog timers may have either fixed or programmable time intervals. Some watchdog timers allow the time interval to be programmed by selecting from among a few selectable, discrete values. In others, the interval can be programmed to arbitrary values. Typically, watchdog time intervals range from ten milliseconds to a minute or more. In a multistage watchdog, each timer may have its own, unique time interval.

==Corrective actions==
A watchdog timer may initiate any of several types of corrective action, including [[maskable interrupt]], [[non-maskable interrupt]], [[hardware reset]], [[fail-safe]] state activation, [[power cycling]], or combinations of these. Depending on its architecture, the type of corrective action or actions that a watchdog can trigger may be fixed or programmable. Some computers (e.g., PC compatibles) require a pulsed signal to invoke a hardware reset. In such cases, the watchdog typically triggers a hardware reset by activating an internal or external pulse generator, which in turn creates the required reset pulses.<ref name=SMSWT/>

In embedded systems and control systems, watchdog timers are often used to activate [[fail-safe]] circuitry. When activated, the fail-safe circuitry forces all control outputs to safe states (e.g., turns off motors, heaters, and high-[[voltage]]s) to prevent injuries and equipment damage while the fault persists. In a two-stage watchdog, the first timer is often used to activate fail-safe outputs and start the second timer stage; the second stage will reset the computer if the fault cannot be corrected before the timer elapses.

Watchdog timers are sometimes used to trigger the recording of system state information—which may be useful during fault recovery<ref name=SMSWT/>—or [[debug]] information (which may be useful for determining the cause of the fault) onto a [[persistence (computer science)|persistent]] medium. In such cases, a second timer—which is started when the first timer elapses—is typically used to reset the computer later, after allowing sufficient time for data recording to complete. This allows time for the information to be saved, but ensures that the computer will be reset even if the recording process fails.

[[File:WatchdogNmiReset.gif|500px|center|alt=Two-stage watchdog timer]]

For example, the above diagram shows a likely configuration for a two-stage watchdog timer. During normal operation the computer regularly kicks Stage1 to prevent a timeout. If the computer fails to kick Stage1 (e.g., due to a hardware fault or programming error), Stage1 will eventually timeout. This event will start the Stage2 timer and, simultaneously, notify the computer (by means of a non-maskable interrupt) that a reset is imminent. Until Stage2 times out, the computer may attempt to record state information, debug information, or both. As a last resort, the computer will be reset upon Stage2 timeout.

==Fault detection==
A watchdog timer provides automatic detection of catastrophic malfunctions that prevent the computer from kicking it. However, computers can have other, less-severe types of faults which do not interfere with kicking, but which still require watchdog oversight. To support these, a computer system is typically designed so that its watchdog timer will be kicked only if the computer deems the system functional. The computer determines whether the system is functional by conducting one or more fault detection tests and will kick the watchdog only if all tests have passed.<ref name="ganssle"/>

[[File:Wdctl screenshot.png|upright=1.5|thumb|Screenshot of <code>[[wdctl]]</code>, a program that shows watchdog status]]
In computers that are running an operating system and multiple [[Process (computing)|processes]], a single, simple test might be insufficient to guarantee normal operation, as it could fail to detect a subtle fault condition and consequently kick the watchdog even though a fault condition exists. For example, in the case of the Linux operating system, a user-space watchdog [[Daemon (computing)|daemon]] may simply kick the watchdog periodically without performing any tests. As long as the daemon runs normally, the system will be protected against serious system crashes such as a [[kernel panic]]. To detect less severe faults, the daemon<ref name="LinuxWatchdogManpage"/> can perform tests that cover various aspects of the system condition, including resource availability (e.g., [[Computer memory|memory]], [[file handles]], CPU time), evidence of expected process activity (e.g., system daemons running, specific files being present or updated), overheating, and network activity.<ref name="LinuxWatchdogTests"/>

Upon discovery of a failed test, the computer may attempt to perform a sequence of corrective actions under software control, culminating with a software-initiated reboot. If the software fails to invoke a reboot, the hardware watchdog timer — if available — will timeout and invoke a hardware reset. In effect, this is a multistage watchdog timer in which the software comprises the first and the hardware WDT the final stage. In a Linux system, for example, the watchdog daemon can be configured to attempt to perform a software-initiated reboot, which may be preferable to a hardware reset as it allows file systems to be safely [[Mount (computing)|unmounted]] and fault information to be logged prior to the reboot. It is essential, however, to have the insurance provided by a hardware WDT, to allow for the case in which a fault causes the daemon itself to malfunction, and thus become unable to invoke a reboot.<ref name="ganssle"/>

==Implementation==

Watchdog timers are implemented in various ways. Some electronic WDTs (e.g., Analog Devices MAX6324) use linear timing circuits that operate without a digital clock signal. Other electronic WDTs, and software WDTs, typically employ digital counters as timers and rely on a clock signal for proper operation.

===Electronic watchdogs===

Electronic WDTs are usually implemented either as a stand-alone [[integrated circuit]] (IC) or as part of a more complex IC. Some stand-alone implementations contain only a WDT, whereas others bundle a WDT with other functions (e.g. [[supply voltage supervisor]]s) in a common IC.

Many microcontrollers have a watchdog "module" consisting of a digital WDT and mechanisms for controlling and monitoring the WDT. Such modules typically include related control and status registers, circuitry for qualifying restart triggers ("kicks"), and routing control logic for the timeout signal. Some microcontrollers provide an analog WDT in lieu of a digital WDT. For example, Texas Instruments' TMS470 microcontroller has an analog WDT that employs an external capacitor and resistor to program the watchdog interval.<ref name="TMS470"/>

====Digital watchdogs====

In microcontrollers and other complex digital ICs, a digital WDT is typically instantiated by synthesizing it from a description written in [[VHDL]], [[Verilog]] or some other [[hardware description language]]. For example, the following VHDL code describes a simple WDT:

<syntaxhighlight lang="VHDL" class="skin-invert">
entity watchdog_timer is
port (
  CLK      : in  std_logic;             -- clock
  INIT     : in  std_logic;             -- initialize watchdog
  KICK     : in  std_logic;             -- restart timer
  INTERVAL : in  unsigned(31 downto 0); -- timer interval in clocks
  TIMEOUT  : out std_logic;             -- timeout indicator
);
end watchdog_timer;

architecture behavioral of watchdog_timer is
process(CLK)
  variable elapsed : std_logic;              -- timeout register
  variable counter : unsigned(31 downto 0);  -- remaining clocks until timeout
begin
  if rising_edge(CLK) then    -- upon rising clock edge
    if INIT = '1' then        --   if watchdog is being initialized
      counter <= INTERVAL;    --     start timer
      elapsed <= '0';         --     reset timeout indicator
    elsif counter = 0 then    --   else if watchdog interval has elapsed
      elapsed <= '1';         --     indicate timeout; timer is halted
    elsif KICK = '1' then     --   else if watchdog is being kicked
      counter <= INTERVAL;    --     restart timer
    else                      --   else
      counter <= counter - 1; --     advance timer
    end if;
  end if;
  TIMEOUT <= elapsed;  -- send register output to TIMEOUT
end process;
end behavioral;
</syntaxhighlight>

====Analog watchdogs====

[[File:Analog WDT.svg|thumb|Simple analog watchdog timer]]
[[File:Analog WDT timing.svg|thumb|Example timing diagram for analog WDT shown above. Four timely kick pulses keep ''V<sub>C</sub>'' below ''V<sub>TH</sub>''. When kicks cease, ''V<sub>C</sub>'' rises above ''V<sub>TH</sub>'' and causes a timeout.]]
Analog WDTs have a ''kick'' input and ''timeout'' output, but lack the clock input signal found in digital electronic watchdogs.

Circuitry and components vary widely among analog watchdogs, but in general, analog WDTs typically base their timing functions on [[capacitor]] charging rates. For example, in the analog watchdog circuit shown to the right, electric current ''i'' gradually charges capacitor ''C'', causing voltage ''V<sub>C</sub>'' to ramp up (rise at a constant rate). In normal operation, periodic "kick" pulses are applied to the kick input. Each kick causes capacitor ''C'' to discharge, thus restarting the voltage ramp-up. However, if the kicks cease or become spaced too far apart in time, ''V<sub>C</sub>'' will rise above threshold voltage ''V<sub>TH</sub>'' and, as a result, the [[voltage comparator]] will assert the ''timeout'' signal.

===Software watchdogs===

Some software watchdog timers are implemented as standard software modules. Examples of these include "Softdog", a [[Device driver#Virtual device drivers|virtual device driver]] which emulates an electronic WDT and conforms to the [[Linux]] watchdog API,<ref name="softdog"/> and [[MathWorks]]' Software Watchdog Timer, a retriggerable one-shot timer which can be instantiated by dragging its GUI representation onto a block diagram.<ref name="mathworks"/> Other software WDTs are typically custom-designed to meet specific requirements.

Every software WDT depends on a timing reference to allow it to accurately track the passage of time. Various mechanisms are commonly available for this purpose. Depending on the computer, and if used, the [[operating system]] (OS), such mechanisms may include programmable interval timers, kernel timers, the [[system clock]], and synchronization objects (e.g., [[semaphore (programming)|semaphores]]) that support timed waits.

The design of a software WDT can be influenced by a number of factors, including the length of the watchdog interval, the time references available for WDT use, CPU loading, how soon the WDT must be kicked after relevant conditions have been met, whether the computer is running an OS and, if so, whether the WDT is intended to run in user or kernel mode. For example, in bare metal applications (program running without an OS), timing references are often limited to [[programmable interval timer]]s (PIT). In such cases, the WDT might be implemented with a PIT in a fashion similar to the [[flowchart]] shown below:

[[File:Flowchart sw wdt pit.svg|500px|center|alt=Flowchart for a software watchdog timer based on a programmable interval timer (PIT), with example application program]]

In the above example, if the application program fails to kick the watchdog (by restarting the PIT), the PIT will reach the end of the watchdog interval and generate an interrupt request (IRQ). The associated interrupt service routine (ISR) will then execute and take corrective action via programmed I/O, system calls, or other software-controlled operations.

==See also==
* [[Command-loss timer]]
* [[Safe mode (spacecraft)]]
* [[Deadman timer]]
* [[Power-up timer]]
* [[Heartbeat (computing)]]
* [[Keepalive]]

==Notes==
{{Notelist}}

==References==

{{Reflist|refs=

<ref name="ti_appnote">{{cite web |title=What Is a Watchdog Timer and Why Is It Important?
 |access-date=2025-02-06 |url=https://www.ti.com/document-viewer/lit/html/SSZTAH7
 |author = Odom, Kelvin |publisher=[[Texas Instruments]]
}}</ref>

<ref name="grenade">{{cite web |title = The Grenade Timer: Fortifying the Watchdog Timer Against Malicious Mobile Code
 |url = http://www.cl.cam.ac.uk/~rja14/Papers/grenade.pdf
 |author1=Stajano, Frank |author2=Anderson, Ross |name-list-style=amp
}}</ref>

<ref name="ESD">{{cite web |title = Watchdog Timers
 |access-date = 18 February 2013 |url = http://www.embedded.com/electronics-blogs/beginner-s-corner/4023849/Introduction-to-Watchdog-Timers |date=October 2001
 |author1=Murphy, Niall |author2=Barr, Michael |name-list-style=amp |publisher = Embedded Systems Programming
}}</ref>

<ref name="SMSWT">{{cite web | title = Single and Multistage Watchdog Timers
 |access-date = 10 September 2013 |url = http://www.sensoray.com/downloads/appnote_826_watchdog_1.0.0.pdf
 |author=Lamberson, Jim |publisher = Sensoray
}}</ref>

<ref name="ganssle">{{cite web |title=Great Watchdog Timers for Embedded Systems
 |access-date=23 January 2025 |url=https://www.ganssle.com/watchdogs.htm
 |author=Ganssle, Jack |publisher=The Ganssle Group
}}</ref>

<ref name="LinuxWatchdogApi">{{cite web |title=The Linux Watchdog driver API
 |access-date=20 January 2021 |url=https://www.kernel.org/doc/html/latest/watchdog/watchdog-api.html
 |author=Weingel, Christer
}}</ref>

<ref name="LinuxWatchdogManpage">{{Cite web |title=Watchdog 'man' page
 |access-date=2013-09-10 |url=http://linux.die.net/man/8/watchdog
}}</ref>

<ref name="LinuxWatchdogTests">{{Cite web |title = Linux Watchdog - General Tests
 |access-date=2013-09-10 |url=http://www.sat.dundee.ac.uk/~psc/watchdog/watchdog-general-tests.html |date=2013-09-05
 |archivedate=2013-09-14 |archiveurl=https://web.archive.org/web/20130914063114/www.sat.dundee.ac.uk/~psc/watchdog/watchdog-general-tests.html
 |author=Crawford, Paul
}}</ref>

<ref name="TMS470">{{cite web |title=TMS470R1x System Module Reference Guide
 |access-date=15 January 2025 |url=https://www.ti.com/lit/ug/spnu189h/spnu189h.pdf?ts=1736971288567
 |publisher=Texas Instruments
}}</ref>

<ref name="oracle">{{cite web |title=Watchdog Timers
 |url=https://docs.oracle.com/javame/config/cldc/rel/3.4/core/da/html/device_access/watchdog.htm |website=Java ME Embedded Device Access API Guide |publisher=Oracle |access-date=8 February 2025}}</ref>

<ref name="softdog">{{cite web |title = Softdog
 |access-date = 9 February 2025 |url = https://tools.bitfolk.com/wiki/Softdog
 |publisher = BitFolk
}}</ref>

<ref name="mathworks">{{cite web | title = Software Watchdog Timer block
 |access-date = 9 February 2025 |url = https://www.mathworks.com/help/mcb/ref/softwarewatchdogtimer.html
 |publisher = MathWorks
}}</ref>

}}

==External links==
{{Wikibooks | Embedded Systems | Watchdog Timer}}
* [https://www.inspiringtechweb.in/p/arduino-watchdog-timer-with-reset.html Arduino Watchdog Timer with Reset] - Article by Adityapratap Singh

[[Category:Embedded systems]]