My typical MCU application is a relatively small circuit, of no more than, perhaps 80 IC's, or an equivalent programmable circuit. It has an on-off switch and a reset button. In fewer than 10% of the cases, it uses an 805x. Most of the time it uses an MCU with a negative-going reset, e.g. 'HC11, HC05/08. Power is typically provided by a linear supply derived from a 13-volt CT transformer, a diode bridge or two, one or two, or even three capacitors, using 78xx or LM340-type regulators or an equivalent adjustable with or without a pass member. I'm not fond of LDO's, as their frequency response is not what I prefer. Yes, I do generally rely on RC reset, as it seldom causes problems in cases using negative-going reset.


I do recall some of the stories, but don't see how they related to your solution, namely using a supervisor, or why that was necessary, nor do I recall you explaining how you pinned the problem to the reset, when it was clearly an out-of-spec power supply. How did you measure the Vcc behavior? How did you and your colleagues determine that the power supply was subsequently correct? How did you persuade yourselves that the problem you had observed and for which you'd applied a "solution" had now been rectified?


I don't believe a power supply has to be "perfect." It does have to be adequate, though. That means that it has to have sufficient current to raise Vcc at an acceptable rate and allow it to fall at an acceptable rate as well. There are numerous ways of accomplishing this, some complex, some not, but all require that the power supply not rely on the target board having lots of on-board capacitance, as that will slow the dVcc/dt.


I'll accept them when they're presented. Apparently you don't believe there is a "reset problem" though I've seen it brought up again and again. I've never encountered a proven "reset problem" in my own work, though I have seen a problem apparently associated with seemingly incorrect dVcc/dt, probably resulting from excessive on-board capacitance on Vcc. Only after starting to investigate the problem did I encounter what I thought might be a reset issue, in the form of the BBRAM corruption.