The startup of the crystal oscillator is a big factor in the timing of the RC RESET circuit. The "typical" circuit, with a 10 uF cap pulled down with 8.2 k-ohms, has a rise time to 95% of about 245.650 milliseconds (see http://www.cvs1.uklinux.net/cgi-bin/c...const.cgi). That's a long time, which is needed primarily to allow time for the oscillator to start and stabilize under somewhat less than ideal conditions.

If you use an external oscillator, or if you build one yourself using a simple inverter, resistor and capacitors, the startup time can be considerably shorter, provided you have adequately short rise time on Vcc.

Kai Klaas has pointed out that the built-in oscillator in Atmel parts can keep on running as Vcc decays down to levels approaching 1.2 volts, IIRC. That means that it is likely to run on long after the logic, internal and external, is completely unpredictable.

From what I've observed, it's not unusual for one to use a large enough capacitance on Vcc to require nearly a second for Vcc to reach 95%. Without a specific discharge circuit, it's not unusual for such a circuit to take nearly 10 seconds to discharge its capacitance down to 1.2 volts.

My current effort is to determine RESET behavior outside the range of effects of the oscillator startup, so I use a gated oscillator controlled by Vcc On/Off timing together with the "standard" RC components. At some point I'll get around to fooling with the built-in oscillator. At present, I'm more concerned with MCU behavior under different Vcc rise and fall times, as those are very loosely specified.

The specifications should be interpreted with an eye to the oscillator startup characteristics. Brownout is a serious concern for MCU, memory, and logic circuits, but not for the oscillator, as Kai Klaas has pointed out. Self-protecting BBRAMs really can't be corrupted unless something entirely untoward occurs, such as MCU operation in the presence of RESET, which I hope, eventually, to explore.

I have already commented sufficiently (search if you're curious) on the usefulness of currently available reset/supervisor circuits. It should be clear that I find them somewhat wanting, in light of the fact I've observed an MCU running in the presence of RESET during slow Vcc decay. This does not mean that I believe such monitors are entirely unhelpful. I do, however, object to the way in which "reset problems" have been characterized in this forum, as there appears to have been no rigorous observation of "reset problems" that have actually been made. There has been evidence of "problems" that "went away" when a supervisor was introduced, though there has also been no evidence introduced that suggests that the reset-specific problem was solved.

Unfortunately, I've not been able to find precise characterization of MCU reset requirements and characteristics when using an external oscillator, aside from the requirement that RESET be present for at least two complete machine cycles (not oscillator periods).

Maybe something useful will surface with more study.

RE