View previous topic :: View next topic |
Author |
Message |
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
Problem with WDT of 24FJ64GA306 |
Posted: Sun Dec 29, 2013 3:30 am |
|
|
Greetings! I'm using MPLab v 8.93, CCS v4.134 and PIC24FJ64GA306.
Here is my program:
Code: |
#include <24FJ64GA306.h>
#FUSES HS,WDT,WPOSTS1,PR
#use delay(clock=20M)
#use I2C(MASTER,SCL=PIN_G2,SDA=PIN_G3,FORCE_SW)
void main()
{
int d;
setup_wdt(WDT_OFF);
d=restart_cause();
delay_ms(100);
/* other code*/
}
|
Every time when the controller reaches delay_ms(100) it resets the cpu and the restart cause is 4 (RESTART_WATCHDOG). I tried to add reset_wdt to #use delay(). I added setup_wdt in the beginning of the program in attempt to stop it if it's ON on default. NO effect!
What's happening here? Where is my mistake?
Thanks! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sun Dec 29, 2013 8:31 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Mon Dec 30, 2013 3:35 am |
|
|
Thanks! Can you tell me how to calculate the time for WDT?! Or how to set it? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Mon Dec 30, 2013 3:55 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Mon Dec 30, 2013 7:16 am |
|
|
Thanks! If I use WDT_SW could I use WDT128 for example?! Or I`m returning to square 1?! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Mon Dec 30, 2013 8:01 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Dec 30, 2013 10:51 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|