'WDT stuff was Car battery power help'
|At 15:39 5/11/99 +1300, you wrote:
>Yes, there should be at least a voltage sensitive reset circuit on
>any micro in just about any practical application, particularly
>automotive. Watchdog is next on the list of most important things.
Is that so...
A watchdog is not important (My opinion) others will proberably not share
this same recourse but I will give you my reasons especialy for the PIC.
Fist code structure within the PIC is in such a way that only one
instuction is skipped on a possible branch condition. Often after the
branch instruction is another branch eg.
GOTO not ready ;branch
As the PIC has a small stack, not accessable to the software, corruption is
not likely by the software itself. So an accidental RETURN will bring you
back to a code section that you may have just been in or are going to. Thus
corruption may or may not cause a notticable problem (More on this to
come), in that unless that the system can detect such it may be possible to
continue on without a WDT.
Now lets look at the watchdog speed.
Most of us set this as slow as possible to avoid any possible miss hits.
This is often 512 clock cycles. For most applications if you look at the
code structure a CLRWDT will occur within the time period as nearly all the
code would / can be exicuted within this time frame, unless that the code
is structured in such a way as not to casue this to occur:-
eg. Wait for a bit to be set
Wait fot some external action
Often we spread CLRWDT all over the place, naughty us, there should only be
So what does this mean. Well in a round about sort of way the PIC enforces
a basic defensive programming style where the PIC will often come back from
a cosmic shock and still keep ticken (OK not a real word but I think it's
great, and you can invent words in english too!), lost of this is due to
the small code space. Don't beleve me.
OK try this.
Take a look at your nice code with its CLRWDT in it (Have you analysed it
for sporadic run time errors? I would put money on it that you have not).
Now pic a point any point in the code and start operations from there,
would the WDT go off?
Defensive progamming is the way to go, how many of you do 7-3 and check to
see that the result is <=4&>=0?. If you are worrided about cosmic stuff,
then you will nead to verify the status quo at regular intervals to see
that the thing has not corrupted itself.
WDTs are only good for getting you out of endless loops.
|> >Yes, there should be at least a voltage sensitive reset circuit on
> >any micro in just about any practical application, particularly
> >automotive. Watchdog is next on the list of most important things.
> Is that so...
> A watchdog is not important (My opinion) others will proberably not share
> this same recourse but I will give you my reasons especialy for the PIC...
OK Dennis I beleive you, I was probably more considering '51 stuff
than PIC's. Wouldn't it be great if we could just switch on the power
to any micro and it went forever without getting upset and requiring
All your points are good but it prompted me to think why I would
still use a watchdog with a PIC. Not major points, just little
I don't have extreme confidence with the oscillator startup on PICs.
Seems to me that many PICsters have had some kind of bad
experience with getting an external crystal to startup during
development which makes me a little suspicious. Whatever the
precise reasons behind this occuring in the field, if it ever did
happen a watchdog reset might get it going again (wouldn't it?)
Similarly, people have at times talked about the brownout detect
not being 100% reliable for all Vcc rise and fall rates or whatever
other reason. I'm happy enough to solely rely on the internal reset
and brownout functions, as long as I have the watchdog for backup.
How many times should we have CLRWDT in our code? Your right -
only once. Even though I sometimes do it myself, any more than
once is asking for trouble.
Thanks for sharing your thoughts which we can all consider in our
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
At 19:11 5/11/99 +1300, you wrote:
No, the WDT comes off the XTAL
>Similarly, people have at times talked about the brownout detect
>not being 100% reliable for all Vcc rise and fall rates or whatever
>other reason. I'm happy enough to solely rely on the internal reset
>and brownout functions, as long as I have the watchdog for backup.
WDT would not detect brownout unless that brownout condtions:-
1/ Kept the XTAL runing
2/ Caused the programme to stop running such that the WDT timer would go off.
Remember that in brownout it is unknown what is read and written to ports
and RAM, there is a chance that the WDT would and could be written correctly
>How many times should we have CLRWDT in our code? Your right -
> only once. Even though I sometimes do it myself, any more than
>once is asking for trouble.
>Thanks for sharing your thoughts which we can all consider in our
At 08:50 AM 11/8/99 +1100, you wrote:
>No, the WDT comes off the XTAL
Which chip are you talking about? I believe they are all the same with
respect to the WDT,and the following is quoted from the 16F84 datasheet,
"The Watchdog Timer is a free running on-chip RC
oscillator which does not require any external
components. This RC oscillator is separate from the
RC oscillator of the OSC1/CLKIN pin. That means that
the WDT will run even if the clock on the OSC1/CLKIN
and OSC2/CLKOUT pins of the device has been
stopped, for example, by execution of a SLEEP
>WDT would not detect brownout unless that brownout condtions:-
>1/ Kept the XTAL runing
>2/ Caused the programme to stop running such that the WDT timer would go off.
Well, it would not have to do #1 or #2. However, I suppose that it is
possible that a brown-out could cause the WDT's RC oscillator to stop OR
prevent the prescaler/counter from registering its pulses and causing a
reset. SO, it isn't a reliable brown-out detector.
>Remember that in brownout it is unknown what is read and written to ports
>and RAM, there is a chance that the WDT would and could be written correctly
>>How many times should we have CLRWDT in our code? Your right -
>> only once. Even though I sometimes do it myself, any more than
>>once is asking for trouble.
Well, I can see how it is BEST to only place it in your code once (reduce
the chance that the code would lock up by running an infinite loop it isn't
supposed to) ,but not always possible. I could have two loops in my code
that wait for some kind of event or input,and are so tight that they cannot
branch to a separate part of the code to run a CLRWDT.
| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
cornell.edu ICQ #: 3329174 shb7
At 17:00 7/11/99 -0500, you wrote:
Yep sorry about that, was thinking of 8605 stuff when I wrote this. I
should have twigged when I was thinking about how sloppy it is.
>>WDT would not detect brownout unless that brownout condtions:-
>>1/ Kept the XTAL runing
>>2/ Caused the programme to stop running such that the WDT timer would go
Bad code Sean, re-organise it to remove this potential problem.
I think it is fairly straightforward that the WDT will not assist
*during* a brownout as if code fails to run correctly due to low
voltage, then it is not going to *start* correctly at that voltage
either. So assuming the WDT does trip, it will keep trying to
re-start, but get nowhere. Whether the crystal is functioning at this
point makes little or no difference either.
Now, when the power comes back up to normal we have a conundrum.
There is some suggestion that chips may "jam" due to brownout and
require a complete power cycle to clear, notwithstanding internal reset
(from WDT) or external. However, it is equally possible that this state
may be avoided by holding the chip in reset during the brownout.
All in all, the WDT is of *no* use whatever in brownouts, which is why
you need a power monitor circuit of some kind.
As to how many CLRWDT you put in your code - this is certainly an
interesting discussion, and the answer is not trivial (i.e., "one" is
not the answer). This was discussed before, but the point is you really
have to know exactly *how* you actually expect your code to go wrong.
If you anticipate RAM corruption, then the WDT is of no direct help,
but may be used by a routine which checks RAM and trips WDT to force a
complete reset if it is corrupt.
If you anticipate a spurious jump to occur, then WDT will help where
the code jumps to a point from which it cannot return, as it will
reset. If however the code makes a spurious jump and is funnelled back
to the routine(s) which performs the CLRWDT, then WDT will not trip and
you need other checks for potential damage which may have occurred.
If the MCU jumps into an odd mode where it executes instructions in an
aberrant manner, then the WDT will help only insofar as it is able to
reset that MCU mode to normal, and that assuming that aberrant mode
doesn't happen to CLRWDT anyway.
And can the WDT correct for software bugs? Maybe; to some extent. It
is certainly not a panacea.
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...