Yes, if one manufacturer or another would actually admit that there's a basic problem with the RESET scheme on the 805x core, then everyone could stop denying it.

I don't deny that there's been a problem. I don't deny that a supervisor can help in mitigating the problem. However, I've seen multiple instances with more than one manufacturer's MCU wherein the MCU continues to access external memory during decaying Vcc despite the assertion of RESET by a supervisor.

BTW, that was a DS1232, and not a MAX1232 as I misstated yesterday.

It disturbs me that there are no detailed accounts of how these "RESET problems" were identified, isolated, characterized, "cured," and the cure verified. Mainly, this is because I'm looking for "handles" to grab in establishing a thorough test procedure to recreate and characterize the faults, but also, because it shows a generalized willingness to accept what folklore is bandied about by the chip manufacturers.

I recognize that the boss gets upset if there's a complaint about failure to reset on power-up in one of every 100 cases. I also recognize that it's a serious improvement if that is reduced to one of 10000 cases by the addition of a supervisor. However, I feel it inappropriate to sweep those 100 of every million cases under the rug just because their cause and effect is not understood. A 5000 hour mean time between failures is tolerable. That's somewhat less frequent than once a year. However, if a few customers have "RESET" failures once a week, It's understandable that they'd be upset. They don't care that they're the one out of 10000. If replacing the board fixes their problem, then there's a problem with the board. If it doesn't, perhaps because it's a power-supply issue, then you haven't fixed anything. Has anyone pursued this problem to any depth?

I suppose there's going to be much more grumbling about how it's obvious that a supervisor "fixes" everything. In the meantime, however, I'm confronted with a case in which, during the power-down transient, I observed unanticipated accesses to external memory in the presence of RESET. It really doesn't matter that the RESET was caused by a supervisor. What matters is that the MCU ran away during Vcc decay and a probably below-specifications Vrst didn't stop it.

While several posters have argued that a supervisor fixes everything, there's really no concrete supporting evidence. When a system fails to start normally on power-up, it can be called a RESET problem but it may actually originate with the oscillator, and if it's an oscillator problem, it could be a Vcc rise time problem.

Before manufacturers started incorporating self-writeable flash program store into 805x's, there was no RESET problem. This doesn't mean that the 805x RESET worked perfectly with just the RC that was initially recommended, though. What it means is that an imperfect RESET had little consequence beyond requiring someone to push the RESET button. Self-writeable flash lowered the package cost by an order of magnitude, far offsetting the added programming cost during assembly. Manufacturers wanted to sell their products. They didn't care that there were now additional risks due to self-corrupting program store. If one manufacturer swept it under the rug, then that's what they all did. Did they actually set about to test their product? Well, maybe, but they didn't publish their test results. Instead, a very few of them published an app-note that happened to include a supervisor.

Now, in order to make these supervisors applicable to most MCU's, and not just to 805x's, they were built with a number of compromises for the general case, which meant they had no way to stop the runaway 805x as power decays. It's simple economics. However, the 805x makers wanted to present the image that there was a "FIX" to be had, the problem being serious and widespread enough to be of concern to end users capable of switching away from the flawed 805x MCU. The result was that the entire 805x community was stampeded into thinking the supervisor was a fix for all evils, which it's not.

Often, when a hobbyist asks why his circuit doesn't work, the knee-jerk response from 8052.COM is "do you have a proper RESET IC?" before it's even established that he could simply push the reset switch to make it start. For a kitchen-table experiment, particularly one on a "solderless-breadboard" or other fragile and recklessly constructed setup, if it starts half of the time, that's adequate. In most cases, the O/P doesn't care how reliably his circuit works since he has no equipment with which to verify that it does. He simply wants to see characters on his LCD, which doesn't work because he hasn't yet read, or even obtained, a datasheet. He thinks he has a RESET problem because that's what he's told on 8052.COM, and not because that's what's been observed.

Since I've been presented with no information about what fails, I have to test what doesn't. I expect the first test I'll perform involves a "proper" power supply, with a <1ms risetime and a <10 us fall time. I'll be surprised if there's any trouble with that over a long-term test, whethere there's a supervisor or just an RC. I also suspect that if there's a RESET without a power cycle, there'll be no trouble. We'll see, I guess.

RE