[En-Nut-Discussion] Debugging Watchdogs via OS Thread Switching
Timothy M. De Baillie
debaillie at ciholas.com
Mon Aug 24 21:19:08 CEST 2009
I was thinking today about adding some debug code to the function
NutThreadSwitch in context_icc.c. Let me explain my thinking here.
I have a watchdog timer set for some time (say 5 seconds).
My watchdog is kept at bay by a high priority (low in number) thread
that sleeps for at least 1 second at a time (via a NutSleep(1000)).
(this is the highest priority thread in the software)
I need to debug which thread is causing a watchdog in a very complex
Therefore, it would be "nice" if the OS saved the state of the last
Looking through the OS code, all of the "yielding" functions ultimately
call NutThreadResume, which then calls NutThreadSwitch. From my
understanding of the code (by inspection), I could save the thread I am
going to switch to, the total amount of RAM free, and the watchdog timer
information in a protected piece of RAM for later inspection from the
So my implementation would include modifying the OS Ram size to give me
some bytes of RAM to play with above the Heap. Every NutThreadSwitch
would save the information I listed above. Additionally I was wondering
if there was an easy way to get the specific line of code (code space
address) of the return path of the yield in both the "last thread" and
"next thread". This would help narrow down the problem to where in a
thread the problem might occur. On a watchdog, the first thing my
software would do, would be to read the contents of the RAM above the
Heap and report it.
I understand that these extra calls will slow down the context switch,
and therefore I would only add it in with a DEBUG compiler definition.
Does anyone have any thoughts or suggestions on the implementation of this?
Thanks in advance,
More information about the En-Nut-Discussion