Searching \ for '[PIC]: WatchDog Timer Routines and Implemenations?' 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/microchip/time.htm?key=time
Search entire site for: 'WatchDog Timer Routines and Implemenations?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: WatchDog Timer Routines and Implemenations?'
2003\04\22@104033 by Mccauley, Daniel H

flavicon
face
Being a high voltage / high power transmitter engineer by trade, I don't
have much experience with digital processor stuff like the PIC. Could
someone explain how watchdog timer routines are typically implemented and
some general guidelines???

Thanks much!

D

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\22@110330 by Olin Lathrop

face picon face
> Being a high voltage / high power transmitter engineer by trade, I don't
> have much experience with digital processor stuff like the PIC. Could
> someone explain how watchdog timer routines are typically implemented
> and some general guidelines???

Probably, but not me.  I personally don't find much use for the watchdog
timer as a watchdog.  The one time I needed a watchdog function in a
safety-critical system, this needed to be performed by separate hardware
that had its own sensor.  This hardware could kill power thru totally
independent means from the main operating processor.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\22@113713 by Rick Regan

picon face
> Could someone explain how watchdog timer routines
> are typically implemented and some general
> guidelines???

Embedded Systems Programming Magazine has some
generic articles on watchdog timers which may be of
interest.  Just go to http://www.embedded.com/ and
search on 'watchdog'.




__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\22@115941 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Tuesday, April 22, 2003
3:39 PM:

> Being a high voltage / high power transmitter engineer by trade, I
> don't have much experience with digital processor stuff like the PIC.
> Could someone explain how watchdog timer routines are typically
> implemented and some general guidelines???

However carefully you code, however good the design, and however quiet the
environment, there will, at some point, be a time when your code does
something you didn't expect it to.  Watchdogs try to catch the unexpected
situations and reset the code.

There was an article at http://www.embedded.com recently about watchdogs,
http://www.embedded.com/story/OEG20030220S0037
There have been a few others, try a search on the embedded.com homepage for
"ganssle watchdog" (without the quotes), and have a look.

As far as PICs are concerned, there is a 20ms (approx) timer, with
adjustable prescalers, if the wdt is enabled (by setting the config fuses
on programming), you need to clear it using clrwdt before it times out and
resets the processor.  On boot, you can detect if the reset was due to a
watchdog timeout and try to deal with it.

As watchdogs go, the pic one is reasonably good, but it's far from perfect
(single instruction to clear it, clear as often as you like etc etc).

Nigel
--
Nigel Orr, Design Engineer                 spam_OUTnigelTakeThisOuTspamaxoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\22@122430 by M. Adam Davis

flavicon
face
In general:

A watchdog is any element of a design which is meant to detect and react
to unintended failures.

In the case of many microcontrollers with built in watchdog timers, the
watchdog simply resets the machine, and sets some register to a
particular state so that on reset the code can detect the watchdog event
and act accordingly.  Typically the watchdog is periodically 'refreshed'
by correct operation of the code.   This could be a write to a specific
register, a defined sequence of writes with particular bytes to one or
more registers, or toggling a hardware pin, perhaps in an interesting
sequence.

The idea is that you embed in you code this refresh so that when the
code is operating correctly the refresh happens, and when it isn't the
refresh doesn't occur, thus resetting your device to a known state.

In the PIC the watchdog is a very simple single register write refresh.
You can write anything to the register.  This is nice, but certian kinds
of runaway code (such as a memory clear routine) could still refresh the
watchdog so the processor isn't reset.  But with good design you can
catch most of the problems that occur.

The routine you might follow depends on your application.  If you are
developing a clock, for instance, then you know the display needs to be
updated frequently - you could place the refresh inside the disply
update routine.  If the display isn't refreshed quickly enough, the
watchdog resets the processor.

If you are controlling a machine which has to stay inside certian bounds
then you could update the watchdog every 20mS only as long as the
location registers were within bounds.  Idealy your program already
takes care of that, but if a power glitch changes a register randomly
without reseting the processor then your watchdog will catch it.

There are several other good resources on watchdogs in general.  I hope
this helps!

-Adam

Mccauley, Daniel H wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\04\23@045138 by Peter L. Peres

picon face
In a normally programmed and operating cpu the instruction execution order
is well defined and known at all times, together with the time it takes
each segment of code to run. Should something go wrong (glitch etc) then
this order will be changed, and with it the timing.

A watchdog circuit is a hardware timer that runs down continuously,
regardless of what the cpu is doing, with the exception of a clrwdt
instruction or resetting the watchdog prescaler. If the timer runs down
completely it causes a reset of the cpu and that should allow the cpu to
be reset to a valid state. The amount of time the watchdog takes to run
down is fixed (but settable by the user on a pic).

So a watchdog timer reset (clrwdt) is best placed in the user's code in a
location where it is executed regularly, with a period just smaller than
the timeout of the watchdog, while the program is running correctly, but
not if its not. Since there is no way to know where the 'right' location
is beforehead, clrwdt should be put in a location that has a low
probability to execute if the code does not work right. This would be a
program segment that is crucial to the function of the code. It is
difficult to determine a general case, the best location depends on the
application. Sometimes more than one clrwdt is used, depending on
execution paths. In any case use as few as possible, this reduces the
likelihood of their being executed when the cpu is operating randomly.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\04\23@100205 by Bob Ammerman

picon face
You can improve the probability of the watchdog biting on a software error
by using a technique like this:


wdt_flags    res    1

WDTF_ISRA = 0
WDTF_ISRB = 1
WDTF_MAINLOOP = 2
WDTF_OTHERPLACE = 3
WDTF_ALLMASK = B'00001111'    ; mask of used bits


... at initialization ...

   clrf        wdt_flags

.... at the top of the main loop ....

   bcf        wdt_flags, WDTF_MAINLOOP
   movf    wdt_flags,F
   skpz
   goto    dont_kick_dog
   movlw    WDTF_ALLMASK
   movwf    wdt_flags
   clrwdt
dont_kick_dog:

... somewhere in ISR A ...

   bcf    wdt_flags,WDTF_ISRA

... somewhere in ISR B ...

   bcf    wdt_flags,WDTF_ISRB

... somewhere in some other place ...

   bcf    wdt_flags,WDTF_OTHERPLACE


This code ensures that several different code paths are being executed
before it will clear the watchdog.

Bob Ammerman
RAm Systems


{Original Message removed}

2003\04\24@045133 by Peter L. Peres

picon face
Bob Ammerman <.....rammermanKILLspamspam@spam@ADELPHIA.NET> wrote:
>You can improve the probability of the watchdog biting on a software
>error by using a technique like this: ...

Yes, that is a good idea, it's just that the 'checker' must run in an
often-executed piece of code to be aware of all the bits in time. I find
the effort required to code it like that too great. Unless you have a
timer isr that runs all the time and you can put it in it it's hard to
maintain when writing code in higher languages (like C).

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\04\24@073422 by Bob Ammerman

picon face
In many systems the checker can just go at the top of the main loop.

Oh, and there is no reason it can't go into a function that is called
instead of the raw CLRWDT instruction.

Bob Ammerman
RAm Systems

{Original Message removed}

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