Erik,

I believe you've misinterpreted my request for more information about your observations as a demand for proof. It is not!

What I want is to know how you determined that the problem you were having, in each case you've dealt with, was found to be a RESET-related (in your case nRESET-related, which I believe to be preferable) problem. It seems to me that your conclusion was based on assumptions which, in turn, were based on the published and widely-accepted notion that the 805x MCU sometimes has RESET issues.

I don't deny that there are RESET issues with any device that relies on a changing Vcc to tell it when it's in RESET. The path from that to the flash corruption matter is a bit twisted, but probably justified.

The logic in your conclusion regarding the pig-foot extract is not sound. The large number of individuals involved seem persuasive, but are not, in reality, convincing, because there's no link that's been shown to tie the two events together. Just because event A preceded event B doesn't make event A a cause of B and event B an effect of A. Likewise, when dozens of people have problems that they perceive, for some up-to-now-unstated reason, as being RESET-related, subsequently guess that some change in the reset circuitry is warranted, implement some such change, and then find a much less frequent occurrence of the problem they believe they've identified, it's easy for them to declare the problem as being fixed. There's no logical basis for that conclusion. It's tempting to deduce that since the original symptom is no longer easily apparent, it's been alleviated. It may even be true, but there's no logical basis for that conclusion.

Had observations been made, pointing to the cause of the fault, and observations subsequent to the "repair" shown that the cause had been eliminated, the conclusion that the effect, i.e. the perceived reset fault, was repaired because its cause had been removed, would be warranted.

That, of course, is an oversimplification. Problems such as this are often caused by multiple factors. It's the interaction of those factors that cause the problem. The job of the engineer is to determine what those factors are and in what way they interact (cause) in order to create the perceived problem (effect).

There's another approach to this sort of problem. If one samples a large number of identically manufactured circuits one can establish the failure rate. For every class of product, there's a limit on how large a failure rate can be tolerated. If the product in question is found, either by a brief repetetive test of a large number of samples or by a long and exhaustive test of a smaller sample, to fall within the acceptable range, one can be persuaded that it is acceptable, at least for that particular test parameter. No circuit is perfect. If it fails twice or three times in a million power-cycles, that's probably acceptable. If it fails twice or three times in a thousand, well, that's probably less so.

I don't know how much testing the manufacturers have done in order to establish what they consider "acceptable" as far as the function of their MCU's and their respective RESET function is. I don't think they state that anywhere. It would be interesting to know what their criteria are. It would be useful to know what the Vcc rise time and fall time in their test of RESET is. Information about that is quite sketchy.

I'm suspicious of the relationship between RESET and the rise and fall of Vcc because of what I've observed. The MCU shouldn't do anything while its RESET line, positive- or negative-going is active. The fact that I stumbled on a repeatable instance in which it does something, and, in fact, does something potentially damaging, is what brought me to the position I now occupy. The fact that I feel justified in my opinion is based on physical observations I have made and not just on acquired opinions derived from app-notes and scuttlebut in some unknown ratio. These were made in the presence of a supervisor IC, yet the problem I preceived was not alleviated.

As I've said before, one of these days, demands on my time allowing, I'll set up and perform a long-term test to make precise observations of the logic levels and voltages involved, probably starting with variations in rise and fall times of Vcc. Since nobody's paying for this test, at least not yet, I'm going to have to wait until time and resources are available for such a test. I'm not sure, yet, what the goals of this test will be, and that prevents me from proceeding.

It's easy to blurt out, as several individuals have often done, that the supervisor is the ultimate "fix" for any and all reset faults. While I accept that a supervisor may be helpful in mitigating the occurrence of certain effects of Vcc variation, I've seen no evidence of how much it helps. Until it's quantified in some way, e.g. failure rate under identical conditions of Vcc and Gnd, identical MCU, identical everything else, vs failure rate with a supervisor and no other circuit changes, it won't be possible to make a reasonable choice as to the relative value of such a device. In the end, it's an economic decision and has to be left to the managers.

At this moment in time, I'm of the opinion that, with a sufficiently fast rise and fall time on Vcc, the supervisor won't make a lot of difference during the power-up and power-down transient. It can be very helpful under brownout conditions. I believe that, if the slew rate both rising and falling, on Vcc is sufficiently low, the supervisor will suffer from the same problem that afflicts the MCU. That is just a guess ... so far.

I find the published material regarding supervisors and FLASH corruption to be somewhat unhelpful. First of all, there's no firm link between the supervisor's action and the corruption of internal FLASH, though it does indicate that the manufacturers have taken a look at and acknowledged it. Secondly, statistical information about the frequency of occurrence of such a fault is not available. Thirdly, the relative effect of using a supervisor has not been statistically quantified, so we really don't know what we're buying.

BTW, I find your method of loading a FLASH writer and subsequently overwriting it when once it's loaded quite interesting. That certainly will make more difficult for the potentially runaway MCU core to write to its FLASH.

RE