Post by thread:Re[2]: Cheap Reset Circuit -- With slowly rising V

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_ozTakeThisOuTrelaymail.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: listservKILLspammitvma.mit.edu

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.

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

part 0 759 bytes -----Original Message----- From: John Payson [SMTP:.....supercatKILLspam.....MCS.NET] Sent: Thursday, August 21, 1997 2:45 PM To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.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.

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