You're absolutely right. There is no guarantee. There's not even a good reason to believe that the manufacturer has faithfully replicated the circuitry in the licensed original Intel design. Unless the manufacturer provides specific information about this, you're on your own ... sadly ... and likely to remain so. I did observe similar run-on with DALLAS, PHILIPS, and INTEL MCU's. I'm not sure what, exactly, that implies, since their reset logic may be different.


Quite frankly, I don't know that we can get solid "proof" of what's going on inside the MCU. However, it IS possible to get significantly persuasive evidence. It's not easy or likely to happen overnight, but with considerable thought, and some concerted effort, you can gain insight into what the chip's behavior is under controlled circumstances, including those under which the, in your case, "lost flash" occurs.

This is quite far removed from the "Has LINUX had its chips" topic, though, and I believe, if you, Erik, are willing to have a discussion, rather than a "food fight", it can be done, in an MCU-specific context, as well as a general one that's applicable to pretty much all 805x-core MCU's, though there will undoubtedly be some exceptions, but I believe it would be appropriate to do it in a separate thread.

Since I've finally, after many years, managed to assume a retired status, I have some time available, and have the hardware with which to do much of the "heavy lifting" in the sense of building the necessary hardware to perform rigorous testing over long time and many repetitions. Keep in mind, though, that this will wander into several sensitive areas, including the application of "reset circuitry", power supply bypass, and raw power supply, about which many people have expressed opinion. Oscillator startup is probably also a factor.


There's no question that this line of reasoning would lead you to the conclusion you reached. However, in my own rather cursory testing, over long periods and with a few different MCU's, I found that my BBRAM was clobbered despite the assertion of RESET during Vcc decay, as there was a supervisor in the circuit. Now, this doesn't prove anything about your particular experience, but it does give me pause, as I observed activity on ALE, nRD, nPS, and nWR during the interval when RESET was active. This was, in my case, complicated by the fact that the supervisor, the BBRAM, and the MCU all had different ideas about where a "brownout" began and ended. I'm persuaded that if they all agreed, the problem might have been averted, but that's just a guess.



Well, I'm not sure that the problem's as severe as you suggest, but I do agree that it is potentially cost-sensitive. However, in this particular discussion, it's not about designing a cost effective solution. It's about finding out what the nature of the underlying problem actually is. What I'd point out is that the manufacturers may or may not have done this sort of thing already, but putting the information in front of potential users probably doesn't help them. It's much easier for them to suggest using one or another supervisor, particularly if it's one of theirs.

It may take some time for me to gather up the resources with which to perform thorough automated testing and documentation of the result, particularly as my wife will be coming around to make me go outside and work in the garden. I do however have the resources with which to perform automatic testing over a lengthy period and with which to record the result. I'd find that interesting, if only to show that the various manufacturers have been unkind in not doing this or at least releasing the results.

RE