Searching \ for 'WDT? On Permanent Disability?' 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=wdt+permanent+disability
Search entire site for: 'WDT? On Permanent Disability?'.

Truncated match.
PICList Thread
'WDT? On Permanent Disability?'
1996\05\16@154045 by Mark Peterson

flavicon
face
       Sorry about the dumb joke in the subject, no offense to anybody.
Just trying to get a response.

        Somewhere I read that Watchdog Timers are useful in situations
where if the processor loses its mind, the WDT would kick in and run an
emergency shutdown routine. The worst-case scenario presented to me was
similar to this:

       A log spins on a lathe, the lathe speed is controlled by a slider
switch, the entire process is supervised by a processor. If the processor
were to crash, it is possible but not probable that the lathe speed could
increase and endanger life or a considerable investment. A WDT could respond
to the crash and shut down the lathe in an orderly and safe manner.

       The article went on to suggest that in cases where there did not
exist any risk to expensive equipment or life-form a WDT was rather useless.

       I have seen them used in some code examples and not in others. I
don't have an opinion about WDT's yet. The idea of crash-proofing is
appealing, but I had the notion to devote a timer (TMR0) to run anytime the
ISR executes and to TIME-OUT if either the interrupt routine needed too much
processor time or if it hung the system.

       Crash-proofing is an interesting topic. I don't imagine any digital
machines I create being utilized in lathes or operating rooms.
       So why else would a WDT be useful? If I have a resource like TMR0 to
dedicate to a supervisory position in the system, should I? Is it 6 of one
half-dozen of the other? The thing about TMR0 (without the prescaler) is
that you can read its value, and I'm not clear on whether you can read the
WDT's. Somehow I don't think so. I'll have to read the manual.
Later

1996\05\16@180855 by John Payson

flavicon
face
>          Somewhere I read that Watchdog Timers are useful in situations
> where if the processor loses its mind, the WDT would kick in and run an
> emergency shutdown routine. The worst-case scenario presented to me was
> similar to this:
>
>         A log spins on a lathe, the lathe speed is controlled by a slider
> switch, the entire process is supervised by a processor. If the processor
> were to crash, it is possible but not probable that the lathe speed could
> increase and endanger life or a considerable investment. A WDT could respond
> to the crash and shut down the lathe in an orderly and safe manner.

Actually, while watchdog timers are not necessarily a bad idea in such
systems, they are not a cure-all either.  If the operational risks imposed
by the system without the WDT would be unacceptable, then they should be
unacceptable even with the WDT.  (nb: adding watchdog HARDWARE in the control
systems may be--and often is--a good idea, e.g. making it so that if the
lathe speed gets too fast a hardware device will shut down the system safely.
For life-critical systems, there should never be any means by which even a
maliciously-malfunctioning CPU could be dangerous unless there has been a
WHOLE LOT of checking to ensure it's safe.)

The place watchdogs are useful is instead in non-critical systems which are
expected to run for a long time.  If a CPU-controlled light dimmer malfunc-
tions, it will probably not cause any great harm, but if it's left on for
months at a time it's likely to malfunction at some point.  If there is no
watchdog timer, the light switch will become non-useable if the CPU malfunc-
tions (unless/until it is restarted).  With a WDT, however, a malfunction
will get reset within a reasonably short period of time and the device will
continue to be useable.

1996\05\17@091032 by terogers

flavicon
face
Mark Peterson wrote:
>          Somewhere I read that Watchdog Timers are useful in situations
> where if the processor loses its mind, the WDT would kick in and run an
> emergency shutdown routine.

&etc.

Mark:

In the early days of microcomputer system design it was common to have
an external regular reset (yes, reset) so that the whole mess started
over from the beginning. This he-man design feature was in response to
two immutable facts: people didn't have a good grasp of chip & circuit
design, and people didn't bother to learn from the past (and therefore
re-invented the wheel, complete with flat tires).

With proper structured design and testing it is possible to arrive at a
probably reliable system design, but not a provably reliable design. The
possible use of the watchdog timer is just one element in the overall
bag of tricks that is brought to bear on the problem. Assuming that
other elements of the design process are accounted for, the WDT allows
you to either implement the above mentioned "smack yourself on the head"
approach or to allow an opportunity to assess and recover from the
supposed failure. In real time systems the latter failure is often taken
to indicate timliness problems, not necessarily a hardware or software
bug.

The trick in any case is to be able to evaluate the situation; in the
timed reset case, no previous history is usually assumed other than that
of a cold started system. At the other end of the spectrum a system may
spend more time documenting its operation than performing useful work,
and the failure analysis may take longer than the designed task. the
extreme cases are usually used in extreme circumstances: if you have a
completely unreachable system (say, on the moon) it wouldn't be bad if
it were to spend time healing itself after a failure. Similarly, an
absolutely critical system (say, monitoring a nuclear reactor) might be
reset at a rate more frequent than the required response time so that no
long term failure of the software can prevent an alarm.

If all of this points to lots of work in the design process, well,
that's the job. The WDT is just one small tool in the bag.

Good luck -- Tom Rogers

1996\05\17@102710 by myke predko

flavicon
face
Hi Mark,

Just looking through all the replies and the use that I use for the Watchdog
Timer is missing, that is to wake up the PIC from sleep.

From the previous replies, it's obvious on whether or not the wdt is used to
reset a Processor that runs amok is a philosophical question.  Personally, I
feel it shouldn't be required for properly qualified code.

But, the wtd is a very useful tool in applications where you want the PIC to
wake up every once in a while and check the current status of the hardware
around it.

My 2 cents...

Myke
Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\05\17@113010 by Martin J. Maney

flavicon
face
On Fri, 17 May 1996, terogers wrote:

> With proper structured design and testing it is possible to arrive at a
> probably reliable system design, but not a provably reliable design. The

With respect to testing, Dijkstra said it long ago: testing is adequate to
show the presence of faults, but never their absence [fairly close
paraphrase here].  The only way in principle to prove a system reliable
would be to construct a formal proof in parallel with the design - that's
more or less the motivation behind the entire range of "structured"
techniques.  Of course they're imperfect - they overprescribe in many
ways, the dogmatic form of "thou shalt use no gotos" being an obvious
example, and can't guarantee correct results - but that's the inevitable
result of attempting to make what is bascially a style guide (structured
programming) stand in for a far more rigorous method (formal correctness)
that you can't afford to use.

Sorry, your comment, in combination with the coffee just kicking in, set
me off on a hot button topic there.  :-)

1996\05\17@161946 by terogers

flavicon
face
Martin J. Maney wrote:

> With respect to testing, Dijkstra said it long ago: testing is adequate to
> show the presence of faults, but never their absence [fairly close
> paraphrase here].  The only way in principle to prove a system reliable
> would be to construct a formal proof in parallel with the design

&etc.

Actually, the only really provable stuff I know of is in research in the
UK, and is worse than you indicate by about an order of magnitude...

& boy, if you do that structured stuff by the book, it sure can get in
the way; I have yet to see any technique that a really good programmer
doesn't already use >> when it applies << . The rest of it can go jump
in the lake.

Maybe the classical structured techniques and all the overblown systems
for their use constitute a good test of the approximate level of
capability of a programmer: when you get to the point that you say "Oh,
I already do that", then you've got it.

== Tom

P.S. If you saw the interview of Knuth in DDJ last month, you might get
the idea he wouldn't necessarily agree with my point of view...

1996\05\18@001012 by Martin J. Maney

flavicon
face
On Fri, 17 May 1996, terogers wrote:

> & boy, if you do that structured stuff by the book, it sure can get in
> the way; I have yet to see any technique that a really good programmer
> doesn't already use >> when it applies << . The rest of it can go jump
> in the lake.

I'm not sure if we agree or not.  I have little use for the stylistic
rules _as such_, but find the underlying principles of inestimable
value.  Sure, 90% of all loops you can code by the seat of your
[experienced] pants - maybe I should say 99%? - but when you do run into
the occasional tangled mess it's really, really good to be comfortable
thinking about the loops' invariants.  And the only places I've ever run
into good discussion about such things were in texts on structured
programming.  Perhaps the problem is that such meaty stuff gets glossed
over in the popular texts.

> P.S. If you saw the interview of Knuth in DDJ last month, you might get
> the idea he wouldn't necessarily agree with my point of view...

I'll have to look that up if I get the chance.  One of my all-time
favorite articles on programming has to be Knuth's "Structured
Programming With Goto Statments".

1996\05\18@014218 by nigelg

flavicon
picon face
In message  <spam_OUT199605161848.LAA19162TakeThisOuTspamtidepool.com> .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU writes:

>         The article went on to suggest that in cases where there did not
> exist any risk to expensive equipment or life-form a WDT was rather useless.

For the last few years, Sharp TV's have included a hardware WDT circuit for
the main control microprocessor. It's quite simple, an output pin is
repeatedly toggled at various points in the program, this produce roughly
a 25Hz squarewave on the pin. This signal is used to charge a capacitor,
which then holds a transistor in the switched off state. If the processor
crashes, the squarewave disappears, and the transistor then turns on - this
is then used to perform a hardware reset via the reset pin.

This prevents any crashes affecting the TV, otherwise you would have to
turn the TV off and back on.

Nigel.

         /----------------------------------------------------------\
         | Nigel Goodwin   | Internet : nigelgspamKILLspamlpilsley.demon.co.uk |
         | Lower Pilsley   |                                        |
         | Chesterfield    |                                        |
         | England         |                                        |
         \----------------------------------------------------------/

1996\05\18@035110 by adrian

flavicon
picon face
"Martin J. Maney" wrote:

> On Fri, 17 May 1996, terogers wrote:
>
> > With proper structured design and testing it is possible to arrive at a
> > probably reliable system design, but not a provably reliable design. The
>
> With respect to testing, Dijkstra said it long ago: testing is adequate to
> show the presence of faults, but never their absence [fairly close
> paraphrase here].  The only way in principle to prove a system reliable
> would be to construct a formal proof in parallel with the design - that's
> more or less the motivation behind the entire range of "structured"
> techniques.  Of course they're imperfect - they overprescribe in many
> ways, the dogmatic form of "thou shalt use no gotos" being an obvious
> example, and can't guarantee correct results - but that's the inevitable
> result of attempting to make what is bascially a style guide (structured
> programming) stand in for a far more rigorous method (formal correctness)
> that you can't afford to use.
>
> Sorry, your comment, in combination with the coffee just kicking in, set
> me off on a hot button topic there.  :-)

Sounds like you like structured techniques (or rather they way in which they
are applied) as much as I do <-:

--
_
(_) _| _ . _  _   Tel +44 973 222257  Nokia orange in stock *NOW*. E&OE
( )(_|(  |(_|| )  Fax UK 0500 222258  http://www.eaglenet.co.uk/aa/
Moving to Bracknell? large family ?   http://www.eaglenet.co.uk/aa/house/

1996\05\20@114836 by Mark Peterson

flavicon
face
Nigel, thank you for your excellent example of a Watchdog implementation.

Everyone:
       Open question: Has anyone implemented a hardware Watchdog with a PIC?

       Query1:What might a suitable time constant be?  The Sharp example
refreshes the capacitor approx. every 40mSec.

       Query2: A well-posed PIC solution? :   RC in parallel one end of
each grounded, the other connected to the base of Q1 (NPN type). Base Q1
also to PIC port pin. Q1 emitter to ground, collector to PIC MCLR and to a
pullup resistor. Other end of pullup to +Vcc?
       It's been eons since I've worked with transistors. A TC of 500 mSec
(R=10K, C=50uF) would consume 500uA if my calcs are right.

       Interested persons please correct my arithmetic/circuitry. Toggling
a pin every 100mSec during a tick event (implies a 10Hz "system refresh
clock")would produce a sawtooth waveform with average value ????

       A partial list of constraints for the problem is (1)low power,
(2)use reasonable resistor/capacitor values(small footprint, in tune with
constraint 1), (3)requirements for refresh pulsing should be generous (25Hz
@20Mhz crystal, ?Hz@4Mhz), (4)a safety margin against false crash reset via
eqn: refresh rate=(1/RC)/(k) where k is the safety factor, i.e. the sawtooth
should appear as a ripple on +5vdc where v p-p is minimized.

       One final detail: On device power-up it appears the MCLR pin would
be low, thanks to our watchdog. We need a way around this!!! Ideas?


Feel free to shred the above. I'd like to follow Nigel's example to a
practical implementation. The beauty of the idea is that no software timers
are involved, and the software overhead is limited to a system level refresh
during the tick event (toggle a port pin). Did we just re-invent the wheel?
My instinct is to blow the fuse on the internal WDT and replace the function
(at my discretion) with a hardware solution.
       The main reason for disabling the WDT is that the numerous code
examples that don't have the fuse blown are plastered with CLRWDT
instructions. It's like you have to police your watchdog constantly yelling
"down boy, it's O.K." (only the neighbors). My voice grows hoarse just
thinking about it.

<.....mapKILLspamspam.....tidepool.com>

Credit to Nigel:

At 07:07 AM 5/17/96 GMT, you wrote:
{Quote hidden}

1996\05\20@135225 by terogers

flavicon
face
Mark Peterson wrote:

> Everyone:
>         Open question: Has anyone implemented a hardware Watchdog with a PIC?
& etc.

There are some nice low-cost reset ic's that can implement a wdt, either
independantly or by adding an external rc. Try checking the Dallas &
Maxim web pages..

-- Tom

1996\05\21@013905 by Scott Stephens

picon face
>I had the notion to devote a timer (TMR0) to run anytime the
>ISR executes and to TIME-OUT if either the interrupt routine needed too much
>processor time or if it hung the system.

Use WDT because:

* Don't count on the PIC being in an interruptable state (return address in
stack, interrupts enabled, et.)
* Your pick may not have a TMR0 int
* You might want the code and the interrupt for another use later. Sloppy
resource utilization.
* You may wish to re-initialize everything, as in a reset anyways (and you
can tell the difference between WDT, hard and soft resets).

>        So why else would a WDT be useful?

Only for a very innaccurate, temp. dependant periodic 20 MS interrupt.

>If I have a resource like TMR0 to
>dedicate to a supervisory position in the system, should I?

Keep your resource options open. TMR0 assumes an initialized processor state
for operation. A reset assumes nothing. Go with the reset :)

1996\05\21@031842 by fastfwd

face
flavicon
face
Scott Stephens <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> > I had the notion to devote a timer (TMR0) to run anytime the
> > ISR executes and to TIME-OUT if either the interrupt routine needed
> > too much processor time or if it hung the system.
>
> * Don't count on the PIC being in an interruptable state (return
>   address in stack, interrupts enabled, et.)
> * Your pick may not have a TMR0 int
> * You might want the code and the interrupt for another use later.
>   Sloppy resource utilization.
> * You may wish to  re-initialize everything, as in a reset anyways
>   (and you can tell the difference between WDT, hard and soft
>   resets).

   Here's another reason:

   The interrupt may continue to work perfectly, EVEN THOUGH your
   main routine fails.  This is why you should NEVER put "CLRWDT"
   commands inside an interrupt service routine.

> > So why else would a WDT be useful?
>
> Only for a very innaccurate, temp. dependant periodic 20 MS
> interrupt.

   Actually, it can be used as an accurate, temperature-INDEPENDENT
   periodic interrupt.  In my opinion, this is the cleverest thing
   Chip Gracey (author of the code in Parallax's BASIC STAMPs) has
   ever done.

   It works like this:

   You execute a CLRWDT instruction, then enter an infinite loop
   which simply increments a counter.  When the Watchdog Timer
   expires, it resets the PIC.  When your program starts again, you
   look at the value in the counter; it contains the length of the
   Watchdog Timer period.

   -Andy

Andrew Warren - RemoveMEfastfwdTakeThisOuTspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\05\23@174404 by Kalle Pihlajasaari

flavicon
face
Hi,

Long post about Watchdogs.  (woof!)

>     Open question: Has anyone implemented a hardware Watchdog with a PIC?

Yes.  I think not quite what you intended though.  We have quite a
few computers that have to work day and night and if they should
choke up (crash) we monitor the activity on the serial ports or
the network interface by looking at the activity LEDs.  Most
likely how the BBS user did it with Hard drive activity (or was
that on the STAMP list, whatever).

No activity for a predetermined time and the reset switch is
'pressed' to reboot the PC thing and then I also turn on the
drive on a output pin that is set low that is connected to
the _MCLR pin to reset the PIC as well.  This kicks in the
extra long ignore time during boot when there will be no activity
but one should not reboot.

Works like a charm and the PIC is reset as well if it causes a spurrious
reset.  I use the C84 and one resistor (Vcc to _MCLR) and one cap
(Vcc to Vdd).  I pull all the signals, a 3.068MHz clock and power
from one of out custom interface cards and just short two pins
to ground to 'press' the reset switch.  This works only if the reset
function is a input with a pull-up and switched to ground that
seems to be the most popular as then I don't have to polarise
the reset jumper.  Using BS2's works as well but costs a lot more.

>         Query1:What might a suitable time constant be?  The Sharp example
> refreshes the capacitor approx. every 40mSec.

Depends on how long you system may remain in an unknown state.

{Quote hidden}

Yes, connect the capacitor to Vcc and then it will yank up _MCLR
on power up.

I think that the PIC watchdog is a reliable beast that should be used
unless there is a real good reason that it cannot be used.

The reason for having wathcdogs in general is for systems that
have to operate unattended or have to have minimum crash time
that a human cannot respond to fast enough.

Just remember if you plan to use the PIC watchdog timer in
critical applications that the IO pins got Hi-Z for about
20ms (depends on PIC and config fuses) during the reset phase
so if you have to hold outputs without a glitch you need to
put in Latches or Flip-Flops.  You might get away with a cap
as well if your output does not have a low impedance.

{Quote hidden}

(shred-shred-sherd :-)
Yeah, you are suggesting code that mucks (read before write &c.) with the
PIC IO pins when there is a nice safely tucked away timer already
on the same wafer.  You should reset any watchdog as seldom as possible
and you can even change the kick interval with the internal WDT
by using the scaling counter (here you do wind up using system
resourses) but for fast code you can reset every 9 ms easily and
for real slow stuff you get to use it in 1 second time out mode.

>>         The article went on to suggest that in cases where there did not
>> exist any risk to expensive equipment or life-form a WDT was rather useless.

I use it whenever convenient.  Saves getting support calls and having
to suggest they cycle the power on whatever machine.

I also use it as a flashing error indicator in real fast code by using
a port pin to turn off an LED when healthy and the reset lets the LED
turn on again, if the link is not established then the LED flashes
at the period of WDT + reset timer.

{Quote hidden}

Exactly.

Plenty nuff said.

Cheers
--
Kalle Pihlajasaari     spamBeGonekallespamBeGonespamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

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