Kai,

I think you're getting tangled up in the fact they (Intel) attempted to avoid being circular, and, therefore, self-contradictory, in their writing. I agree, however, that their statement of what I've interpreted as a requirement, does seem less forceful than it is in the Philips document.

The reason I'm persuaded as I am with respect to the importance of Vcc rise time is because of my observations, made not because I had to "fix" a problem in a hurry, but because I wanted to solve one of long standing.

I've never put a reset IC of any sort in any of my client applications, nor have I ever seen one in a pass-produced commercial application. Despite all that, I've not encountered a "reset" problem in 805x context until I started investigating this one. Judging from the price of these RESET/Supervisor chips, I'm persuaded that they're used in considerable volume. I agree, that there's a reason, though I suspect it's possible that poorly informed designers have been stampeded into it by an inherently and fundamentally flawed MCU design. It wouldn't be the first time that one had to deal with terrible hardware with a great instruction set.

So far, I've seen few descriptions of a "reset" problem with 805x that indicate than anyone has attempted to determine what the problem really was. Your description is, in fact, the only one that I've seen that didn't seem to be a response to a phone complaint, rather than rigorous investigation.

I am curious, however, why it appears that with slow decay on Vcc, 805x's (and I'm not for a moment suggesting it couldn't happen with absolutely any MCU) the content of external BBRAM frequently seems to become corrupted. This suggests that the MCU is doing something despite the fact that RESET is asserted, as I've seen this in cases where a MAX1232 was installed, as I previously stated.

The inclusion of large amounts of on-board decoupling cap's, in an application powered by a "weak" raw input supply, while helping with the risk of "brownout," would easily drive this sort of environment into a worst-case scenario. I suspect that it's difficult to discern whether a power-up failure has occurred because of a poor reset circuit or whether it is caused by an inherited failure from the previous power-down transient, in a case where that has effected changes in the program space.

Once I receive some information about what precise behaviors people have actually observed in the context of "reset failure" I can set up a test environment based on those observations.

Unfortunately, I can't set up qualitative conditions. I have to have precise observational data that has been measured and can be replicated. That may explain why everything dealing with this issue in the technical literature smacks of shrugs and handwaves.

RE