Comtrol eCos - Manual (Page 812)

Synthetic Target Watchdog Device
Target-side Configuration
The watchdog device depends on the generic watchdog support, CYGPKG_IO_WATCHDOG : if the generic support is
absent then the watchdog device will be inactive. Some templates include this generic package by default, but not
all. If the configuration does not include the generic package then it can be added using the eCos configuration
tools, for example:
$ ecosconfig add CYGPKG_IO_WATCHDOG
By default the configuration will use the hardware-specific support, i.e. this package. However the generic watch-
dog package contains an alternative implementation using the kernel alarm facility, and that implementation can be
selected if desired. However usually it will be better to rely on an external watchdog facility as provided by the I/O
auxiliary and the
watchdog.tcl script: if there are serious problems within the application, for example memory
corruption, then an internal software-only implementation will not be reliable.
The watchdog resolution is currently fixed to one second: if the device does not receive a reset signal at least once
a second then the watchdog will trigger and the eCos application will be terminated with a
SIGPWR signal. The
current implementation does not allow this resolution to be changed.
On some targets the watchdog device does not perform a hard reset. Instead the device works more or less via
the interrupt subsystem, allowing application code to install action routines that will be called when the watchdog
triggers. The synthetic target watchdog support effectively does perform a hard reset, by sending a
SIGPWR signal
to the eCos application, and there is no support for action routines.
The synthetic target watchdog package provides some configuration options for manipulating the compiler flags
used for building the target-side code. That code is fairly simple, so for nearly all applications the default flags will
suffice.
It should be noted that the watchdog device is subject to selective linking. Unless some code explicitly references
the device, for example by calling the start and reset functions, the watchdog support will not appear in the final
executable. This is desirable because a watchdog device has no effect until started.
Wallclock versus Elapsed Time
On real hardware the watchdog device uses wallclock time: if the device does not receive a reset signal within
a set period of time then the watchdog will trigger. When developing for the synthetic target this is not always
appropriate. There may be other processes running, using up some or most of the cpu time. For example, the
application may be written such that it will issue a reset after some calculations which are known to complete within
half a second, well within the one-second resolution of the watchdog device. However if other Linux processes are
running then the synthetic target application may get timesliced, and half a second of computation may take several
seconds of wallclock time.
Another problem with using wallclock time is that it interferes with debugging: if the application hits a breakpoint
then it is unlikely that the user will manage to restart it in less than a second, and the watchdog will not get reset in
time.
To avoid these problems the synthetic target watchdog normally uses consumed cpu time rather than wallclock
time. If the application is timesliced or if it is halted inside gdb then it does not consume any cpu time. The
application actually has to spend a whole second’s worth of cpu cycles without issuing a reset before the watchdog
triggers.
However using consumed cpu time is not a perfect solution either. If the application makes blocking system
calls then it is not using cpu time. Interaction with the I/O auxiliary involves system calls, but these should take
708