What is watch dog skin#

Moreover because it is the responsibility of a thread to register with the watchdog, you might have some threads that do not register at all. Both tasks and interrupt handlers might be monitored in this way. Tasks with low or aperiodic behaviour might time-stamp their scheduling, the callback might then return a failure if the task has not been scheduled for some specified time period. If the counter is zero on entry, the task did not schedule since the last watchdog check. Tasks of high periodicity might simply increment a counter, which is set to zero when the callback is called. Each function can be tailored to the needs and characteristic of the task. The design of the callback functions themselves depends on the specific task and its behaviour and periodicity. In a cooperative scheduler, it should yield between call-back calls.

In a preemptive OS, the watchdog thread would be the lowest priority or idle thread. That way any thread that never returns a healthy state will stall the watchdog task until the hardware watchdog timeout occurs.

At the end of the list the hardware watchdog is kicked.

Each callback itself is called iteratively until it returns a healthy state.

When the watchdog is scheduled it may iterate the list of registered tasks.

Every thread that wishes to be checked explicitly registers its callback with the watchdog thread, which maintains a list of such callbacks.

Fun stuff, that's why I love embedded development. In many scenarios, this will not be caught, and your system will still kick the WDG, yet part of your system is crippled. The method I described above will trigger WDG reset if an ISR is hogging the CPU (good), but what about the opposite scenario - an ISR has (sadly) become accidentally and inadvertantly disabled. There is at least one other aspect to consider - outside the scope of this question - and that's dealing with interrupts.

What is watch dog skin#

There are 100 ways to skin this cat, but the basic principle of a single task that is responsible for kicking the WDG and having other tasks funnel up to the kicker task is pretty standard. Considerations of task priorities, queueing theory, etc. Reply-request - once a second (or whatever), kicker tasks tells everybody (via queues) 'time to check in' - and eventually every task runs its queue, gets the request and replies. Autonomous - for example, once a second, each task receives an event in its queue 'tell kicker task you're still alive'. This way, you don't have to worry about a task not checking in because it's blocked on a semaphore 'way down there' (if that doesn't make sense, sorry, without writing a lot more I can't explain it better).ДЄlso there is the consideration - do tasks check in 'autonomously' or do they reply/respond to a request from the kicker task. All tasks (and ISRs) communicate with each other by sending events / messages. In this case, each tasks blocks at one specific place - on a message queue. I typically design my embedded systems as event-driven systems. RTOS event flags provide a somewhat similar mechanism that is more elegant.

Some people have each task set its own dedicated bit (atomically) in a global variable the kicker task checks this group of bit flags at a specific rate, and clears/resets when everyone has checked in (along with kicking the WDG, of course.) I eschew globals like the plague and avoid this approach. Now there are of course implementation details to consider. If another task is hung, kicker task sees no check in, kicker task doesn't kick WDG, you reset If an interrupt is hung (100% CPU), the kicker task won't run, you reset One common approach is to delegate the watchdog kicking to a specific task (often either the highest-priority or the lowest priority, tradeoffs / motivations for each approach), and then have all other tasks 'check in' with this task.