Problem with WDT of 24FJ64GA306

[stoyanoff]

Greetings! I'm using MPLab v 8.93, CCS v4.134 and PIC24FJ64GA306.
Here is my program:

[Ttelmah]

You are explicitly turning the watchdog on, and disabling the ability of software to disable it. This is what WDT does as a fuse.....
You have it at such a short timeout period that the restart in the delay probably never gets reached. You have it set for 1mSec timeout, while the default routines assume a minimum of 18mSec.

WDT_SW allows the watchdog to be software enabled/disabled.

Increase the post-scaler WPOSTS8 will probably make it slow enough that the restart code in delays will work.

[stoyanoff]

Thanks! Can you tell me how to calculate the time for WDT?! Or how to set it?

[Ttelmah]

Look in the data sheet!.....

Historically 'standard' traditional watchdog's had a minimum nominal time-out of 18mSec (which actually varied down to as little as about 7mSec and up to about 28mSec, between chips, and with different temperatures), which was why the CCS code assumed this sort of time was the minimum that could ever be met.
You chip has a different (more accurate as well) watchdog, which is run from an internal RC oscillator at nominally about 32KHz. So 1/32000 * (prescaler*postscaler) gives the time-out. Postscaler is 1 to 32768. Prescaler is 32 or 128, so with postscaler set to 1, and prescaler not specified (could be 32 or 128, you'd need to check the fuses generated - different compilers give different results for the default) the time-out would be either 1mSec or 4mSec.

Best Wishes

[stoyanoff]

Thanks! If I use WDT_SW could I use WDT128 for example?! Or I`m returning to square 1?!

[Ttelmah]

WDT128, just sets the _prescaler_ to 128. WDT32 sets it to 32. Only choices for the prescaler. WPOSTn, sets the postscaler to the 'nth' entry in the table in the data sheet (total of 16 entries). You can use these with either the software controlled, or hardware 'fixed' watchdog.
You can change the postscaler, but not the prescaler in the setup_wdt instruction. This assumes the prescaler is set to 32.

So:
WDT_SW,WDT128,WPOST8

gives you a software controllable watchdog at 1/32000*(128*16) = 64mSec

setup_wdt(WDT_ON);

will enable this.

However

setup_wdt(WDT_ON | WDT_128MS);

will enable the watchdog at 512mSec (because the prescaler is set to /128)

WDT_SW,WDT32,WPOST12

gives a software controllable watchdog at 1/32000*(32*2048) = 2.048s

Look at page 335 in the data sheet for the table of division values. '12' gives 11 in this table (insane I know), which is 2048 for the divider.

Best Wishes

[ckielstra]

Just a general remark on using a watchdog.

When I started building electronics projects I tended to think that a watchdog was a great feature to make my designs more reliable. Now, with more experience, I do still think so but I've also learned that watchdogs have some huge draw backs and hardly ever use a watchdog any more.

Drawback 1 is that a watchdog makes your device more difficult to debug. While debugging the watchdog is disabled, otherwise the breakpoints won't work. You test your whole project and then in the 'release' version you discover it sometimes fails for unknown reasons. Somewhere you forgot to kick the watchdog and is triggered

Drawback 2 is that a watchdog complicates your design. You carefully have to think about where you kick the watchdog. Just kicking at many random locations in your code will prevent the watchdog from being triggered but then you miss the whole point of using the watchdog as a safeguard for critical code.

What do you want to happen at a random program hang? A watchdog will restart the processor but is that really the best solution? A random device reset is just as annoying to the user as a program hang. Most likely you would like to detect the watchdog being triggered and go to some 'safe mode' where no harm can be done. As the restart is done automatically you'll also have to add some logging mechanism so you can later review the sequence of error events.

General speaking a watchdog gives me more problems than it solves. For a simple project where a user is monitoring the process I don't mind a program hang. The user will see the device failing and under user control a save power cycle will be executed. The user can later tell me the sequence of events leading up to the error situation.

Conclusion: when lives are on stake I'd add a watchdog but most other projects it will add more trouble than it solves.