A sneak preview

The sleep current war between MCU vendors is bogus.

Regular readers of embedded.com are aware of the sleep current war raging between MCU vendors. Marketing glitz and web pages are the guns; white papers are the ammo, which is being broadsided with increasing frequency. Everything claimed is probably true, but much of it is misleading and/or irrelevant.

It's truly remarkable just how little current is needed to keep a processor alive today. In the deepest sleep modes even some ARM parts claim just 20 nA (nanoamp) of consumption. That's a mere 0.02 microamp, a number that boggles the mind.

In the desktop world CPUs suck over 100 amps while active, so I salute the MCU community for achieving such astonishingly-low figures.

First, some context. In the trenches of this war lie the lowly CR2032, a typical coin cell that's oft-quoted as the canonical battery for extremely-long-lived systems (Figure 1 ).

Figure 1. A CR2032 primary cell
A CR2032 has about 220 mAh of capacity (quoted capacities vary a little depending on the vendor ), which means it can source one mA for 220 hours. (Note there is some dependency on capacity vs.how fast one discharges the battery ).

It's nominal voltage is 3.0, perfect for these 1.8 to 2V min MCUs, and the discharge curve has a sharp knee. They are considered “dead” at 2.0 V, which is confirmed by my experiments. Here's data for a number of batteries, all from one batch from the same vendor, discharged at a 0.5 mA rate as shown in Figure 2 :

Figure 2. Batteries discharging at a 0.5 mA rate.
Some of the vendors claim their MCUs can run for 20-30 years from a single CR2032. That's may be true in theory, but not in practice. I contacted a number of battery vendors and none guarantee shelf lives over ten years.

One vendor said: “Not recommended for use after shelf life expires as the chemicals in the battery break down and it looses power a lot quicker, and there can be corrosion or leakage.”

It's poor engineering practice to use a component beyond its rated specifications.

Though the war is all about battery lifetime of a mostly-sleeping system, that's irrelevant for design engineers. The right question (which no one seems to be asking ) is: how much useful work can the system do while awake?

“Useful work” translates into a lot of things (clock rate, instruction set efficiency, etc ), but is ultimately bounded by how much current the system (MCU and other components) can consume while awake. It's is the budget a design engineer has to work with, and cannot be exceeded (on average ).

Doing the math, I came up with the following curve (Figure 3 ), which assumes a ten year battery life. It shows the number of mA available while awake, as a function of time spent sleeping and amount of current consumed while sleeping.

Figure 3. Milliamperes (mA) available as a function of sleep time and sleep current.
Here's the key takeaway : Sleep currents are almost irrelevant. Take two MCUs, one that needs 20 nA while sleeping and another that consumes 200 nA. The available awake current is just about the same in both cases. Even one that sucks a microamp while sleeping gives results not much different from an MCU needing an order of magnitude less.

Every MCU has vastly different mixes of features. Some wake up quickly. Others execute at great speed so wake times are minimized. Some preserve registers and memory while asleep; others don't. Brown-out and watchdog circuits may or may not be viable options while sleeping if maximum battery life is desired. So making comparisons is difficult. Even the sleep current numbers are frustratingly difficult to parse as not all vendors give worst-case values.

This article is titled “A Sneak Preview ” because it's just the tip of the iceberg. I've been running experiments for 6 months to gain a deeper understanding about building ultra-long-lived battery-powered systems, and will be reporting more results soon.

Some of my experiments are quantifying the behavior of the components we use. For instance, there's very little known about how a CR2032 discharges in these ultra-low-sleep current applications, and I've amassed a vast amount of data using some custom tools, like that in the following photograph below. The results are surprising, and lead me to doubt that even a ten year life is attainable in a real system. 

Figure 4. Nine-cell battery profiler using an mbed ARM controller board .
Transistors switch different loads on each battery to run various current and time profiles. Loads are low tempco, 1% resistors. An A/D reads battery voltages and Vce of the transistors. A precision reference and software calibrates the entire analog path.

Vendors have been very generous in offering their tools and support; for instance, I've evaluated several tools for measuring current, including:

* IAR's I-Jet
* The Real-Time Current Monitor
* The uCurrent

Microchip just sent me their latest current-measuring tool, which I hope to dig into between trips to the Middle East and ESC-India this month. Agilent is sending their very interesting new N2820A current probe, which has a claimed 3 MHz bandwidth and 86 dB dynamic range. I'll review them both, and other similar tools as they become available.

Stay tuned!

Jack G. Ganssle is a lecturer and consultant on embedded developmentissues. He conducts seminars on embedded systems and helps companieswith their embedded challenges, and works as an expert witness onembedded issues. Contact him at . His website is.

See more articles and column like this one on Embedded.com .Sign up for the Embedded.com newsletters . Copyright © 2013 UBM–All rights reserved.

12 thoughts on “A sneak preview

  1. “An A/D reads battery voltages”

    I recently designed a “fuel gauge” feature to monitor the voltage of a coin cell powering an RTC. I was surprised to discover that the max leakage current of my MCU's analog inputs was +/-1uA, which is 50x greater than the

    Log in to Reply
  2. Good question! The batteries go to low-R analog switches, which then feed a non-inverting voltage follower before going to the A/D. The voltage follower's input impedance is extremely high.

    Log in to Reply
  3. Hi Jack.
    Are you familiar with the work that EEMBC Ultra low power Benchmark initiative? It would be a good contribution to this article series. What the members are working towards is a unified way of measuring and bench marking products for low power

    Log in to Reply
  4. Kewl stuff Jack. I hope the next time you are in Chicago we can get together. The last time we met in person was an an IEEE conference in Boston about 15 years ago. You gave a class that I attended, and I gave a paper on semiconductor manufacturing executi

    Log in to Reply
  5. Interesting graph, have to remember that. Guess this is just the latest offshoot of the “green” movement to run on power that they'd like to assume was scavenged in the first place, they'll make all manner of irrational assumptions including the processor

    Log in to Reply
  6. This is a very difficult issue. Some on-chip brownout detectors require far more current than the MCU core does in sleep mode.

    Writing to flash usually takes quite a lot of energy. And holding up the power using a capacitor will (probably) not work. If yo

    Log in to Reply
  7. Wow! Thanks Jack, I'm used to asking questions I haven't been getting answers for, especially from some obvious support organizations (on whom I don't want to put TOO much blame, they're trying as hard as they can), but you're restoring my faith in our emb

    Log in to Reply
  8. I was going to make a similar comment. We at EEMBC are well along with establishing what we're calling ULPBench. It's a much more sophisticated benchmark than just running a 'pile of code' and takes into account sleep modes, real time clock function, and e

    Log in to Reply
  9. “Your premise, “The sleep current war between MCU vendors is bogus.” is misleading. While sleep current may not be significant for coin cells, sleep current is very important for applications using a low self-discharge rate battery such as lithium thion

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.