When the power supply on a microcontroller falls under a certain threshold, a brown-out conditions occurs and RAM may get corrupted. Provided that every power down sequence of the circuit can mean a potential brown-out condition, I always enable the brown-out detection reset mechanism when working with microcontrollers.

Are there are any situations in which it is not recommended to enable the brown-out reset feature?

  • 5
    \$\begingroup\$ Brown-out detectors also may consume current that should be taken into consideration for micropower applications. \$\endgroup\$
    – HL-SDK
    Jul 30, 2014 at 16:09
  • \$\begingroup\$ Given the diverse drawbacks of the BO-detection stated in the answers, consider this as well: Can you proive any custom certainty in your particular case? In certain cases you could i.e. guarantee a sufficient supply or a complete blackout => save the ressources for BOD \$\endgroup\$
    – Mark
    Aug 1, 2014 at 10:00

8 Answers 8


As noted, enabling the brown-out circuit will often increase current consumption. Further, because manufacturers generally want to ensure that the brown-out circuit will trip on any voltage that might be low enough to cause other parts of the chip to function, many parts will be able to operate at a lower voltage with brown-out disabled. For example, a controller might work most of the time down to 1.5 volts at room temperature but, under certain stressful conditions (such as elevated temperature) could malfunction at 1.99 volts. To ensure that the device would reset under any condition where a malfunction might occur, the brown out circuit might be designed to trip at 2.1 volts +/- 100mV.

If a device with such a controller were powered from two alkaline AA batteries, enabling the brownout circuit may cause the device to become unusable with a battery voltage of 1.1 volts per cell, and would likely cause it to cease operation by the time the voltage reached 1.05 volts per cell. Disabling the brownout circuit would likely extend operation down to at least 0.9 volts per cell, and possibly even 0.75 volts per cell. If no plausible malfunction that could occur at low voltage could cause any harm beyond increased drain on junk batteries, disabling the brownout circuit would be a simple way of improving battery life, even if it didn't reduce the current draw from usable batteries.


Everything has tolerances, so the brown out reset level must be set somewhat above the minimum level at which the chip is guaranteed to function properly.

Hence the brown out might kick in well before the chip would malfunction. So you have to ask yourself, for this region, where the chip might function OK but you can't be sure, would you choose

  • to let the chip work and hope the best of it (it might work!), or
  • to let the chip be reset (and kept in reset) by the brown-out circuit.

If the cost of malfunctioning is not much higher than the cost of not functioning at all the first option is to be preferred. Think of the ping-feature on an airplane 'black box'. By all means, let it go on if there is even the slightest chance that it will give a ping!

On the other side, consider the triggering of a bomb or a car airbag. If there is the slightest chance of it going off by accident due to a low power voltage, it should better shut itself off. That of course assumes that shutting of means not igniting!

There are situations where no good choice is available. Consider the infamous first Ariane V rocket launch. The direction control computer(s) malfunctioned (in this case not due to low power). What should it do? Going on most probably means steering in the wrong direction, but quitting means not steering at all, which has the same result. Neither is a nice prospect for the people in the control bunker that the rocket might wander into :(

As Ross comments, a backup is of course a good idea for a mission-ciritical system. But that shifts the design problem to that backup. What if that fails? (In practice there are often 3, active all the time, using a majority vote.) In the case of the Ariane 5 both primary and backup computers failed (Though not through their own fault, but that is another story.) What happened next was that some other system (maybe it was even a human in the control room) detected that everything was out of control and triggered the self-destruct. Better have the rocket explode in the air and fall down in small pieces in the sea that have it continue its flight in one piece in some random direction.

  • \$\begingroup\$ For the rocket situation, the best solution is to have a backup computer which will take over in case the first fails, and have the first shut down, right?? \$\endgroup\$
    – Ross Aiken
    Jul 31, 2014 at 15:28
  • \$\begingroup\$ some text added \$\endgroup\$ Jul 31, 2014 at 15:32
  • \$\begingroup\$ Actually the Ariane 5 story is much more complicated, and error handling was part of the reason for the failure. esamultimedia.esa.int/docs/esa-x-1819eng.pdf \$\endgroup\$
    – starblue
    Jul 31, 2014 at 16:41
  • 1
    \$\begingroup\$ No, error handling was not the cause. It was the use of a proven system (it had flown on Ariane 4) with data outside its original specifications without testing it with the new data. (Such tests were originally planned, but later scrapped in a cost reduction program ;) \$\endgroup\$ Jul 31, 2014 at 17:13

You may choose to disable the BOR if there is a bug where the BOR does not work correctly.

Module: Voltage Regulator

Device may not exit BOR state if a BOR event occurs.

See issue 15 in PIC32MX534/564/664/764 Family Silicon Errata and Data Sheet Clarification.

  • 8
    \$\begingroup\$ Ouch. Which part does this lovely errata belong to? \$\endgroup\$ Jul 30, 2014 at 14:00
  • 1
    \$\begingroup\$ How does something like that make it into production? \$\endgroup\$
    – Matt Young
    Jul 30, 2014 at 15:37
  • 1
    \$\begingroup\$ That's hilarious. And by hilarious I mean almost criminal. \$\endgroup\$ Jul 30, 2014 at 15:39
  • 1
    \$\begingroup\$ The particular device was the PIC32MX664F and only some silicon revisions. Most of the time it would exit BOR normally only once out of every 20 or so times it would not. \$\endgroup\$
    – mjcopple
    Jul 30, 2014 at 15:50
  • \$\begingroup\$ @Matt Young: Because most uses of these PIC microcontrollers, BOR only exists to shut it down before the silicone starts executing random instructions when you pull the plug. If you have a reflash routine in ROM, it's possible for it to attempt to flash itself w/ garbage if BOR didn't exist. \$\endgroup\$
    – Joshua
    Sep 11, 2015 at 17:54

If you don't care about reset (for example, the user can be trusted to turn it off and on again if things don't work perfectly, and no damage is possible) and power consumption is important, turning it off can save some microamperes. (or if you do care, you can use a better external circuit than the so-so one that is built in).

If the internal BOR is inadequate for the task (the tolerances may not be appropriate, for example) then may as well turn it off and use something external.

An interesting requirement for some purposes is that you need to know the maximum voltage below which things like EEPROMs are guaranteed not to work, so that the BOR can inhibit operation and guarantee no corruption. That might be a bit subtle for some built-in BOR circuits.


If you want to reduce the current consumption in sleep mode. E.g. for the ATmega328P you can reduce it by a 17uA by turning BOD off. Turn everything else off while sleeping and the chip consumes a tiny 1.8uA!

(Source: http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/)

  • \$\begingroup\$ In my tests, the ATmega328P consumes well below 1 µA in power-down sleep mode, when BOD (and WDT) is disabled. For example, I measured 0.13 µA, or so, at VCC=3.3V - which matches the figures specified in its manual (I_CC_typ=0.1 µA, Section 30.2.4 ATmega328P DC Characteristics - Current Consumption, page 325). \$\endgroup\$ Jun 12, 2022 at 9:03

There are situations where you might like to use an external, custom-built brown-out circuit instead.

There are microcontrollers where the resolution of brown-ot levels is quite small.

Let's assume you work with a µc where the two highest brown-out levels are 4.3 V and 2.7 V (common in case of AVR). You have determined that at the frequencies you use, 2.7 V is unsafe. However, 4.3 V would be too high, as it would limit the length of running time after a power fail.

I often have to work with devices which can frequently lose connection to the external power supply and then have to survive on capacitors or batteries. Having a brown-out level of 4.3 V would lead to the device switching off too soon. 2.7 would lead to data corruption. However, if for example, 3.5 V would be a safe brown-out level, you might want to make an external brown-out circuit which works by pulling the reset line of your microcontroller. In this case the internal brown-out circuit is of no use and can be disabled.

In case you have more processors in the same system, it makes sense to use a single external reset controller for all of them. In this case, disabling the individual brown-out detectors in the processors is not only useful for the marginal advantage of saving some power, but is required to avoid the situation where some processors are in reset and others are still running.

  • 1
    \$\begingroup\$ I know you're not picking on AVR, but I feel compelled to mention that 1) different AVR lines have different BOR thresholds, and 2) AVRs make the reset signal externally visible on nRESET so if you're very careful you can use one as a reset controller. \$\endgroup\$ Jul 31, 2014 at 17:38

It's recommended to turn off brown-out detection (of an MCU) if it consumes too much energy for your application.

For example, with the ATmega328P, the MCU typically only consumes 0.1 µA during power-down sleep (where the contents of the RAM/registers is still conserved), but its power consumption increases to 17 µA when BOD is enabled.

Depending on the type of battery this might be higher than self-discharge effects and thus worthwhile to avoid. I'm not an expert on battery chemistry, but e.g. 10 µA self-discharge equivalent seems to be plausible with alkaline batteries.

When the MCU's BOD is switched off you can still detect brown-out externally.

For example, you can use an LDO voltage regulator with enable pin feature such as the RT9080 and combine it with a push/pull voltage detector (PMIC supervisor) such as the MCP112 or TC54.

In comparison with the ATmega328P internal BOD, the above voltage detectors are more efficient (e.g. I_DD_typ=1µA and I_DD_max<4µA).

Alternatively, with the ATmega328P there is also a middle ground. That means it's possible to just disable the BOD during power-down sleep mode.

This trades off wake-up latency for lower power usage during sleep. (i.e. 60 µs or so additional wake-up overhead).

Using it like this still has reasonable safety properties because the MCU automatically re-enables BOD during wake up.

Also, you might prefer to use an external BOD that simply switches off the MCU, because you want to protect your battery from deep discharge, anyway.

For example, the BOD of the ATmega328P puts the MCU into reset mode when it detects a brown out condition. And there it consumes 1 mA or so such that your battery continues being discharged at that rate.

Also, all configured pull-up resistors are disabled during reset, such that you have to connect all unused pins to external pull-up/pull-down resistors to avoid additional current consumption because of floating pins.


We had to toggle the VBOR off and back on during one part of startup due to a bug in the silicon on the microcontrollers we were using. Charging up the caps on the voltage pump would drain the device to momentarily just above minimums and the VBOR kept tripping. So we turned off the VBOR during powerup and turned it on about 10ms later.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.