Searching \ for 'Setting the WDT' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=setting+wdt
Search entire site for: 'Setting the WDT'.

Truncated match.
PICList Thread
'Setting the WDT'
1998\12\22@021751 by Kat Lee

picon face
Hello everybody,

I have a question on WDTs. I keep getting people telling me to enable
the WDT in almost every program but there's never any instruction on how
to implement this.

Can anybody out there explain how? Manually, through hardware or
software?

Thanks in advance.
Katherine

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

1998\12\22@024326 by Tjaart van der Walt

flavicon
face
Kat Lee wrote:
>
> Hello everybody,
>
> I have a question on WDTs. I keep getting people telling me to enable
> the WDT in almost every program but there's never any instruction on how
> to implement this.
>
> Can anybody out there explain how? Manually, through hardware or
> software?

You have to do three things to get it to work :
1) Enable the watchdog option in the fuse settings (when programming)
2) Select the prescale value you want to use. The WDT and TMR0
  both use (mutually exclusive) the prescaler, so you have to
  decide which of the two will use the prescaler, and what the
  value of the prescaling must be.
3) 'Tag' the watchdog in your code.

Comments on above points :
1) You can set the fuse setting in your program with a compiler
  directive if you want to, or you can set it when you program
  the PIC.
2) To start with, use the maximum prescale value with the
  watchdog. You can make it shorter *after* you are certain
  that your program works perfectly. Watchdog resets makes
  debugging a pain in the ass.
3) a) Never (ever) tag the watchdog in more than one place
     in your program. If you do, you might as well leave it.
  b) Having said that, place the tag in a section where the
     code has to pass, but can only pass if it is OK.
  c) If you have several section of critical code, and a
     mission-critical application, you can use 'software'
     watchdogs to keep things ultra stable.

Software watchdogs :
1) You need a interrupt-based timer running in the background.
  In the interrupt code for the timer, you increment a counter
  for each of the critical procedures. Lets call them
  ProcedureCount1 - ProcedureCount5. Clear a counter that
  will be used to check if the timer interrupt is running
  ok. Let's call it ISRVisitCount.
2) In the main routine, you have a section that increments
  ISRVisitCount, and will ONLY reset the watchdog if :
       1) ProcedureCount1 - ProcedureCount5 < 100 (say)
       2) ISRVisitCount < 100 (say)

In a variant of this, you can check each of the other
counters from each of the procedures.

This is obviously a 'safety tax' on the ROM and RAM, but if
you are running mission-critical code, this is the only way
you can be sure that *all* the sections of the code are
running ok.

I have probably confused you more now, right?

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spam_OUTtjaartTakeThisOuTspamwasp.co.za  / \ AGAINST HTML MAIL

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....tjaartKILLspamspam@spam@sms.wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\12\22@100121 by lilel

flavicon
face
After thoroughl;y answering Kat's basic question on watchdogs, Tjaart
wrote:

> 3) a) Never (ever) tag the watchdog in more than one place
>       in your program. If you do, you might as well leave it.

I often use the CLRWDT instruction at the beginning of the main loop.
Are you implying that might not be the best place?

I often am forced to use CLRWDT in the middle of long timing loops as
well.  Many of my programs just "sit around" for seconds or minutes
at a time running a timing loop.  Your statement indicates this might
be a bad idea.  Can you elaborate?
-- Lawrence Lile

"Nyquist was an optimist."

=> Median Filter Source Code
=> AutoCad blocks for electrical drafting

at:  http://home1.gte.net/llile/index.htm

1998\12\22@114555 by Michael J. Ghormley

flavicon
face
Lawrence Lile wrote:

> I often use the CLRWDT instruction at the beginning of the main loop.

I seem to remember a thread a while back about the effects of CLRWDT.
Didn't it clear the prescaler along with the counter?  Perhaps you WDT
guru's could enlighten Kat (and me!) about that aspect.

I went back and re-read the data sheet and that is what it seems to be
saying, although my (un)common sense says that it could not be.

I await the collective wisdom of the group...

Michael

*************************************************************************
When the way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good.  --  Lao Tzu
*************************************************************************

1998\12\22@160532 by Dwayne Reid

flavicon
face
>I seem to remember a thread a while back about the effects of CLRWDT.
>Didn't it clear the prescaler along with the counter?  Perhaps you WDT
>guru's could enlighten Kat (and me!) about that aspect.

Only if the prescaler is assigned to the watchdog.

dwayne


Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

1998\12\22@180126 by Mark Willis

flavicon
face
Lawrence Lile wrote:
{Quote hidden}

 My suggestion:  Something more like a state machine, so you return to
the main loop regularly, only to jump back in to that timesliced
routine, & resume waiting.  This way the WatchDog will get fed his
Meaty-Bone & remain happy & not remind you that you forgot to feed him a
treat.

 (I don't kick dogs, folks, not even as a joke, with a 90# Service Dog
in the house that's not considered nice!  But feeding a dog treats will
make them remind you to do it again later;  I need to set Zeuss' timing
options to longer than 15 seconds, I think <G>)  Nothing quite like
having a dog hit me in the face with the food dish at 3 AM if he didn't
get fed <G>

 If your program gets hung in that timing loop for some reason, say a
cosmic ray hits the counter & changes it's value - it'll quit running
anything else, or run the timing loop for too long - which is BAD, on
avionics windshear warning systems, for example, where 400 lives can
rely on proper hardware function - and you don't want that.  Just
annoying on a PIC fortunately, usually <G>  The FAA won't certify those,
though, if you don't do it just right (And rightfully so!)

 So that sort of system has a main loop which calls several state
machines in turn, which run the small pieces of code to do everything
else (usually including a fairly nice hardware re-test while running),
periodically, in basically isochronous form (You don't care if the
routines take too *little* time, you make up for it in the main loop by
waiting for a hardware timing clock if needed, (Say, wait for the 10 mS
rising edge that synchronizes the two computers working together to do
all this,) treat the watchdog, and go again.

 You could have state machine # 3 wait for 15 of 16 cases, and launch a
little piece of code the 16th time (Though it could just return &
continue if you sync up with an external clock like this, sometimes it's
better to wait internal to the routine - so you are certain you have no
other routines going over their alloted time!)

 Mark, .....mwillisKILLspamspam.....nwlink.com

1998\12\22@192005 by Dwayne Reid

flavicon
face
A couple of people have written:

>After thoroughly answering Kat's basic question on watchdogs, Tjaart
>wrote:
>
>> 3) a) Never (ever) tag the watchdog in more than one place
>>       in your program. If you do, you might as well leave it.
>
>I often use the CLRWDT instruction at the beginning of the main loop.
> Are you implying that might not be the best place?
>
>I often am forced to use CLRWDT in the middle of long timing loops as
>well.  Many of my programs just "sit around" for seconds or minutes
>at a time running a timing loop.  Your statement indicates this might
>be a bad idea.


This is how ** I ** do it.  Note: it works for me but my reasoning may be
full of holes and I might be going about it all wrong also.

Most of my projects make use of a background routine that is called
repeatedly by main line code as well as any long subroutines.  This
background task maintains my real time clocks, reads and writes eeprom,
handles the SPI ports, serial comms, reads and stores a/d results, reads and
debounces external switches, etc.  The watchdog is cleared as part of this
background task.

There is a bit of error checking before the clrwdt instruction is issued.
In one version, the background waits for TMR0 to wrap - if it doesn't wrap,
the watchdog times out.  TMR0 is set at 1.024 mSec and is the basis of the
real time clocks and the SPI data rate to off-board shift registers.  The
foreground task and any subroutines requiring long delays call the
background task whenever they need to waste any time.

If the PC gets corrupted or the thing goes off into lala land somewhere, the
background does not get called, the watchdog times out, the pic resets.

This works for code that is primarily time based (ie slow tasks).

The nice thing about this is that most i/o is handled by the background
task, which is code that has been thoroughly debugged over several years.
Seems to work . . .

dwayne


Dwayne Reid   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

1998\12\22@211605 by Michael J. Ghormley

flavicon
face
Dwayne Reid wrote:

> >I seem to remember a thread a while back about the effects of CLRWDT.
> >Didn't it clear the prescaler along with the counter?  Perhaps you WDT
> >guru's could enlighten Kat (and me!) about that aspect.
>
> Only if the prescaler is assigned to the watchdog.

So, if I understand this correctly, I would write:

       ; load W first so that prescaler takes effect ASAP
       MOVLW           0x005           ; the value for a 1:32 prescaler for the
WDT
       CLRWDT                          ; resets the WDT and clears the prescale
r
       IORW            OPTION,F        ; reset the prescaler bits to 1:32


Michael

*************************************************************************
When the way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good.  --  Lao Tzu
*************************************************************************

1998\12\23@001711 by Tjaart van der Walt

flavicon
face
Lawrence Lile wrote:
>
> After thoroughl;y answering Kat's basic question on watchdogs, Tjaart
> wrote:
>
> > 3) a) Never (ever) tag the watchdog in more than one place
> >       in your program. If you do, you might as well leave it.
>
> I often use the CLRWDT instruction at the beginning of the main loop.
>  Are you implying that might not be the best place?
>
> I often am forced to use CLRWDT in the middle of long timing loops as
> well.  Many of my programs just "sit around" for seconds or minutes
> at a time running a timing loop.  Your statement indicates this might
> be a bad idea.  Can you elaborate?

It is definitely a bad idea. Say your reload value for
the 'golden brown' setting on a toaster got corrupted.
It could stay in the loop until the guy's house is also
turning golden brown ;) Long loops are dangerous, as a
small difference in a reload value could make a biiiig
difference in the timing.

See my other post on how to avoid this.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
tjaartspamspam_OUTwasp.co.za  / \ AGAINST HTML MAIL

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS @spam@tjaartKILLspamspamsms.wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\12\28@090943 by paulb

flavicon
face
Michael J. Ghormley wrote:

> So, if I understand this correctly, I would write:
>
> ; load W first so that prescaler takes effect ASAP
>   MOVLW   0x005           ; the value for a 1:32 prescaler for the WDT
>   CLRWDT                  ; resets the WDT and clears the prescaler
>   IORW    OPTION,F        ; reset the prescaler bits to 1:32

 I'm not sure what you are considering here.  If you are going to
fiddle with the WDT, you do a CLRWDT before you fiddle with it, to make
sure it wasn't about to time out.  It's already a counter, so you have
many instruction times, even at 32kHz clock, to perform the "fiddle".

 It does make sense however, to clear it again just afterward,
especially if you have just switched the prescaler over from the counter
to the watchdog, as it may be just about to overflow.
--
 Cheers,
       Paul B.

1998\12\28@121827 by John Payson

flavicon
face
|> I often am forced to use CLRWDT in the middle of long timing loops as
|> well.  Many of my programs just "sit around" for seconds or minutes
|> at a time running a timing loop.  Your statement indicates this might
|> be a bad idea.  Can you elaborate?

|It is definitely a bad idea. Say your reload value for
|the 'golden brown' setting on a toaster got corrupted.
|It could stay in the loop until the guy's house is also
|turning golden brown ;) Long loops are dangerous, as a
|small difference in a reload value could make a biiiig
|difference in the timing.

True, you need to be careful with timing loops, and any spots
in your program that clear the watchdog should return to the
main loop via goto or sequential execution, rather than via retlw/return.  But a
properly-designed timing loop should, even
if there's a glitch within it, should only run for a reasonable
and finite time.

For example, to cause a ~1 second delay on a 4MHz PIC, a loop like

Delay:
               clrf    T1
               movlw   244
               movwf   T2
DLoop:
               clrwdt
               nop
               nop
               ... ; Total of 11 NOP's
               nop
               decfsz T1
                goto DLoop
               decfsz T2
                goto   DLoop
               ; Program execution continues here

can run for at most just over a second following any glitch that
does not knock the program counter out of the loop nor "permanent-
ly" affect the PIC's instruction decode/execution logic.  If it
were desired to only have the loop run about 30,000 times adding a
"bcf T2,7" would ensure that it could run at most 32,768 times after
a glitch.

Note that placing a "clrwdt" in a main polling routine that's called
from the main loop and other delay points is a common technique, but
is not terribly safe since it provides no assurance that any properly
executing code is calling the polling routine (that routine might
otherwise be the only thing that's actually working).  Placing the
"clrwdt" instruction before the calls to the polling routine would
be somewhat better, since it would then be known not only that the
polling routine was being executed, but that it was being called
from real code.

1998\12\28@122432 by Michael J. Ghormley

flavicon
face
Paul B. Webster VK2BZC wrote:

> >   MOVLW   0x005           ; the value for a 1:32 prescaler for the WDT
> >   CLRWDT                  ; resets the WDT and clears the prescaler
> >   IORW    OPTION,F        ; reset the prescaler bits to 1:32
>   I'm not sure what you are considering here.  If you are going to
> fiddle with the WDT, you do a CLRWDT before you fiddle with it, to make
> sure it wasn't about to time out.  It's already a counter, so you have
> many instruction times, even at 32kHz clock, to perform the "fiddle".

My understanding is that performing the CLRWDT is going to clear the
prescaler value (if it is assigned to the WDT) back to 1:1.  Thus, I will
need to reset the prescaler value (in this case 1:32) in the OPTION register.

You are right that one WDT tick is going to be 18mS or so, but this just
looks like a good practice.  If it doesn't help, at least it doesn't hurt.
Or is there something wrong in doing it this way?

>   It does make sense however, to clear it again just afterward,
> especially if you have just switched the prescaler over from the counter
> to the watchdog, as it may be just about to overflow.

In the case of dynamically switching the prescaler you would also need to
deal with the fact that the value in the option register represents a
different ratio for Timer0 and the WDT, yes?

Michael

*************************************************************************
When the way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good.  --  Lao Tzu
*************************************************************************

1998\12\28@164214 by paulb

flavicon
face
Michael J. Ghormley wrote:

> My understanding is that performing the CLRWDT is going to clear the
> prescaler value (if it is assigned to the WDT) back to 1:1.  Thus, I
> will need to reset the prescaler value (in this case 1:32) in the
> OPTION register.

 You are getting confused.  CLRWDT resets the prescaler counter, not
the prescaler value (size).  Look closely.
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...