Kai, this has been repeated ad nauseum by you and others. It is only partially true. What seems common to the observations is that there is a problem that occurs from time to time with the "old-standard" RC reset. I won't quibble about that. However, jumping from that observation to the conclusion that a supervisor is the "fix" for it is not so sound.

I won't deny that changing the circuit can have various effects, not exclusive of altering the likelihood of internal FLASH corruption.

However, not one description of any rigorous study, or even casual observation of any MCU signals has been offered to suggest that RESET or a supervisor is, in any way involved.

There are numeorus non-reset-dependent factors that are involved, not the least of which is the behavior of Vcc. As you know, I'm concerned about the relationship between Vcc rise time, oscillator startup, and various RESET behaviors.

You probably also remember that I've pointed out that the likelihood of FLASH corruption is much greated during the power-off transient than during the power-on transient. You've also seen, I imagine, my description of unanticipated behavior of the nWR signal, among others, during asserted RESET once power falls below 4.2 volts.

Stories like, "We've received no complaints about our circuit since we started using a supervisor," while interesting, are not conclusive evidence that the "problem" was repaired by the installation of the supervisor IC. Changing the power source, or a capacitor value might well have achieved the same observation. Until there's been rigorous examination of literally millions of resets on tens of thousands of identical circuits, no reasonable conclusion can be reached. Until someone performs at least ONE rigorous test, not just a, "Well,it works now" observation, no facts are at hand.

I've offered to run a 1000-hour automated test involving various 805x's provided that they had a few things in common with the ones I occasionally use, namely the DIL-40 and PLCC-44 package. (The ones I work with most have been in operaton for over 25 years with no such problems, despite the fact that they use the published 10 uF cap with an 8.2 K-ohm pulldown, but have, on occasion "upgraded" a couple of the installations with faster flash-based MCU's. The original MCUs have no FLASH, so it's not likely there'll be FLASH corruption. RESET has always worked properly, though.) I don't use other packages, so far, as I have no motivation to do so. I asked people to suggest specific MCU's that have had proven instances of this FLASH-corruption problem. My own experience has been limited to external BBRAM corruption. One of these days,

One fellow provided a list, from various manufacturers, but over half of them were no longer manufactured, so asking the chip maker for samples would have been a lost cause.

Everyone seems to agree that there are, indeed, occasional and quite unpredictable instances of FLASH corruption. One thing that I find interesting is that these seem to be concentrated among ATMEL MCU's. I've had no reports from anyone on this forum that had proven corruption of internal FLASH. What's more, nobody has ever gone to the trouble of reporting that they examined specific signals, as with an oscilloscope or logic analyzer, to pursue this problem. People seem to enjoy making simple assumptions, rather than doing the exhaustive and tedious work.

RE