Re: Watchdog timers & Cooperative OS'es

I am working with a cooperative threaded OS. I need to implement a reliable

> watchdog timer.

That can be quite hard.

In the end, it all depends on what _exactly_ you want the dog to watch out for: complete breakdown of multi-tasking (i.e. one task hangs in a loop and no others get any CPU time) only, or partial breakdown too, as in: task-switching is still being done, but at least one task is getting executed too infrequently to get its work done.

It also depends rather strongly on the exact type of scheduling algorithm you're using, esp. on whether the scheduler tries to guarantee a maximum interval between invocations of a given thread, at a given priority.

And it depends on what your watchdog time-out handler will *do*, once it's triggered.

I was thinking of kicking it in the idle thread (e.g. the lowest priority in > the system), but then I thought, that makes it difficult to use, perhaps > running it in a high priority thread on a timer makes sense.

Putting it in the idle thread is not reliable at all --- it won't be updated at all if the other threads are so busy that the idle thread hardly ever gets executed at all. So the WD might well misfire in the exact situation where it hurts most.

Putting it in the highest-priority thread will only detect complete break-down of task-switching. It won't notice if some of the medium-priority tasks are overloaded, but the top-priority one still gets executed.

You may have to put the WD update into *every* thread instead. Or, since you appear to be writing your own scheduler, right into the scheduler itself. E.g. at each task switch for a task that has to finish its next invocation before some known time interval, it should update the watchdog to fire at that time if it's currently set to fire later.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker
Loading thread data ...

Ralph,

Here is an article from embedded.com:

formatting link

near the end of the article it talks about the high priority vs. low priority watchdog timer threads.

Are you planning on haveing each thread report on its health? If not you could get in a condition where the lower priority threads are starving but the watchdog at the high priority is still kicking the watchdog.

David

Reply to
David

I've seen the high priority vs. low priority choice develop into a holy war. The high-priority option will cause the WDT to trigger reset when the system goes to pot, or the scheduler stops working properly. But it won't detect an instance where one of the threads locks up. The low priority option will trigger the reset in the same instances as the high priority type will, as well as when a thread above idle blocks processing on lower priority threads.

Both options are appealing, but often a combination of the two is the best. Set up a flag that the idle thread can use to indicate that it has executed. Have the high priority thread check for this flag and reset it. If the flag hasn't been set, the thread can access state information so you can determine why the idle thread didn't execute. Then, depending on your desired system behavior, you can toggle the watchdog or not.

This idea can be extended so that each of the threads has a bit that must be set so the watchdog thread can verify that they've executed. By using both a low and high priority thread for WDT handling, you gain a lot of flexibility in the way error situations are handled.

Reply to
Dingo

reliable

priority in

task

war.

system

will

threads.

best.

executed.

Thanks Dingo,

This is a very good idea, I can have my idle thread set a global to some count, and the high priority watchdog thread count that down, if it ever reaches 0 then it stops kicking the watch dog.

Seems that this really is the best of both worlds. Easy for tasks to use.

I am also going to check for free ram in the watchdog, the system runs with a nice buffer of free ram, if it drops too low it can reset (which it should never do), meaning all my tasks don't need to bother checking for low ram situations that shouldn't happen anyway.

Ralph

Reply to
Ralph Mason

Thanks for the link, a good read.

Ralph

Reply to
Ralph Mason

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.