[En-Nut-Discussion] Watchdog Debugging

[Timothy M. De Baillie]

Nathan Moore wrote:
> On Wed, Sep 24, 2008 at 12:15 PM, Bernard Fouché <bernard.fouche at kuantic.com
>   
>> wrote:
>>     
>
>   
>> Timothy M. De Baillie wrote:
>>     
>>> Any thoughts or improvements out there in the ether?
>>>
>>>       
>> What about:
>>
>> - with a configuration option, remove usage of the hardware watchdog and
>> provide a software one, based on a available timer/counter. When the
>> counter reaches its max value, an interrupt is fired. One must choose a
>> max value that makes the timer/counter with a timing equals to the real
>> watchdog (or the closest possible).
>>
>> - the function to reset the hardware watchdog then just reset the
>> timer/counter.
>>
>> - the interrupt fired when the counter reaches its max value can write
>> information to EEPROMs, banked RAM, on the serial port, etc.
>>
>>     
>
> Just keep in mind that if a hang-up happens within an ISR or critical
> section
> this method won't catch it.
>
> NutEnterCritical();
> for(i = 0; (i = 4); i++) {
>    f(i);
> }
> NutExitCritical();
>
> Nathan
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>   
Sure it will.

void MyInterrupt(void * arg){

    //save the interrupt threads information
    unsigned int thread_information = _my_memory_location;  

    //set the memory location to the interrupts flag
    _my_memory_location = MY_INTERRUPT_FLAG;

    for(;;); //causes lockup

    //under normal circumstances, you would then set the interrupted 
thread back again before returning from the interrupt
    _my_memory_location = thread_information;

}

Now I know that's not 100% reliable, but should get the job done.

Criticals don't change threads (or shouldn't) so you don't have to do 
anything special.

Tim