Brown-Out Reset - An Update

Summary: More info about using brown-out reset circuits.

Recently, I recommended against (http://www.embedded.com/electronics-blogs/break-points/4430317/Brown-Out-Reset) using the brown-out reset (BOR) circuit found on many MCUs. My argument was that BOR's often have a wide tolerance range, which means one could give up nearly all of a coin cell's capacity. For instance, some are rated as triggering a reset at some nominal voltage, but the tolerance bands are 2.05 to 2.35 volts. Worst case design means assuming it'll fire at 2.35, which, with a decent load on the battery, means it may initiate a reset when there's 90% or more of the battery's capacity left.

I suggested, instead, waking up once in a while and reading Vdd with an A/D, and did write that the load during this measurement must reflect the real, expected load while awake. I still think this is good advice. However, in some situations this solution might be impossible to implement.

The nice folks at Microchip called to explain some of the scenarios they see their customers experiencing. One I hadn't considered is writing to flash memory. This can suck some serious coulombs; on their PIC18LF46K22 writes can take 10 mA for around 6 ms/block (not an unusual number; TI's MSP430F2013 needs 7 mA during flash erase). As the battery is slowly depleted its internal resistance may be low enough to run code, but so high that Vdd will drop below the minimum allowed during the flash write. The result: who knows? With Vdd below the minimum the CPU needs, any internal register, like the program counter, could become corrupt.

Why not use the A/D to check Vdd during the flash write? Well, on some MCUs that's quite impossible, since all instruction execution is suspended during the write.

Perhaps it makes sense to turn the BOR on only when the processor is not sleeping, and let it issue a reset when writing to flash if the battery just isn't able to power the system properly. However, if the BOR goes off at 2.35 volts, and flash writes eat 10 mA, then, assuming no other significant loads during the write, the BOR will signal battery failure when around 160 mAh have been consumed. That is, about 30% of the battery's capacity will be wasted.

Newer parts, though, have better specs. Microchip's PIC16LF170X series spec a very tight range of BOR voltages. The numbers are a function of temperature and selected mode, so are too complicated to list here. However, the BOR uncertainty is generally better than 0.1 V, and is very well documented. In this case enabling BOR during awake times does make sense.

(You may have seen my discussion of the meaning of "typical" recently here: http://www.embedded.com/electronics-blogs/break-points/4430579/Typically-Typical-Take-Two. Interestingly, and unusually, the PIC16LF170X datasheets explain the meaning of max, min and typ for each parameter. For instance, on a graph for the BOR voltage max is listed as "typ+3s," which of course means typical is max-3s. This is the first time I have ever seen these important parameters defined. Bravo Microchip!)

Some systems need more than 10 mA when awake; wireless comm can eat tens of mA. In that case turning on the communications logic will drop Vdd more than a flash write does. If comm is a requirement, then using the A/D to measure the battery's condition with the comm on will also ensure flash writes will be safe.

Do remember, though, that the cutoff point is when the loaded Vdd is approaching the MCU's rated minimum allowable value. The battery's internal resistance will be in the many tens to hundreds of ohms. When the load is removed the voltage will be much higher; measuring it then will give no useful information.

Absent any sort of BOR monitoring, on any MCU a flash write can drop Vdd enough to make the system run mad, even overwriting code space and bricking the device.

The bottom line is that on many MCUs you can't use the A/D to monitor Vdd during flash writes unless there's some way to simulate the expected load. As always, do a careful, worst case, engineering analysis.

Published June 3, 2014