This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Hardware Watchdog
- To: Gary Thomas <gthomas at redhat dot com>
- Subject: Re: [ECOS] Hardware Watchdog
- From: Christoph Csebits <christoph dot csebits at frequentis dot com>
- Date: Thu, 26 Jul 2001 18:18:16 +0200
- Cc: ecos-discuss at sources dot redhat dot com, "fche at redhat dot com" <fche at redhat dot com>,Doug Fraser <dfraser at photuris dot com>
- References: <20010726164916.A32626@frequentis.com> <XFMail.20010726094929.gthomas@redhat.com>
On Thu, Jul 26, 2001 at 09:49:29AM -0600, Gary Thomas wrote:
>
> On 26-Jul-2001 Christoph Csebits wrote:
> > Nevertheless my watchdog is not
> > software controlled. :-|
> >
>
> What happens when your watchdog fires?
the MPCs reset lines are pulled accordingly
to do an hard reset. no way to catch it. :-)
> Fixing this may be hard. Within RedBoot, there is a notion of "idle"
> routines which will be called while RedBoot waits. However, once the
> GDB stubs start running, all of that stops and everything is simply
> polled based on the serial port.
I have a running version of RedBoot, but as i told, from
time to time i am running into a loop, and the board resets.
Then i start to locate the loop and fix it.
The best solution may be a timer interrupt routine
with detaching the interrupt when starting an application.
(Someone mentioned it earlier, thanks to him
- i lost the mail and do not remember the name)
Is it the right way to do it with
cyg_drv_interrupt_create( );
cyg_drv_interrupt_attach( );
cyg_drv_interrupt_acknowledge( );
cyg_drv_interrupt_unmask( );
: