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?
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
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.
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.
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/)
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.
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.
