The Great Watchdog Hack

[Joel Sherrill]

Paul Evans wrote:
> 
> Joel Sherrill wrote:
> <snip>
> 
> > It is OK if the memory has already been zeroed by something else.  Over
> > the years,
> > I have seen a variety of systems which did ensure that memory was zeroed
> > before
> > control was given to the application.  These tended to be systems with
> > ROM
> > monitors or boot loaders but it was common enough that we decided to let
> > the
> > BSP specify if RTEMS was clearing memory twice.
> 
> I'll try this next chance as I already zero RAM in start.S before
> copying .data from flash.
> 
> <snip>

:)  I have spotted patterns in embedded systems. :)

> > If possible just using a longer timeout for the first time would be a
> > possible
> > solution.  This would be the simplest thing.
> 
> It's already maxed out. *sigh*

OK simple solution is out. 

> >
> > There are some pretty easy places to stick the reset if not in a kind of
> > order that reflects how easy I think they would be to insert compared
> > to how effective.
> >
> >   + if clearing memory is the big culprit, have your own memory clear
> >     routine that zaps N bytes, then touches the watchdog.
> >   + touch it before calling rtems_initialize_executive
> >   + put a hook in for every init hook to touch the watchdog (pretasking,
> >     predriver, postdriver, etc.)
> >   + let every device driver init touch the watchdog
> 
> Aside from being ugly doesn't putting a strobe infront of
> each *_Initialize function inside rtems_initialize_executive_early()
> provide pretty good coverage? I could add the init hooks and driver
> strobe just in case.

It will work.  I was just trying to keep you from modifying executive
source if possible.  If you have to hack on the source, try before 
the init of each API.  

You might also be able to get away with a custom version of 
libbsp/shared/bootcard.c in your own BSP.  That also avoids
the executive modifications.

> I liked Chris John's idea of using a timer interrupt but it's not
> clear to me if it's possible to use it early enough in the boot
> process to make a difference.
> 
> I'm hoping eliminating the workspace clear fixes it. If not, I'll need
> metrics, time to get out the logic analyzer..

It would be nice to hear what your final solution turns out to be.

> > I suspect that the big time culprit is either zapping memory or
> > dead time during device init.  So figure out how much those are
> > and work it out.
> 
> I was already strobing the watchdog during the delays I have
> in device driver inits, but I'll look again at this.
> 
> >
> >
> > >--
> > >  Chris Johns, cjohns at cybertec.com.au
> >
> >
> 
>         -Paul

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985