That's always a possibility, but I do keep an eye out for that very thing. I expect I'll learn more as the process progresses to varying the Vcc rise/fall time. It's difficult to perform experiments such as this without affecting the circuit in some way. That's why, so far, I've limited my "fooling around" to fiddling with the power supply rise/fall time. I am, however, looking for a solution that might alleviate the issue arising from the slow decay of Vcc, perhaps in concert with a supervisor.


It's not by any means a "normal" or anticipated occurrence. For exactly that reason, I substituted Intel, AMD, Signetics, Philips MCU's but found more or less the same thing. I'd point out, however, that I only observed it once or twice with the Dallas part, while the Philips and Intel parts seemed to exhibit this behavior quite frequently. Keep in mind that I was just "playing" with the power switch and observing the result on the logic analyzer and oscilloscope.

I'm partial to the Dallas DS89C4x0 because it's a high-speed drop-in replacement for the i8032 and that's the sort of application that I still have to support from time to time. I am interested in extending this experiment, but it takes time.



Which NXP processor would you recommend? I need it to be pin-compatible with the original DIP-40 Intel part, since that's what I have to support. It would have to be a part that they still produce and plan to continue to produce, and are willing to sample, though.



Erik, I made the initial, admittedly not rigorous, observations with a Philips P8032 MCU. Because the external memory bus timing of the Dallas MCU is different than with "classic" parts, I repeated that casual observation with various MCU's, including the Dallas part, although somewhat differently, i.e. with different power supplies, all of them in a circuit using external memory, i.e. 8032 mode. My goal at the time was, simply, to verify that "things" were happening with RESET active, which is not supposed to be the case. This was only possible because the experiment was not carefully controlled, and because the failure (BBRAM program store) rate was higher than 10%. That circuit was powered from a switcher (a small PSU providing +5Vdc @2.5 A and +/- 12 volts for the RS232) and a 7805 and had over 600 microfarads on Vcc. I tried several others, notably a retired PC/AT supply, but the rise time and much more significantly, the fall time of Vcc was quite slow due to the relatively large capacitance on the Vcc rail. With the switchers, the ripple was noticeable, but using a linear didn't make a noticeable difference.

The long-term test was done with the DS89C420 with a hefty linear power supply, allowed to rise in just under 10 ms and falling in about 15 microseconds. The next test, assuming I find time for it, will be with the same MCU but with a much shorter rise time and a very much shorter (<1 microsecond) decay time.

The rise is controlled with an integrator. The fall time is controlled with a MOSFET discharging Vcc through a resistor. The test was controlled and monitored with a PC.

I'm concerned about a couple of Dallas-specific matters, particularly the bidirectional RESET. The Dallas DS89C4x0's have a Vcc monitor on board, and assert RESET when it falls below 4.5 volts. The BBRAMs also have protection circuitry that becomes active at some point, but what concerns me at present is the fact that I saw activity on address and control signals during RESET, and that those occurred during RESET while Vcc was well below 4.75 volts.

If one stops the oscillator when RESET becomes active, then discharges Vcc, and then allows Vcc to rise at an acceptable rate (whatever that might be) so that the oscillator reliably starts again, that may well prevent any unwanted run-on of the MCU.

I'm interested in your comment once made about using a 10K-ohm resistor betwen two sources of RESET. I don't see how this will help, since there's at least one pulldownresistor, namely that within the MCU, and that's going to prevent the RESET signal from going high enough. Can you shed a bit more light on that?

RE