You don't like to read the question, do you, Erik? Instead you guess as to what's there. If it were already answered, I'd not be after an answer, ... one that YOU, Erik, clearly can't provide. You spew the same sorts of rubbish that, for over a decade, has been flowing from the manufacturers, who clearly haven't bothered with this very serious problem. Instead, they've "passed the buck" to the makers of these band-aid chips that are, apparently, also adversely affected by the slow risetimes and noise on Vcc that foul up the MCU, though perhaps not as frequently so.

I've met the guys from some of the mfg's and they're no smarter than you and I. Believe me, that gives me pause. From what I can tell, all they've done is a superficial trial, the results of which they've not published. It's like writing 'C' code, then assuming that, if it compiles, it's good, so ship it.

The first thing I'm trying to do is to establish whether the "problem" that these "RESET IC'S" address is the reset problem, or the FLASH corruption problem.

What has me running down this road is that there is really only one thing that can corrupt the FLASH content, and that's the coincidence of a functional supervoltage charge-pump and a runaway MCU core. What interests me at the moment is the relationship between the runaway MCU core and the rise time of Vcc.

I see at least two potential problems. (1) The rise time of Vcc is increased by capacitance on the board in cases where the supply current is small, if theoretically adequate, regardless of whether the supply is a switcher or a linear. (2) The rise effect of this slow rise time is affected by ripple, whether from a low-power linear or a noisy switcher. The reason I'm interested in this is because these two issues can foul up not only the MCU but also the reset IC, and particularly so in the case of the switcher-fed system.

One reason I'm interested in the separate problem of flash corruption and faulty reset is that the MAXIM DS89C4x0's had a flash corruption problem despite the fact that the reset IC is built into their MCU.

The applications that interest me most at the moment are those in which I can drop-in substitute the Maxim part for the older Intel/AMD/Signetics part, and take advantage of the fact that it has internal code space the original didn't have and, when necessary, take advantage of the clock multiplier as well. I've not yet attempted to use the internal code space, as the jury's still out on whether it's sufficiently reliable.

I've recently examined a number of commercial applications of Philips' parts, and find that none of the ones I examined that operated in 803x mode used reset IC's. Actually, I've never seen an 805x circuit in a commercial application that used a reset IC. The reason, probably, is that these are either 803x app's, or ROM-based, so FLASH corruption is not an issue. That, also, points in the direction of this being a FLASH issue, and not a RESET issue.

I'm still wondering whether anybody here on this forum has ever actually thoroughly compared the results from a circuit with and an identical circuit without the reset IC?

I'm still wondering how to isolate the FLASH problem from the reset problem. I'm wondering how to control the circuit such that, when one's done with the investigation, one will KNOW whether the problem is in the power supply, the MCU, or the reset circuit.

Yes, the circuit I'm considering is definitely going around the hard way, but I'm not designing for production. I'm trying to find out what the problem really is. For that I need a test environment. I can use a signal generator to produce the desired rise time on Vcc, and I can use another in sync with it, to produce the appropriate reset pulse. I can use some simple logic to trigger a logic analyzer to accumulate the relevant information when there's an anomaly that majority logic can detect and forward it to a PC. Whether I'm willing to go to all that trouble is another issue.

Apparently it's been too much trouble for YOU, Erik, and others, to question the marketing literature.

RE