Correct ways for implementing standard inbuilt watch dog timers

I'm bit new with using applications that use watch dog timers and i'm up to use one for the first time. I'm using pic18f26j50 and it got an internal watch dog timer which got a limit from 2ms and can be expanded up to 2 minutes.

I understand the whole purpose of using internal watch dog timers is to prevent any accidental code lock.So i would like to know what are the ways in which the watch dog timer can be tested and proved that it could be fail safe to kick it properly with out any error.

I trust input from you will help me to write test routines so that i could understand the features of it and also i would like to be informed about any possible pitfalls if any.

And i trust watch dog is usually cleared inside the main and another question that suppose i have is if i have certain modules A,B,C..N that gets called in main. What are the requirements for a designer such that watch dog timer implemented meets the standard and what are the things which the developer must look in to properly in such a case.

-

A book could probably be written on this- I'll try to cover the high points.

The WDT is a tool that can be used to help satisfy some system-level requirements, and those requirements are the primary motivation. They could be safety-related or arise from a desire to reduce some annoyance to the user. There are other tools such as clock monitors, external WDTs, redundancy, interrupts on access to improper memory locations, interlocks of various kinds, etc.

A WDT will not prevent anything- it can be used to help recover from a system upset. When a WDT timeout is triggered, you know something really bad has happened, but you don't know exactly what, so you must begin some kind of recovery operation. The processor could have gone off and done all sorts of things- corrupted memory (RAM or EEPROM), re-written SFRs to improper values, set outputs to undesirable states etc. The first thing you need to do is to put the system in a 'safe' state if that is a concern, and if it is possible. For example, a 10kW heater should be switched 'off' in most cases (there are cases where 'on' is better). Some things (consider a drone autopilot) may not have a safe passive state, and you may have to resume operation and attempt to recover.

Before resetting the WDT (as you say, it should happen in the main routine) you should check as many things as possible, not just that you got to the reset routine. You may wish to confirm that known values such as SFRs have not changed (or re-write them if that does not disturb things). It's a bad idea to depend on power-on default values. It's possible to set flags that indicate error-free completion of important operations- you can make the flags persistent (flag an error and never reset it) then if your WDT reset routine finds that the flag has been set it has the option of performing a complete recovery. It's good practice to have the WDT reset fenced in by jumps so that you can't run into it by accident (say by executing NOPs in unused memory). Some WDT implementations have a window function that requires a minimum time between resets as well as a maximum, which prevents some unanticipated routine from resetting it accidentally.

As far as the WDT time-out- you want to make it short enough that nothing bad can happen, or the WDT will not be that useful. In the case of a thermal system, a couple seconds might be no problem. In the case of motion control system, milliseconds might be better. Too frequent and you may have problems resetting it frequently enough.

It's better to have a WDT that cannot be disabled from firmware and cannot be set to a too-long timeout (which is almost the same as it being disabled). Usually well-designed processors have some protection against an errant processor doing that sort of thing.

In the case where you have to reset it very frequently, but you have a very slow control loop executing, you can use a flag or a timer to indicate a problem in the slow routine and reset the WDT if it times out. That, essentially, adds a software WDT to the slow routine. An example of that might be a motion system that does a self-tuning algorithm in the background. You need a very fast WDT to prevent the system from making undesirable movements, but the self-tuning takes longer.

-
Thank you for your inputs :). –  Rookie91 Jul 20 '14 at 13:25
is there any fault with using inbuilt WDT's?.Or you should be correct and careful in implementing the peripheral well i trust. –  Rookie91 Jul 20 '14 at 14:08
Even if properly implemented, the on-chip type can only do so much. If there is a hardware fault in the chip or the connections they can't help. Are they tested? If the WDT clock (independent clock) fails, how do you know? I've had to use external WDT in safety-critical systems (of course the internal one can be used at the same time). –  Spehro Pefhany Jul 20 '14 at 14:49

Yes, you are correct that a watch dog timer (WDT) is used to catch any code that would accidentally cause the microcontroller to lock up due to an infinite loop.

Typically, main routines in embedded code are structured something like this:

void main ()
{
initialization();

while (1)
{
routine_a();

routine_b();

// etc.

CLear_WDT();
}

// never get to here
}


Clearly, you need to have a call to clear the WDT at the end of this loop (which I am calling Clear_WDT), as shown. But often, you will need to include additional calls to this function in the lower_level routines, if they have some code that can take a particularly long time to execute (long enough to trip your WDT anyway).

Sometimes you may need to put a call to clear the WDT inside a while loop; for example here is a loop which is waiting up to 20 seconds for an answer from a far-end device:

i = 0;
while (i < 20)
{
{
break;
}
delay_ms(1000);

Clear_WDT();

i++;
}


Here you have to guarantee by inspection that the loop will exit when the timeout exceeds 20 seconds (20 times through the loop). If the call to i++ is missing, you will never exit the loop, but you won't trip the WDT either. Note that watch dog timeouts will still occur properly in any calls to lower level functions (like answer()); it is only the high-level loop containing the Clear_WDT call that is of concern.

In general, don't put calls to Clear_WDT inside any interrupt routines, especially timer interrupts as that would defeat the purpose.

Testing a WDT is quite simple; just create an infinite loop that does not contain a call to Clear_WDT:

while (1)
{
}


and stick that anywhere in your program (in a place that will get executed of course). When it gets to that loop, and never continues it will kick off your WDT.

The timeout value for a WDT needs to be long enough so that you don't have to sprinkle calls to Clear_WDT all over your code to avoid the WDT from being tripped, and short enough to be useful (a two minute WDT is not much different that just letting the system lock up). I have often used a value between 2 and 8 seconds.

-
thank you very much :) –  Rookie91 Jul 20 '14 at 13:26
So do the watch dog timer should be tested from the beginning of testing and time for each module should be documented in a f/w document right.:) That was helpful –  Rookie91 Jul 20 '14 at 13:28
Yes, I recommend that you should put in a temporary infinite while loop near the beginning of your main code (after the WDT initialization of course) and verify the WDT timer setting is correct (if the WDT is set for a few seconds this will be easy to do). Then go through each of your routines, and if they take more than a few hundred milliseconds, make note of that and see if you need to add additional Clear_WDT call(s). –  tcrosley Jul 20 '14 at 16:08