Searching \ for 'WDT problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=wdt+problem
Search entire site for: 'WDT problem'.

Truncated match.
PICList Thread
'WDT problem'
1997\05\07@060749 by Ruben Jnsson

flavicon
face
Hello all.

I have a problem with the Watch Dog Timer (or the *TO bit in the
status register) in a 16C57.

When the program is reset by a power up or a WDT timeout it does a
selftest of all used instructions, the RTCC and the WDT.

The WDT timer is tested as follows:

The first time at power up (*TO=1) the selftest routine checks all
instructions, the RTCC and writes 0x12345678 into 4 ram registers. It
then does an endless loop broken only by the WDT, which in turn calls
the selftest routine again. This detects that it is a WDT timeout and
checks if the 4 ram registers contain 0x12345678. If they do it knows
that this was an intentional WDT timeout and resets the registers
again (so an unintentional WDT is detected) and returns. If there is
any faults detected or it was an unintentional WDT timout it goes
into and endless loop and indicates this on a LED output.

This all works fine - mostly! The problem is if I turn the power off
and on again quickly (VDD goes down to about 2V), then sometimes the
*TO bit is cleared at power up so the selftest routine thinks that it
was a WDT timeout and goes into the error loop because the 4 ram
registers are not 0x12345678.

I use a Dallas DS1233, 5V reset circuit which gives a nice and clean
300 ms reset pulse on MCLR at power up but this doesn't seem to
help. The *TO bit is sometimes cleared anyway.

I don't know how to deal with this problem, I can't just clear the
WDT at reset because then I can't test it. Is there anybody else that
has had similar problems and perhaps even solved them?

Regards
------------------------------------
Ruben Joensson
AB Liros Elektronik
Box 9124
200 39 Malmoe
Sweden
Tel +46 40 14 20 80
Mail: spam_OUTrubenTakeThisOuTspamsbbs.se
------------------------------------

1997\05\07@090947 by Gerhard Fiedler

picon face
At 12:04 07/05/97 +0000, Ruben Jšnsson wrote:
>This all works fine - mostly! The problem is if I turn the power off
>and on again quickly (VDD goes down to about 2V), then sometimes the
>*TO bit is cleared at power up so the selftest routine thinks that it
>was a WDT timeout and goes into the error loop because the 4 ram
>registers are not 0x12345678.
>
>I use a Dallas DS1233, 5V reset circuit which gives a nice and clean
>300 ms reset pulse on MCLR at power up but this doesn't seem to
>help. The *TO bit is sometimes cleared anyway.
>
>I don't know how to deal with this problem, I can't just clear the
>WDT at reset because then I can't test it. Is there anybody else that
>has had similar problems and perhaps even solved them?

I recall having heard that in various other applications they had trouble
with this chip, and replacing it by the Maxim equivalent helped them. (You
say it's working fine, though -- they had trouble with it not giving a
proper reset pulse.)

I had a quick look at a data sheet and it says "u" for the /TO bit at a
"/MCLR Reset during normal operation", which probably is your case. Are you
sure you don't reset it somewhere?

Gerhard

1997\05\07@094742 by Ruben Jnsson

flavicon
face
{Quote hidden}

The dallas DS1233 works fine, It holds reset low as long as VDD is
less than 4.5 V, and keeps it low for abt 300 ms after it goes above
4.5V.

I also change the OPTION register (the data book  says it is set to
all ones at reset) to prescaler for RTCC and prescalervalue to 3. The
data book also says that I should use CLRWDT before setting the
OPTION register when changing the prescaler from WDT to RTCC
but I can't do that because it also sets the *TO bit. Anyway the
according to the databook both the prescaler and WDT is cleared
during reset.

I'm going to see wat happens if i save the *TO bit before I set the
OPTION register and do the test on the saved bit instead.

Still I don't think it has anything to do with how my program is done
because it works most of the time.



------------------------------------
Ruben Jšnsson
AB Liros Elektronik
Box 9124
200 39 Malmš
Sweden
Tel +46 40 14 20 80
Mail: EraseMErubenspam_OUTspamTakeThisOuTsbbs.se
------------------------------------

1997\05\08@203344 by gordon slater

flavicon
face
At 12:04 PM 7/05/97 +0000, Ruben Jšnsson wrote:
{Quote hidden}

I have experienced a very similar problem with the PI16C74-JW parts.

The problem as best as I can determine occurs if the supply voltage does not
disappear totally before a restart.

The application that exhibited this problem is one in which the PIC is
switched on for short periods, generally no more than 30 secs, and can be
off from 1 sec to days, so put a DS1233 on the MCLR fo safety, to be sure
that there is always a good reset condition, unfortuately that did not
resolve the problem.

I am using a LDO(Low Dropout Regulator) which requires a large capacitor
(47uF) on the output, and this holds the supply to the chip at less than a
volt for a long while after power has been removed. If power is reapplied
while there is still some voltage present on the VDD to the chip, the PIC
will sometimes not start properly - even though the  MCLR pin is held low
while power is being applied and held low for 300ms. The situation the PIC
seems to get into is that the watchdog does not get reset by CLRWDT, and so
the processor continuously gets itself reset by the watchdog - this
situation continues even if MCLR is shorted to ground (by a jumper) in an
attempt to reset the PIC. The situation clears itself if VDD is shorted to
ground and it will then restart correctly.

To rephrase something said above in case of confusion - the pic does restart
properly, but it is solely the watchdog which cannot be reset, and hence
restarts the pic continuously ad infintum, until VDD is zeroed.

I rewrote code, setting all registers during initialization, but the problem
is still there.

I am hoping that the A versions of the chip with brown out protection fix
this problem, but in the mean time I have built an extra circuit which
shorts the VDD  to GND, and this seems to have gotten around the problem,
but it is a messy solution.

I have also changed to an LDO that requires only 3.3uF on the output.

I know of another user who has experienced very similar problems, and he too
has had to get around the problem by ensuring VDD goes to ground.

Does any one know if this problem is fixed by the BROWN OUT on the A chips?



Hope this little bit helps

regards

Gordon Slater

@spam@gordonsKILLspamspamcobweb.com.au

1997\05\12@042453 by Tim Forcer

flavicon
face
At 12:04 PM 7/05/97 Ruben Jšnsson wrote:
>>I have a problem with the Watch Dog Timer...CUT...

At 10:04 AM 9/05/97 Gordon Slater wrote:
>I have experienced a very similar problem... using a LDO
>(Low Dropout Regulator) which requires a large capacitor
>(47uF) on the output, and this holds the supply to the chip at less than a
>volt for a long while after power has been removed. If power is reapplied
>while there is still some voltage present on the VDD to the chip, the PIC
>will sometimes not start properly....cut...

I may have missed a response to this in my digest of 3 days' traffic.  If
so, sorry.  Otherwise, solution (which should be a standard part of most
regulator/supervisory circuits) is to fit a diode FROM output TO input.
Type is not particularly important, as long as it can handle the peak
(regulated side) capacitive discharge.  Reverse breakdown is irrelevant,
since the regulator will fail long before then!  The diode ensures that the
output volts drop fast with input volts - it may be worth fitting a resistor
across the input of the regulator so that the output volts can decay all the
way to Vd.

The requirement for many LDO regulators to have quite huge electrolytics on
their output side is very bad news when trying to design small-scale and/or
low-cost circuits.  From personal experience, the Texas TL750L05CLP is bad
in this respect, the Zetex ZR78L05C is pretty good.  Some LDO regulators
also have poor ripple rejection or other characteristics compared to
standard types.

Tim Forcer               KILLspamtmfKILLspamspamecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions

1997\05\12@072820 by Ruben Jnsson

flavicon
face
> Date:          Fri, 9 May 1997 10:09:47 -1700 (GMT)
> To:            RemoveMErubenTakeThisOuTspamsbbs.se
> From:          gordon slater <spamBeGonegordonsspamBeGonespamcobweb.com.au>
> Subject:       WDT problem

--- SNIP ---

{Quote hidden}

---SNIP---

Hello Gordon and thanks for your reply.

After a bit of further investigation (experimentation) I have found
out the following:

What happens when I switch the power of and on again before it has
gone completely to zero is that the DS1233 resets the PIC which stops
to work but somehow the WDT also times out and sets the *TO bit. When
power is switched on again the PIC continues to run after the 300 ms
MCLR reset. Since the VDD has been high enough for the PIC to continue to
work, it has seen this as a MCLR reset with power still on. Since a
MCLR reset dosn't change the *TO bit the program thinks it has been a
WDT timeout.

I have solved my problem by not using the *TO bit to check if the
reset came from a WDT (since I can't rely on it) and instead using a
signature in RAM which is set to a certain value when I have tested
the WDT at power up the first time. This signature is then not changed
by the short interruption of the power.



------------------------------------
Ruben Joensson
AB Liros Elektronik
Box 9124
200 39 Malmoe
Sweden
Tel +46 40 14 20 80
Mail: TakeThisOuTrubenEraseMEspamspam_OUTsbbs.se
------------------------------------

1997\05\12@191546 by Gerhard Fiedler

picon face
At 13:24 12/05/97 +0000, Ruben Jšnsson wrote:
>I have solved my problem by not using the *TO bit to check if the
>reset came from a WDT (since I can't rely on it) and instead using a
>signature in RAM which is set to a certain value when I have tested
>the WDT at power up the first time. This signature is then not changed
> by the short interruption of the power.

How do you then detect the difference between a real WDT reset and a /MCLR
reset?

1997\05\13@021914 by Ruben Jnsson

flavicon
face
> Date:          Sun, 12 May 1996 20:13:58 +0000
> Reply-to:      pic microcontroller discussion list <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
> From:          Gerhard Fiedler <GerhardEraseMEspam.....POBOX.COM>
> Subject:       Re: WDT problem
> To:            EraseMEPICLISTspamMITVMA.MIT.EDU

> At 13:24 12/05/97 +0000, Ruben Jšnsson wrote:
> >I have solved my problem by not using the *TO bit to check if the
> >reset came from a WDT (since I can't rely on it) and instead using a
> >signature in RAM which is set to a certain value when I have tested
> >the WDT at power up the first time. This signature is then not changed
> > by the short interruption of the power.
>
> How do you then detect the difference between a real WDT reset and a /MCLR
> reset?

I don't, but it doesn't realy matter. In my aplication the main thing is that
the program gets back to a known state if something caused it to get
out of control.
------------------------------------
Ruben Jšnsson
AB Liros Elektronik
Box 9124
200 39 Malmš
Sweden
Tel +46 40 14 20 80
Mail: RemoveMErubenEraseMEspamEraseMEsbbs.se
------------------------------------

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