WDT

[ertansuluagac]

Hello
Friends WDT exactly how it works. And does it make sense to use WDT in every program we do? What should I watch out for WDT?
_________________
Es

[temtronic]

Basically, the WDT, if enabled, is an internal peripheral that will restart the PIC. providing the PIC is working fine, the WDT will never trigger a restart. It runs from it's own RC clock oscillator and you program in a 'delay time'. If the PIC fails, then AFTER that delay time, a restart to the PIC is executed.
WDT design and optionshave improved over the 2+ decades, so you'll have to read the WDT section of the datasheet for your PIC.
Normally you do NOT enable the WDT until the program is complete, ready for the client, THEN you have to decide upon a timeout value. Say it take 1.2 seconds for main() to execute a complete loop....To be 'safe', call that 2 seconds, so set the WDT for 3 seconds. Be sure to read the WDT oscillator spec !In the early days it could be +-50% of the rated time, so a 2 second WDT could trigger anywher from 1-3 seconds and be within 'spec'. Newer PICs have better, tigher specs BUT you need to read.....
I never enable WDT while 'on the bench', ONLY when the PIC goe out the door...
Computing the WDT delay value can be tricky....
You need to add it to USE RS232(..options..)

I'm sure others will respond and add comments

[Ttelmah]

The other key thing is that if you enable the watchdog and 'scatter; restart
wdt calls through your code, this actually does pretty much no good. The
key thing in watchdog code design is that you have a restart_wdt, that
is 'trapped' with tests, so that a program walking through memory
can't get to it, and it'll only execute if things are genuinely working 'right'.
Then the watchdog will trigger if the code gets hung or things go wrong.
If you declare your main variables without them being initialised, you
can have your main code test 'restart_cause', and only if this is not a
watchdog reset, initialise the variables, so the code can reboot and
carry on quite quickly, with the RAM values unchanged.

The watchdog here is actually a separate section to the CPU itself. It runs off
it's own RC oscillator, and will run even if the processor gets stuck'. You
will find a lot of references to 'external watchdogs' being superior to built
in ones, but the PIC one is very close to an external design.

Have to disagree with Jay on enabling the restart_wdt in #use RS232 or
#use delay. These really should not be setup to resetting the watchdog.
Doing so, throws away a lot of the watchdog's capabilities. The restart
really must be done by you and testing that the code is working as it
should if it is really going to work.

Look at the section entitled 'Fault detection' here:

[url]<https://www.researchgate.net/publication/295010877_Architecture_and_Operation_of_a_Watchdog_Timer>[/url]

[ertansuluagac]

I want to test and see it with 3.3V Ethernet Control kit. Do you have this test code?

[temtronic]

I was under the impression, though I haven't checked the'code', that adding WDT to USE RS232(), would trigger the WDT in the event the UART got 'hung up' looking for data or sending data or say having 'handshaking' enabled but not working.

hmm, just read this...

Will cause GETC() to clear the WDT as it waits for a character.

oopsy... That would ALLOW the PIC to stay there,looking for data...forever ?

so that means it'd never get out of the loop. Not the way I was thinking it'd work....

I'm a bit distracted as a fox dang near bit my toes off few minutes ago..