This is a recommendation that one use a supervisor, or otherwise prevent operation of the MCU outside its specified limits. It doesn't really deal with the purported "RESET problems." I agree that one should do everything to avoid operating the MCU outside its specified limits, as, when one does that, one is on one's own and has no recourse against the manufacturer nor has one any way of averting difficulties with the rest of the circuitry.

However, if one simply operates his circuit only after the Vcc has reached the nominal value set forth in the MCU spec's, and if one immediately prevents operation of the MCU, either by very rapidly reducing Vcc to somewhere below 0.25 volts when Vcc is detectably below the minimum set forth by the manufacturer, problems are avoided. I don't see that RESET is a player in this arena. It's just a proposed way to prevent the operation of the MCU outside its specified limits. Unfortunately, there's room for doubt as to whether it actually is effective. If registers, etc malfunction once Vcc is out of spec's, then RESET can't be guaranteed to stop things from going awry. I've observed this, in one case, repeatedly, though I've been unsuccessful in reliably reproducing it.

Erik once described a situation, one to which I recently referred, in which he had a customer who complained that the system in question didn't start up when power was first applied, but, if power was shut down and then reapplied, it worked, at least most of the time. He dealt with that by inserting a supervisor in the circuit, and that seems to have satisfied his customer. That looks to me more like a RESET problem candidate of some sort, though it could also be a simple consequence of too-slow a Vcc rise time.

You, Kai, have never complained of RESET or any other difficulties. The fact that you routinely use a supervisor, the MAX1232, IIRC, and you do it on the advice of the document you've cited. That's sound enough practice that nobody could find fault with it. The fact that you've not had any of those annoying "RESET problems" bears witness to that.

The original instance in which I observed run-on during RESET was with a DALLAS MCU, an older DS89C420. However, the second instance was with a Philips MCU, but in the same physical circuit. The situation is clouded, however, by the fact that I was using both MCU's in 8032 mode, with external program store, and with the fact that those were Dallas BBRAM's. These BBRAM's purportedly have their own brownout protection that inhibits writes, but, having seen the write line go active during RESET, and having observed that the content was altered, but not able to verify that it occurred during that particular instance, and not diligent enough at the time to verify that the BBRAM's write timing was too slow, at the slightly lower voltage (70 ns, with an MCU nWR pulse of slightly under 80 ns at full Vcc) that it could have been due to some other condition. At the time I was interested in making the circuit behave in a specific way, unrelated to the faulty operation during decay of Vcc. I was unable to detect this occurrence, which had piqued my interest, once I removed the relatively large cap from the Vcc rail.

That doesn't prove anything except, perhaps, that the MCU doesn't stop when it's asserted at a time when Vcc is out of specified limits.

RE