Watchdog device driver

Thu May 22 18:02:35 UTC 2008

Neil Mayes wrote:
> Blimey things move quickly!!
>   

:-D You guys made made a good suggestion with follow ups
and I thought I would kick start the development. You guys
are now free to get to a full API with shell driver framework
and documentation without too much headache over the
basic infrastructure.
>> 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
>
>   


-- 
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