The Great Watchdog Hack

Paul Evans paule at martex.gen.oh.us
Mon Dec 9 19:30:20 UTC 2002


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>

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

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

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

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





More information about the users mailing list