Recently, I recommended against using the brown-out reset (BOR) circuit found on many MCUs. My argument wasthat BOR’s often have a wide tolerance range, which means one could give upnearly all of a coin cell’s capacity. For instance, some are rated astriggering a reset at some nominal voltage, but the tolerance bands are 2.05 to2.35 volts. Worst case design means assuming it’ll fire at 2.35, which, with adecent load on the battery, means it may initiate a reset when there’s 90% ormore of the battery’s capacity left.
Further, some BOR circuits use quite a bit of juice, in somecases too much to support years of (mostly sleeping) operation off a coin cell.
I suggested, instead, waking up once in a while and readingVdd with an A/D, and did write that the load during this measurement mustreflect 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 thescenarios they see their customers experiencing. One I hadn’t considered iswriting to flash memory. This can suck some serious coulombs; on theirPIC18LF46K22 writes can take 10 mA for around 6 ms/block (not an unusualnumber; TI’s MSP430F2013 needs 7 mA during flash erase). As the battery isslowly depleted its internal resistance may be low enough to run code, but sohigh that Vdd will drop below the minimum allowed during the flash write. Theresult: who knows? With Vdd below the minimum the CPU needs, any internalregister, 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 issuspended during the write.
Perhaps it makes sense to turn the BOR on only when theprocessor is not sleeping, and let it issue a reset when writing to flash ifthe battery just isn’t able to power the system properly. However, if the BORgoes off at 2.35 volts, and flash writes eat 10 mA, then, assuming no othersignificant loads during the write, the BOR will signal battery failure whenaround 160 mAh have been consumed. That is, about 30% of the battery’s capacitywill be wasted.
Newer parts, though, have better specs. Microchip’sPIC16LF170X series spec a very tight range of BOR voltages. The numbers are afunction 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 welldocumented. In this case enabling BOR during awake times does make sense.
Interestingly, and unusually, the PIC16LF170X datasheetsexplain the meaning of max, min and typ for each parameter. For instance, on agraph for the BOR voltage max is listed as “typ+3σ,” which of course meanstypical is max-3σ (see my discussion of the meaning of “typical” ). This is the first time I have ever seen these importantparameters defined. Bravo Microchip!
Some systems need more than 10 mA when awake; wireless commcan eat tens of mA. In that case turning on the communications logic will dropVdd more than a flash write does. If comm is a requirement, then using the A/Dto measure the battery’s condition with the comm on will also Ensure flashwrites will be safe.
Do remember, though, that the cutoff point is when the loaded Vdd is approaching the MCU’s rated minimum allowablevalue. The battery’s internal resistance will be in the many tens to hundredsof ohms. When the load is removed the voltage will be much higher; measuring itthen will give no useful information.
Absent any sort of BOR monitoring, on any MCU a flash write candrop Vdd enough to make the system run mad, even overwriting code space and brickingthe device.
The bottom line is that on many MCUs you can’t use the A/Dto monitor Vdd during flash writes unless there’s some way to simulate theexpected load. As always, do a careful, worst case, engineering analysis.