There’s a war raging about super-ultra-extremely-insanely-low power microcontrollers. Vendors claim their parts will operate on the just a subjunctive promise of a photon’s worth of energy. Some pledge 20 years of operation on a single coin cell.But there is a lot of fairy dust in these claims.
First, despite lots of marketing blather to the contrary, to my knowledge all of the 32 bit devices are completely out of the picture when it comes to these extremely-low power levels.
Second, the low-power MCU’s do offer incredibly-low power options. Truly astonishing. But one must look at system-wide issues. For instance, that two decade dream assumes the processor will be in a deep sleep mode most (like 99.9% ) of the time, because in deep sleep modes these parts consume just tens of nanoamps. Applications that require a usually-alert CPU will kill the battery much faster.
Then there’s the battery. The common CR2032 is usually referenced. Panasonic’s version is good for 200 mA/hrs with a 100 Kohm load. That’s 30 microamps, enough to run some of these MCUs at a reduced frequency, generally with various features and peripherals disabled. If the processor is awake, 200 mA-hours at 30 microamps is less than a year of operation. And by that time the battery will be down to 2 volts, so the system had better be designed to work at that level.
But there are plenty of other issues. The microcontroller doesn’t live in a vacuum; it’s part of the system. Other components draw power, and it’s the design engineer’s job to evaluate those drains. Some may be surprising.
I have a lot of evaluation boards here; many are designed to show off the long-battery-life aspects of a particular processor. It’s interesting to examine the designs.
I put one of the boards under a microscope and looked at some of the ancillary parts. There’s a 22 uF decoupling capacitor. No real surprise there. It appears to be one of those nice Kemet polymer tantalums designed for high-density SMT applications.
The datasheet pegs the cap’s internal leakage at 22 uA. That means the capacitor draws a thousand times more power than the dozing CPU. In fact, the cap alone will drain the battery in under a year (typical values, which are undocumented, are probably better, but who designs for anything another other than worst case? ).
A capacitor has parasitics, and in simplified form looks like this:
Usually the ESR (equivalent series resistance) is pretty low; for caps that are not wound ESL, too, is low. One would hope that Rleak would be infinity, but for the parts we usually use on power and ground that’s just not the case. Some datasheets proudly proclaim Rleak values of 50 million ohms, which sounds great. But at 3 volts that’s much more of a load on the battery than the sleeping MCU.
Leakage is often specified in ohm-Farads, or megohm-microfarads. Many of AVX’s offerings of ceramic MLCC parts are specified at 1000 ohm-Farads. A 22 uF part is therefore about 50 Mohm, completely out of bounds for decades-long power from a small battery.
Also note that dielectrics can be very sensitive to temperature. Going from 20C to 80C on some devices will increase leakage by an order of magnitude.
Perusing various sites it’s rather astonishing how few capacitor vendors specify leakage. A lot of them claim “low leakage” but don’t give numbers. That’s about as useless as a campaign pledge.
Kemet’s excellent “Application Notes for Tantalum Capacitors” does show how derating the voltage can help. Operate at the cap at a third of the rated voltage and the leakage will typically decrease by an order of magnitude. Go to ten percent of the part’s rated level and leakage dives by another factor of five. But in a three volt system that means a 30 volt capacitor – bigger and pricier.
These deratings are “typical” numbers. Use with caution.
But do battery-operated systems need those big bulk caps? Aren’t they only for filtering power supplies?
The answer is that it depends. When the CPU wakes up the entire system comes to life. The processor and all of the required peripherals and real-world interfaces will suddenly make serious demands on the battery. A CR2032 has a series resistance on the order of tens of ohms, but that increases as its capacity is used up. Your system may require tens of mA for a short time. Near the battery’s end of life, when it is struggling to put out a bit over 2 volts, its series resistance could be enough to cause the system to be under-powered.
A capacitor has a very low series resistance (aka ESR), and can provide the needed power. TI has a white paper about this . They claim a CR2032 can exhibit as much as 1000 ohms of series resistance as it becomes seriously discharged! One mA at 1000 ohms is a 1 volt drop, which will certainly crash the system. Even if you discount TI’s number by an order of magnitude, a not-unreasonable 10 mA load will have the same effect.
So what kind of cap has very low leakage and decent capacitance ratings? I can’t find any in the greater than 10 uF range that will allow a system to run for two decades on a coin cell. Probably the only option is to exploit the 10-50X improvement that comes from derating a high-voltage capacitor. But even that will swamp the MCU’s consumption.
Capacitors are the tip of the iceberg. If the battery is installed by a worker who isn’t wearing gloves, what is the effect of the finger oils left on it? If a sleeping CPU uses, say, 20 nA, then it seems logical to keep other drains no larger. At 3 V a 150 million ohm resistor draws 20 nA. It’s not unreasonable to imagine finger oils in the 150 meg range. Maybe it’s much worse – I can’t find any empirical data.
FR4 PCB material is somewhat hygroscopic. Here in Maryland the summertime humidity soars seemingly to infinity. Must boards be conformally coated?
What is the conductivity of the solder flux residue? Does the board cleaner leave low-impedance swarf behind?
There are a lot of ways nanoamp leaks can accumulate, and it won’t take much to seriously impact decades-long battery lives. The nanoamps consumed by the MCU are just a part of the equation – perhaps a small part.
There is good news for designers: if the batteries start failing at the five or ten year mark, probably no one will remember who is at fault.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .