While there may be evidence somewhere, these app notes don't really present any evidence. They just make claims and then throw out a few red-herrings to throw us off the trail. The Atmel piece, http://www.atmel.com/dyn/resou...oc4183.pdf
is a good example.

It's true that a runaway cpu could end up entering a program-store-write routine in an abnormal way, that fact in no way applies to the question I presented. It's also true that, if a CPU runs away due to improper reset, it may do that. It's also true that, in the case of a really slow power-on, the inner workings, including the flash-write charge-pump, could be activated before the CPU control is stabile.

Most of the time, however, a runaway program is due to faulty programming and not due to power-on or power-off transient effects. That's what watchdogs are supposed to manage. Motorola has had watchdogs in their MCU's since the early-mid '80's. All you have to do is "kick the dog" from time to time in order to keep him from timing out. It's not a perfect solution, but it seriously improves the odds.

My question, as stated was,

Now, I've commented a time or two on the effects I've observed, not in runaway program but in failure to operate, in some MCU's. These have consistently been in cases where the power supply was a switcher, or where the power supply was a weak one, i.e, a wall-wart or other <1/2-ampere raw supply. When I've used a hefty linear supply, one with >>20 ampere capacity, it's worked fine, always, without a hitch. When I used a spare supply for my DS3 mux, which has 7/16" screw lugs for the 50-ampere 5-volt supply it fails, as it does with every switcher I've tried. There's a message in there somewhere ...

I'm not convinced that the "supervisors" and other reset aids help very much, aside from increasing cost. That's what I'd like someone to show me, at least through a statistical reliability report or the like. ... someting rigorous and not from the marketing department.

I'm currently persuaded that, if one took the time and trouble to build such a thing, a Vcc switch to the MCU in conjunction with a stabile crystal oscillator (not the one built into the chip) that holds the MCU in reset for 2048 counts of the oscillator after a rapidly-rising (~5-10 microseconds ?) Vcc that didn't even start until long after all the cap's in the circuit were charged, the reset issue would look different.

I'm not convinced that the flash corruption issue is one of improper or inadequate reset alone.

Has anyone rigorously tested the reset function in two circuits identical except for the presence in one of them of a reset IC? Somewhere between 1000 and 100000 repetitions of the power-on, reset, and power-down sequence would be adequate, for statistical reporting purposes.

This would probably require a one- or two-minute-long execution of a wide range of instructions and memory access types all as part of a power-on-self-test, the end-effect of which would be a dump of all internal resources to a port where the majority logic would compare the three, keeping record of any inconsistencies.

Frankly, I think this reset problem is a fundamental design flaw with which I'd never let even an undergraduate student "get by." How this could be left unremedied by industry professionals for a time approaching three decades is a mystery to me.

RE