[En-Nut-Discussion] Debugging Watchdogs via OS Thread Switching

[Timothy M. De Baillie]

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 
multi-threaded system.
Therefore, it would be "nice" if the OS saved the state of the last 
context switch.

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

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,

Tim