Truncated match.
PICList
Thread
'Re[2]: Cheap Reset Circuit -- With slowly rising V'
1997\08\21@093213
by
Scott Walsh
|
Mike,
What I think you are eluding to here is the behaviour of the crystal
or resonator that you are using. They like to be applied with a rapid
rising voltage rather than a slow rising voltage.
I know what you mean though, and believe that this is also a part of
my orignal problem.
regards,
SW.
______________________________ Reply Separator _________________________________
Subject: Re: Cheap Reset Circuit -- With slowly rising Vcc (Battery)
Author: spam_OUTmikesmith_ozTakeThisOuT
relaymail.net at INTERNET
Date: 21/08/97 20:44
On 20 Aug 97 at 20:57, Jim Ham wrote:
{Quote hidden}> I know of two generic methods to solve the problem. One is a
> transistor and resistors or a zener as shown in the data sheet. This
> is the least expensive (from component cost point of view) method.
> The other is to use a power supply supervisor. Check out Maxim and
> Dallas. This is a more expensive solution (US$1 to US$2), but they
> have features that might be worth the cost: Low power, smaller
> footprint, more precise, and turn-on delay. I believe that you will
> find that you will need to handle reset in some way. I have a
> product that I am recalling because of this. Believe me, it's better
> to do it right the first time.
>
> The watchdog does _NOT_ work reliable after broun-out. I have no
> explaination for this, only experience with 16F84s. The 'F84s will
> wake up "sort of" working, and the watchdog will not do a proper
> reset. Ports wake up in a funny mode (not documented) and there is a
> good possibility that the EEPROM is corrupted.
Reset doesn't always seem to remedy some of the problems, either.
How about a 'snap' action on the Vdd pin? (so any voltage below, say
4 volts give 0 v output, then turns on quickly at above 4 volts)
MikeS
<.....mikesmith_ozKILLspam
@spam@relaymail.net>
=== For PICLIST help (including "unsubscribe" instructions),
=== send an e-mail containing the single phrase "help piclist"
=== to: listserv
KILLspammitvma.mit.edu
1997\08\21@142703
by
Miller, Steve
My guess is that VCC is dropping far enough to stop the oscillator. If VCC
slowly increases back to a normal level, the crystal or resonator oscillator may
not restart. (RC circuits are supposed to be guaranteed to restart.) The
crystal or resonator schemes need a sharp VCC rise to kick start them. The
circuit is really just an amplifier with a frequency selective feedback loop.
The sharp VCC rise generates an initial output transient that get filtered and
fed back for regenerative feedback. Without the frequency rich initial impulse
to drive the filter, there is no signal to filter.
If the oscillator does not restart, no code is being executed and the watchdog
does you no good. An external reset circuit will not save you here, because
reset only restarts the code. The oscillator circuit is independent of reset.
The ultimate fix, is to cycle VCC along with reset as has already been
described.
1997\08\21@145656
by
John Payson
|
> My guess is that VCC is dropping far enough to stop the oscillator. If VCC
> slowly increases back to a normal level, the crystal or resonator oscillator
may
> not restart. (RC circuits are supposed to be guaranteed to restart.)
RC circuits "always" work because they are always in one of two states:
[1] Charging the cap, and waiting for it to reach a level near VDD
[2] Discharging the cap, and waiting for it to reach a level near VSS
Unlike a crystal or LC oscillator where DV/DT is an important part of the
oscillator's state, an RC oscillator simply has the two states above.
> The
> crystal or resonator schemes need a sharp VCC rise to kick start them. The
> circuit is really just an amplifier with a frequency selective feedback loop.
> The sharp VCC rise generates an initial output transient that get filtered and
> fed back for regenerative feedback. Without the frequency rich initial impulse
> to drive the filter, there is no signal to filter.
True, but...
> If the oscillator does not restart, no code is being executed and the watchdog
> does you no good. An external reset circuit will not save you here, because
> reset only restarts the code. The oscillator circuit is independent of reset.
> The ultimate fix, is to cycle VCC along with reset as has already been
> described.
When the /MClr line is held low, the oscillator is inhibitted; OSCOUT is low,
and OSCIN is weakly pulled low. When /MClr is released, OSCOUT will swing
high quickly; this will start the oscillator.
I don't know whether the PIC hammers the oscillator on a watchdog timeout; if
it doesn't, it would probably be a good idea for future models to do so.
1997\08\21@152337
by
John Shreffler
part 0 759 bytes
-----Original Message-----
From: John Payson [SMTP:.....supercatKILLspam
.....MCS.NET]
Sent: Thursday, August 21, 1997 2:45 PM
To: EraseMEPICLISTspam_OUT
TakeThisOuTMITVMA.MIT.EDU
Subject: Re: Re[2]: Cheap Reset Circuit -- With slowly rising Vcc (Batter
John Payson wrote:
When the /MClr line is held low, the oscillator is inhibitted; OSCOUT is low,
and OSCIN is weakly pulled low. When /MClr is released, OSCOUT will swing
high quickly; this will start the oscillator.
I don't know whether the PIC hammers the oscillator on a watchdog timeout; if
it doesn't, it would probably be a good idea for future models to do so.
I don't think MCLR stops the oscillator. Although I don't program PICs, a
design
I specified recently depended on the oscillator running during a MCLR reset.
1997\08\21@163834
by
John Payson
|
> When the /MClr line is held low, the oscillator is inhibitted; OSCOUT is low,
> and OSCIN is weakly pulled low. When /MClr is released, OSCOUT will swing
> high quickly; this will start the oscillator.
>
> I don't know whether the PIC hammers the oscillator on a watchdog timeout; if
> it doesn't, it would probably be a good idea for future models to do so.
>
> I don't think MCLR stops the oscillator. Although I don't program PICs, a
> design
> I specified recently depended on the oscillator running during a MCLR reset.
Hmm... that differs from my recollection, though the cases where it's been
a problem to me were the times when /MClr was accidentally left unconnected
(it sinks groundward if it is). It may be that if /MClr is never raised,
that the oscillator won't start until it is (this may improve startup behav-
ior). So we may both be right... though in different ways.
Perhaps the best behavior would be to have a fuse-settable option for
whether the oscillator should be stopped on reset since there are definite
pros and cons to such an approach (if the oscillator stops on reset, then
power consumption will be minimized; a simple battery-backup approach would
be to connect /MClr to the external VDD and use diodes to power the PIC from
battery or external VDD as appropriate). Unfortunately, such an approach
would cause the PIC to run continously when VDD went away--even if the PIC
tried to SLEEP.
On the other hand, letting the oscillator run while /MClr is low allows it
to get started faster, and allows the chip to start running code sooner,
than waiting until /MClr rises. It also helps in applications where the
clock is used for other purposes as well.
Interesting arguments for both sides...
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- Today
- New search...