Resetting a microcontroller by powering it down - What could possibly go wrong ?

[chris_leyson]

Quite a lot if you're not careful. So I've got this 5V microcontroller with a 1.8V core supplied by an internal linear regulator, nothing new there and it could also apply to a 3V3 part with a low voltage core. The scenario goes something like this as VDD drops.

1. Switch of power to micro
2. VDD drops at some dV/dt depending on load
3. On chip brownout detect and reset doesn't work because supply dV/dt doesn't meet spec
4. Firmware keeps on running because internal reset doesn't work, guaranteed by design. See 3
5. I/O input thresholds are changing as VDD drops. Is 1/3 2/3 VDD threshold still applicable ?
6. Firmware does something unexpected possibly because an I/O pin has seen a change of state
7. Oscillator stops, core stops at some unkown state
8. I/O drive finally fails because VDD has droped to 20%
9. Now the microcontroller is finally sleeping.

It's a guaranteed recipe for disaster. I/O ports and level translation between the I/O and core is not defined outside of recommended supply operating conditions so anything can happen. At some point in time it's all going to become nondeterminisic and that point in time is highly variable due to the supply dV/dt. Moral of the story, should have blipped the reset pin.

[Siwastaja]

Is there an actual part that measures dV/dt for the brownout detector? Or is that just speculation?

Obviously, a proper brownout detector looks at the absolute voltage. This is easier to implement on silicon, as well; just a reference and a comparator.

(Note not all microcontrollers necessarily use the term "brown-out detector".)

[SiliconWizard]

Is there an actual part that measures dV/dt for the brownout detector? Or is that just speculation?

I don't think I remember a spec on required dV/dt for the brownout detectors or any MCU I've worked with. Not saying there isn't.

But hypothetically, the only possible issue I can see is the case where VDD drops and rises back too fast for the drop to be detected properly by the brownout detector, yet the drop would still cause the MCU to fail in some way. For that to happen the brownout detector would likely have to be particularly slow AND VDD not properly bypassed IMHO. I've never seen that happen, but given that this would likely happen (if ever) only for ultra short drops, that's something you should be able to solve again by properly bypassing VDD.

[retrolefty]

Often a RESET pin doesn't get the love and care it deserve.

Just with avr 328 type chips I've seen where a too short an externally supplied reset signal 'locks up' the chip requiring a powering off to correct. Or try wiring an output pin to the reset pin so one can perform a programmed reset, doesn't work for the same reason.

Also I've seen a voltage overshoot of the reset pin (about 10vdc) partially put the chip into HV programming mode.

Sometimes a errata notes of a MC's datasheet will give hints of such vulnerabilities.

[T3sl4co1l]

BOD and reset generators are notorious for misbehaving at low dV/dt.

I take it these are more speculation than direct observation?  Or, say, you might've confirmed a few of these in some systems, but not all of them simultaneously..?  (That would be pretty hideous, but I'm not discounting the possibility..!)

Regarding the scenario -- there should at least, be few things, persistent or destructive, a browned-out core can do.  Peripherals aren't doing anything, they're subject to the same malfunctions as any other part; SRAM is going down, and always assumed on boot to be trashed; and EEPROM or Flash, even if accessed appropriately, probably don't have enough charge to finish a write or erase cycle.  And even then, they're only likely to corrupt a few points, which could hopefully be detected, but then of course, you do need to implement a validator (CRC or hash, say) to show that the data is as expected at startup.  Preferably in a fixed non-writable location; often some Flash is reserved for bootloader use, and protected by fuses that can't be written from software.  (Of course, again, who knows what checks might fail during brownout conditions.)

It's also effectively an overclock: at low supply, logic gates don't have enough bandwidth to run at full speed, and that's if the clock generator remains active.  So race conditions may corrupt some operations but leave others alone.


Good practice to add a reset generator to the project, just out of habit; they're cheap, small (SOT-23 or less) and better optimized than a digital process trying to fake it with analog circuitry.

RST pins are also notorious for being noise antennas; a bypass cap is a good idea, if you can afford it.  Typically 10nF.  Cases where that might not be feasible: when the pin is used for serial programming (ATTINY I think for example?).

Tim

[ehughes]

The flash in the MSP430F1611 AND MSP4302618 will get corrupted if you do this.   Ran into this about 10 years ago....    The brownout detection needs to be very agressive.

[I wanted a rude username]

Cases where that might not be feasible: when the pin is used for serial programming (ATTINY I think for example?).

Any modern (relative term, I know) AVR with UPDI ... so also the ATmega4809, for example. For programming/debugging you can leave up to (no stronger than) a 10 kOhm pullup connected, but must temporarily remove any capacitor.

[David Hess]

Sometimes you can find an active pull-down on a critical power supply to increase dV/dt when power is lost to minimize the opportunity for improper operation.  But holding a part in reset if possible is a better solution.

Is there an actual part that measures dV/dt for the brownout detector? Or is that just speculation?

Depending on its sophistication, the brownout detector may have minimum dV/dt requirements for proper operation.  This is a pretty common issue whether the datasheet specifies it or not.

Obviously, a proper brownout detector looks at the absolute voltage. This is easier to implement on silicon, as well; just a reference and a comparator.

It is also easy to get wrong because absolute voltages are not.  The supply being monitored has reference noise, ripple, switching noise, etc. which can cause fault positives or false negatives.

[chris_leyson]

Is there an actual part that measures dV/dt for the brownout detector? Or is that just speculation?

It's a real part and the hardware doesn't meet the dV/dt spec for auto reset.

Obviously, a proper brownout detector looks at the absolute voltage.

Same part has built in programmable VDD detect for absolute voltage that works on rising and falling VDD but that doesn't seem to be working either. I'm curious as to why and at what supply voltage a part becomes nondeterministic.

Thanks for all the comments guys, @Tim, good comment on logic bandwidth, I had forgotten about that one. @David Hess, there is plenty of supply ripple as well so potentially that could throw things either way. You can make little tweaks to parts of the supply circuit or change a pull-up resistor on an I/O pin and get different results. It's a good wake up call and it's fixed with a proper hardware reset pulling the reset pin to ground.

[Siwastaja]

It would be really helpful if you referred us to the part number. Working around broken-by-design MCU peripherals is everyday stuff, sometimes including reset circuitry. Knowing beforehand is helpful, if not to avoid using such part, at least being able to cope.

If minimum dV/dt is indeed specified and you are exceeding that spec, then it's easy enough, just use an external BOR IC which does not have such limitation.

[chris_leyson]

Part number is MN101EF50D https://industrial.panasonic.com/ww/products/semiconductors/microcomputers/mn101e/models/MN101EF50D

[exe]

The supply being monitored has reference noise, ripple, switching noise, etc. which can cause fault positives or false negatives.

Shouldn't BOD have some hysteresis for that? Like stm32f103 has 40mV hysteresis (typical).

[David Hess]

The supply being monitored has reference noise, ripple, switching noise, etc. which can cause fault positives or false negatives.

Shouldn't BOD have some hysteresis for that? Like stm32f103 has 40mV hysteresis (typical).

It should but maybe not enough or it was left out.

[cv007]

>6. Firmware does something unexpected possibly because an I/O pin has seen a change of state
>It's a guaranteed recipe for disaster.

> and it's fixed with a proper hardware reset pulling the reset pin to ground.


Your guaranteed disaster recipe is still there, unless you never lose power. Either it was a theoretical problem, or it was an actual problem, now with less frequency. If disasters await you, I doubt its much consolation that it now only occurs once a day/week/month whenever you lose power.

Many mcu's have a way to notify of power loss before you reach bod levels, so if disaster awaits from a power loss then it would probably be a good idea to make use of that feature, or add some external help of some kind.

[thm_w]

Part number is MN101EF50D https://industrial.panasonic.com/ww/products/semiconductors/microcomputers/mn101e/models/MN101EF50D

The datasheet on their site doesn't mention brownout, just "low voltage interrupt".
I'll assume you have a more complete datasheet that actually provides the BOD specs..

[rcbuck]

Good practice to add a reset generator to the project, just out of habit;

I agree with Tim. I use the Microchip MCP120's for this task. It is available in several different VDD trip point voltages.

[SiliconWizard]

Part number is MN101EF50D https://industrial.panasonic.com/ww/products/semiconductors/microcomputers/mn101e/models/MN101EF50D

The datasheet on their site doesn't mention brownout, just "low voltage interrupt".
I'll assume you have a more complete datasheet that actually provides the BOD specs..

Yeah. Apparently you need to register to get more complete documentation. I didn't bother.
But I'm curious to see what the DS really says. As you said, the brief talks about a "low voltage interrupt". Is this what is used here as a brownout? Is there a proper brownout reset circuitry actually, or is it just a detector, linked to an interrupt, and all you can do is software reset the MCU in said interrupt? (I guess not, but I'd really be curious to see the full DS.)

A "proper" brownout reset circuitry basically includes a decent comparator with some hysteresis and a voltage ref. If said comparator is not completely shaky, low dV/dt values shouldn't be a problem (very high ones could be, but they are less of a problem because they shouldn't happen with proper bypassing anyway.) Of course on some MCUs, it could be badly implemented. I've never run into this, but I'm sure that happens.

One thing I've see though is the following, which you should certainly be wary of. On some MCUs, the brownout threshold is configurable (among a few fixed values), on some others, it's just a fixed value. One thing that can happen is that said threshold (whether the fixed value, or the value you set in the configuration if it's configurable) is just too LOW for the frequency at which the MCU core runs in your specific design. Some MCUs have an operating voltage range that depends on the core frequency (and conversely). If the BOR threshold it too low for a given clock frequency, it just won't work properly. When VDD drops, the MCU is likely to go bonkers before the BOR takes action. I've seen that happen, so that's not just theoretical, and certainly something to take a close look at.