Searching \ for 'WDT stuff was Car battery power help' 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/power/batterys.htm?key=battery
Search entire site for: 'WDT stuff was Car battery power help'.

Truncated match.
PICList Thread
'WDT stuff was Car battery power help'
1999\11\04@225306 by Dennis Plunkett

flavicon
face
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.

lable
       SKIPNZ                          ;branch
       GOTO    not ready               ;branch

       code here
lable

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
                       then
               CLRWDT

Often we spread CLRWDT all over the place, naughty us, there should only be
one!

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.


Dennis


{Quote hidden}

1999\11\05@011801 by Brent Brown

picon face
> >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
a reset?

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
thoughts really...

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
designs.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
eMail:  brent.brownspamKILLspamclear.net.nz

1999\11\07@164441 by Dennis Plunkett

flavicon
face
At 19:11 5/11/99 +1300, you wrote:
{Quote hidden}

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.

Yes

>
>Thanks for sharing your thoughts which we can all consider in our
>designs.
>

That's OK



Dennis


>
>

1999\11\07@165943 by Sean Breheny

face picon face
Hi Dennis,

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,
page 50:

"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
instruction."

>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
>
>

Yes

>>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.
>
>Yes

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

|
| 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
.....shb7KILLspamspam.....cornell.edu ICQ #: 3329174

1999\11\07@181301 by Dennis Plunkett

flavicon
face
At 17:00 7/11/99 -0500, you wrote:
{Quote hidden}

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
off.
{Quote hidden}

Bad code Sean, re-organise it to remove this potential problem.

Dennis

>
>Sean
>
>

1999\11\07@224705 by paulb

flavicon
face
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.
--
 Cheers,
       Paul B.

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