an embedded system's hardware watchdog restarts the system because one
of the software processes (threads,
tasks) has been live locked and spins around
concentrating on itself in a malignant and introvert manner.
It does not even "kick" the watchdog on its way through the infinite
loop of instructions.
By the way, I don't understand the rationale for the term "kicking the dog" to reset its downgoing counter, so that it's again long before it would reach zero. Should we anthropomorphise, then "feeding the dog" should serve better. In particular, for such a nice dog as is used in the figure, namely the Windows operating system's "search dog".
Here, the problem was process P0. It was burning EEPROM,
one "sector" at a time, and then descheduled
itself with no timeout by returning back to the non-preemptive run-time
See "From message queue to ready queue" about RQue and the synchronous channel communication layer
synchronous channel software layer does a
Our solution was to insert a short (1 ms) delay in P0,
thus making RQue empty provided the system had nothing else to do. We
could have "yielded" instead, so that
The solution involved no tuning with priority (we have
no such, neither on processes nor messages). No tuning with extra
P0 continued burning EEPROM like this way several times, without any problems. Not until we happened to hit the controlling "burn" command to start it again at a time when the processor had little else to do.
The watchdog is kicked every time the main loop "
Other publications at http://www.teigfam.net/oyvind/pub/pub.html