This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Hardware Watchdog
- To: Doug Fraser <dfraser at photuris dot com>
- Subject: RE: [ECOS] Hardware Watchdog
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Thu, 26 Jul 2001 11:11:57 -0600 (MDT)
- Cc: ecos-discuss at sources dot redhat dot com, fche at redhat dot com,Christoph Csebits <christoph dot csebits at frequentis dot com>
- Organization: Red Hat, Inc.
On 26-Jul-2001 Doug Fraser wrote:
> Interrupts may not be enabled in redboot, but
> does that stop him from installing his own
> tick handler and servicing the watchdog from there?
> The maximum time on the 860 watchdog is around
> three seconds with a 50Mhz CPU clock.
> As Christoph mentioned, the watchdog activates
> a hard reset cycle, and there is nothing you can
> do to catch it. The other problem is that if you
> disable the watchdog, you cannot reenable it
> without performing a hard reset.
>
So the idea is that you need some piece of code telling
the watchdog "I'm alive", correct? Surely this can be
done without all of the baggage of handling interrupts.
> As well as servicing it with a tick interrupt
> during redboot, you could also disable it if
> the redboot polling mechanism detects a GDB
> connect. You probably want the watchdog off
> during debugging anyway, so that would allow the
> target to boot with a watchdog in a normal run
> state, yet reduce the complexity of having to
> service it during a debug session.
>
I don't see how you can handle interrupts without enabling then.
Once they are enabled, then other interrupt conditions might need
to be serviced, etc.
I think it much better/wiser to figure out where it might be "looping"
and put in stuff to tickle the watchdog appropriately.