Searching \ for 'WDT stuff was Car battery power help [Extreamly lo' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'WDT stuff was Car battery power help [Extreamly lo'.

Truncated match.
PICList Thread
'WDT stuff was Car battery power help [Extreamly lo'
1999\11\07@234719 by Dennis Plunkett

At 14:46 8/11/99 +1100, you wrote:
>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.

This is a bit cart and horse type stuff. In that if the XTAL is operating,
then you can assume that the programme will be attempting to flow. By this
I mean that the WDT must function past the nominal expected processor
operating point.

As for not going to start correctly, this is an assumption based on the
fact that the low power caused the WDT to trip in the first place. This may
not always be the case, as there may be a set of rules that allow the
processor to enter said state when power is at X and wheninstruction Y is
performed with value D sitting on the data bus. Such may not always be so

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

The PIC require a correct dv/dt for a correct reset condtion, else the
processor will not be in the correct operating mode, have latches set to
the correct state and preload values may not be correct. As this is an
unknown state there is no guarrente that teh WDT will work and bing the
processor back from the brink. These are tests that you can perform
yourself. Why is this so? Take a look at the prescaler, if this is
corruppted then it may not ba associated to the correct location. But you
say that this should still make hte WDT occur. Yes this would be so, but
from where does the WDT come? Read from a location in EPROM that is then
used to set a register to assert the function (Ask your Microchip rep how
the WDT is implemented, and what occurs with the PIC during the power up
initialaisation phase, the answers may be interesting)

As for holding a chip in reset during a brownout, yes this is nominally the
only thing that works. There are other methods that suppy a reset after the
power has reached X level for Y period, but these assume a very low power
system where the chip has entered a correct shutdown state before power loss.

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

Yes you have to know how your code will go wrong and what it is attempting
to do, but for the most part a CLRWDT should only appear in one place that
is not interrupt driven, or excited by an interupt function. Hence putting
a CLRWDT inside a main, where the code is timer dirven for exicution is not
a good idea. In such it should be placed at the end of the loop after all
the functions that may be called are called.

>  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 are able to detect that RAM is defunct, then the code must be
operating to an acceptable level. To force a reset in this case would be

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

Correct, this is why I said that WDT on the PIC are of little use, unless
you like to write loop forever type code (If this is the case then you will
be found out by the code police and taken out the back and shot)

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

See my comments on previous posts


>  Cheers,
>        Paul B.

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