[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Watchdog device driver
- Date: Thu, 22 May 2008 11:20:53 -0700
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: Watchdog device driver
I am using a simple RPC service to assert that I don't lose
control over some remote development boards.
The RTEMS box runs the RPC service which can be
in two states:
a) client (development host) disconnected.
In this state, the server task periodically pets the HW
b) client connected.
In this state, the client must periodically send a 'PET'
RPC request to the box -- otherwise the server task
stops petting the HW watchdog and a RESET occurs.
(The client can also request an immediate reset).
State 'b' ensures that control is never lost. E.g., it can
happen that the watchdog server task continues to
run happily (and petting the wdog) but there is a deadlock
somewhere freezing the network etc. In state B, if
for whatever reason the client cannot communicate the
PET request then a reset occurs (and if communication
is OK the client can always request a reset).
I have 'implicitly' used a trivial 'API' that is implemented
by a variety of boards I have (and which provide a HW watchdog):
void wdInit(unsigned long interval_us);
Chris Johns wrote:
> Joel Sherrill wrote:
>> I guess it is such a simple device that no one has proposed
>> anything like an API.
>> I would not be opposed to an API for a watchdog timer. I
>> don't see much of an API though since there isn't that much
>> + enable with expiration
>> + reset
>> + disable
>> + is enabled?
>> But a standard API, no matter how simple encourages portability.
> This is a good idea. I see the driver as something like:
> int wd = open ("/dev/wd0", O_WRONLY, 0);
> ioctl (wd, RTEMS_WDOG_RESET); /* reset the watchdog */
> ioctl (wd, RTEMS_WDOG_CONFIG, 250); /* set the timeout to be 250msec */
> ioctl (wd, RTEMS_WDOG_TRIGGER); /* trigger a watchdog reset */
> close (wd);
> rtems-users mailing list
> rtems-users at rtems.com