WatchDog Timer

[Peter D]

Good day
Please would someone be so kind as to post some sample code for using the watchdog timer on a pic 16F870.
Iv'e read through some forum articles but just cant grasp it.

Hi, its great to see you visiting our forum. Why not try Proton Compiler for FREE? Download the FREE version of Proton Compiler, Its called Amicus18 and its available from HERE Already using proton Compiler??? Get rid of these pesky messages... get LICENSED USER STATUS

[Peter D]

Best I could come up with was to enable the fuse and use Asm and EnadAsm ,

'' INTERRUPT HANDLER
GoTo Over_interrupt
Do_int:
Asm
clrwdt
EndAsm

[shantanu@india]

Simple really.....you just have to insert the clrwdt instruction in areas where your code loops for intervals which might be potentially greater than the WDT overrun time.As a principle it is not advisable to insert the clrwdt mnemonic inside a interrupt loop if the ISR is tight enough.

Example:

For check_time=1 To 500 'wait for 5 sec
Clrwdt
DelayMS 10
Next

[captainslarty]

Hi Peter
I was actually looking into this for a pal the other week, and is an area that needs much clarification in the PDS manual -
Basically, from my observations

If you set the fuse, and use the declare watchdog=on
then PDS atuomatically places clrwdt in your code for 'most' circumstances.
ie,
with watchdog on PDS places clrwdt commands in assembler in the following areas as examples - (This is not a full list as I have not checked in great detail)



On startup
On sleep
During a delayuS
during a delaymS
during hrsin
during hrsout
during ewrites
during adc ADIN routine


That is more than I expected it to do, I presumed it did the delay routines - but is doing more - very clever stuff..


It is then up to the coder to place clrwdt in code that could wait for something not covered in the above -
for example - in a while wend or repeat until or a goto loop etc where you await an event, for example awating a button press or port change -
The wdtcon register sets the timeout for the wdt -
You can of course do as you are doing.

One of the things to also consider when using wdt or bor reset etc, is testing at startup for those conditions being flagged and doing something if you need to -
ie, prior to release of code, incrementing an eeprom counter on such an occurance for testing purposes so that when you soak test the code , say overnight, and in the morning it is still running fine - you can actually check to see if such an event occurred that you may otherwise have missed.
I always leave wdt off diring development, but thats a personal choice, and to be honest rarely use it at all.
hope that helps.?

[captainslarty]

Simple really.....you just have to insert the clrwdt instruction in areas where your code loops for intervals which might be potentially greater than the WDT overrun time.As a principle it is not advisable to insert the clrwdt mnemonic inside a interrupt loop if the ISR is tight enough.

Example:

Hi Shantanu my friend, nice to hear from you
PDS will do that for you, if you set the fuse and use the declare - it auto adds the CLRWDT to the delayms for you. ! - hence no need for what you suggest.
If you look at the ASM you will see it.
Joe.

[shantanu@india]

Hi Joe,
Yes I know PDS would do it for me......only I could never get rid of the habit of doing it manually.I shall try it in my next code which I am writing right now.

[captainslarty]

Hi Joe,
Yes I know PDS would do it for me......only I could never get rid of the habit of doing it manually.I shall try it in my next code which I am writing right now.

Hi Shantanu
Yeah , it is one of those things that if you use the 'auto' setting in PDS, then you have little control over,
Manual, IF you need or want WDT is the way I would tend to go too... but then, you cannot use delayms etc unles your WDT timer is > than the delayms period otherwie you get a WDT timoute in the delay..

I actually seriously wonder about the use of WDT in general... ?
Ok, endless loops etc, or pic program crashing - then WDT occurs.. but HOW do you KNOW it happened unless you test for it on reset ?
Even then, what do you do about it?
Do you warn the user, do you warn the developer etc etc ? and if so how ?
It sort of seems like a nightmare waiting to happen that you have no real control over when it happens ... ! -

IF the wdt occurs, is it down to a Mchip defect, a PDS issue, A design issue, a programming issue etc etc.
Ok, lets say you have a hospital BP trend monitor, and the WDT occurs due to any of the above (and why else would it occur??) -
We lose our trend, the device resets etc etc..
We could store the trend in ram, or in eeprom - ram has no limit (I am not talking here about writing to flash etc) - just normal ram ...
So, on wdt reset, we lose all info... (and eeprom has a finite number of write cycles)

I fail to see a really useful app that actually needs it ? -
We have, on modern units, BOR, stack overflow etc... even these.. apart from BOR - we need to carefully consider their use. and if they apply HOW and WHAT we do.. ?
Deep Joy....

[pic-ignorant]

Hi Joe,
I always use the Watchdog timer. My products are hard wired into the mains. If somebody abuses it, and it needs a reset (which does happen) I would be called out, maybe halfway across the country to flick the trip. If you said to the client, "Just open the mains cabinet, flick the trip off then on' they would reply 'I'm not qualified to do that'
With the watchdog timer, if a problem did occur, the unit attempts to resolve the problem itself within a certain time, then the WDT will reset the whole system, recalibrate, and then carry on without user intervention.

[pic-ignorant]

Have a look at the OPTION REG in the datasheet.

Enable WDT in Fuse Config
Assign PSA to Watchdog: OPTION_REG.3 = 1
Set Prescaler to desired value (Option_reg.0,1 & 2)

Now the WDT is running, you just make sure you clear it before it rolls over


You can test it by using a simple program like this

Set WDT to rollover at approx 1Hz


LED = 0
delayms 500
LED = 1

The Led will be off for half a second, then turn on and stay on until the WDT rolls over, then start over


John

[John Drew]

As an aside, the watchdog timer can be set for very long periods in the enhanced series. I've got one running for 4 mins 16 secs in one location as I wasn't positive that I had all eventualities covered in the various software states. Just one CLRWDT in the main loop does the job with confidence. An instance where I didn't want Proton to add more.
It's a 140km drive then up a poor road to the hilltop to reset a device in an amateur radio repeater. No big deal if there is a lockup and there is a 4 minute delay on reset but a big deal to make the round trip drive of nearly 300km to throw a switch. Yes, I know 4 minutes is possibly overkill. Not exactly a mission critical application though.
John

PS I edited this post as I made an error in the length of time the WDT could be set. The enhanced series are however a big improvement over earlier WDT times and does overcome the need to have lots of CLRWDT in the code