Watchdog device driver

[Neil Mayes]

Blimey things move quickly!!
> 
> Message: 6
> Date: Thu, 22 May 2008 09:41:07 -0500
> From: Joel Sherrill <joel.sherrill at OARcorp.com>
> Subject: Re: Watchdog device driver
> To: Chris Johns <chrisj at rtems.org>
> Cc: "rtems-users at rtems.com" <rtems-users at rtems.com>
> Message-ID: <48358603.5090507 at oarcorp.com>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
> Chris Johns wrote:
> > Andrei Chichak wrote:
> >   
> >> At 05:12 PM 5/21/2008, you wrote:
> >>     
> >>> 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);
> >>>
> >>> Regards
> >>>       
> >> I like the interface, in all of the systems that I have 
> written there
> >> was a two phase strobbing, I suspect that would be the 
> RESET and TRIGGER, yes?
> >>
> >>     
> >
> > The trigger would allow you the ability to reset a board by 
> asking the driver
> > to trigger the watchdog. This maybe done by lowering the 
> time out to very
> > short value or it could be disabling interrupts and looping.
> >
> > I think a single call to RESET or SERVICE the watchdog is 
> all that is needed.
> > You also need enable and disable. If a watchdog cannot be 
> disabled the driver
> > should return an error code.
> >
> >   
> One issue is the default state.  Many watchdog's need to start
> disabled and be enabled once the application is initialized.  I
> have seen multiple cases where the BSP + application initialization
> was longer than the reset period.

Indeed, the BSP as default should disable the WD, well this is what I
have done. I have introduced a WDdevice driver and if the application
configuration wants it via confdefs
(CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER) the driver is added to the
dd table. During startup all devices within the table are initialized
and at this point I enable the WD to the max timeout.

> >> Where in the BSP would this sort of stuff go? (Being a moderate
> >> newbie I have to ask. I didn't know there was support for SPI, I'll
> >> have to look that up)
> >>     
> >
> > We need to create a header file that would live in the 
> cpukit and be installed
> > when RTEMS is build and installed. This would provide the 
> API which is the
> > RTEMS_WDOG_RESET declarations. Maybe these could go in an 
> existing header. I
> > will let Joel decide this.
> >
> >   
> This is the right approach. 
> 
> > In the BSP the driver can go where it suits the BSP. You 
> have to register the
> > driver and this could be via confdefs.h (Joel?) or by a 
> call in the BSP. If
> > the BSP does not provide a watchdog driver the open fails 
> because no device
> > node exists.
> >
> >   
> 
> I have committed a baseline watchdogdrv.h in
> cpukit/libcsupport/include/rtems along with changes
> to confdefs.h  Doesn't define the ioctl's -- just
> enough to be able to configure the driver.
> 
> There should be a driver template similar to the Clock
> Driver template which does a lot of the boiler plate
> for you.  The BSP should not have to do not anything
> but define a few macros to support initialization, etc.
> I didn't add one of these.
> 
> There should also be a chapter in the BSP and Device
> Driver Guide about the interface once it is settled.

I have essentially copied the clock driver, so the shell calls the BSP
specifics.

I would like to see a little more for the watchdog functionality. When
it expires (for ERC32) I have installed a RAW ISR handler which enables
me access to PC and nPC (I know this does not always tell you the
culprit) but what I would like to see is an interface to the supercore
to get the RTEMS status of all tasks and saved contexts, PC, SP & any
other info. The watchdog handler can decide what it wants to do with
this crash info, ie write to NVRAM, output UART etc. At the moment I
drive the UART directly since I have traps and ints disabled during
this.

I have also added the WD prodding to a BSP installed IDLE task, if the
device is installed it prods the watchdog.

> > Regards
> > Chris
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >   
> 
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
> 
> End of rtems-users Digest, Vol 20, Issue 39
> *******************************************
> 
> 
Regards,
Neil