Battery Management

PRODUCT HOW-TO: Developing apps on an energy-friendly MCU designed for a 20-year battery life

May 10, 2010 | Rasmus Christian Larsen | 222900911

Rasmus Christian Larsen, Training and Support Manager, Energy Micro, explains that when designing products for battery-powered operation, it is clearly desirable that battery life should be as long as possible. For a rapidly-growing class of devices, extended operation from a single battery becomes more than just a desirable feature in the specification: it is central to the entire product concept.

Page 1 of 7

In some applications, access to change the battery is difficult or even impossible: in others, the end-user cannot support the cost of replacing the battery.

Such applications employ an MCU that is active on a very low duty cycle, spending perhaps 99% - or even more, 99.9% is not uncommon of its time in a deep sleep state. They wake, either on a periodic cycle or in response to some stimulus, perform an action, and return to their sleep state.

As they spend such a high proportion of their time asleep, it is obvious that a key parameter in obtaining maximum battery life will be the current consumption while in the powered-down state.

However, the difference between a service life of three or four years, and one that exceeds 10 years, extending to 20 years or even more from the same battery lies in paying careful attention to every aspect of how the task uses the resources of the MCU, and how the MCU itself is designed to minimize energy usage in every way.

20 years from a single cellA widely-used battery in small MCU applications such as remote environmental sensors is the CR2032 coin cell; this is a lithium/manganese dioxide 3V primary cell.

A typical supplier for example, Kodak rates the capacity as 230 mAh to an end-point voltage of 2V into 5.6 kilo-ohms (about 0.5 milliamperes). At that rate its life would be around 400 hours; energy-sensitive applications, by contrast, deal with service lives up to 200,000 hours.

This particular cell has very good shelf life or self-discharge rate; the data sheet gives 10 years to 90% capacity. Very approximately, this is equivalent to a continuous discharge of about 0.25 micro-amperes, which sets a context for the applications average demand if a 10-20 year battery life is to be achieved.

Rasmus Christian Larsen, Training and Support Manager, Energy Micro, explains that when designing products for battery-powered operation, it is clearly desirable that battery life should be as long as possible. For a rapidly-growing class of devices, extended operation from a single battery becomes more than just a desirable feature in the specification: it is central to the entire product concept.

In some applications, access to change the battery is difficult or even impossible: in others, the end-user cannot support the cost of replacing the battery.

Such applications employ an MCU that is active on a very low duty cycle, spending perhaps 99% - or even more, 99.9% is not uncommon – of its time in a “deep sleep” state. They “wake”, either on a periodic cycle or in response to some stimulus, perform an action, and return to their sleep state.

As they spend such a high proportion of their time asleep, it is obvious that a key parameter in obtaining maximum battery life will be the current consumption while in the powered-down state.

However, the difference between a service life of three or four years, and one that exceeds 10 years, extending to 20 years or even more – from the same battery – lies in paying careful attention to every aspect of how the task uses the resources of the MCU, and how the MCU itself is designed to minimize energy usage in every way.

20 years from a single cell
A widely-used battery in small MCU applications such as remote environmental sensors is the CR2032 coin cell; this is a lithium/manganese dioxide 3V primary cell.

A typical supplier – for example, Kodak – rates the capacity as 230 mAh to an end-point voltage of 2V into 5.6 kilo-ohms (about 0.5 milliamperes). At that rate its life would be around 400 hours; energy-sensitive applications, by contrast, deal with service lives up to 200,000 hours.

This particular cell has very good shelf life or self-discharge rate; the data sheet gives 10 years to 90% capacity. Very approximately, this is equivalent to a continuous discharge of about 0.25 micro-amperes, which sets a context for the application’s average demand if a 10-20 year battery life is to be achieved.

With a finite amount of charge available over the lifetime of the cell, designers must minimize the product of current and time over all phases of the MCU’s operation; not only does every microamp count, but so too does every microsecond that every action takes.

In order to minimize the current consumed in the deep-sleep mode, it has been common practice to employ 8-bit (or 16-bit) cores in MCUs destined for energy-sensitive applications. The reasoning has been that the 8-bit cores – even in updated versions often employed in such designs – are small, have relatively few gates and low levels of static or leakage current.

However, many applications now require more processing power than 8-bit cores can easily provide. In other areas of MCU application, users are frequently choosing to upgrade from an 8-bit to a 32-bit environment. In this low-power context, it has been assumed that the current used by a 32-bit core in its power-down mode state must inevitably be unacceptably high.

With the full range of low-power design techniques available to today’s IC designers, it is possible to implement a 32-bit ARM core that offers a variety of low-power modes, as good as or better than their 8-bit competitors, and that nevertheless achieves rapid wake-up times.

The higher processing performance of 32-bit processors also enables the MCU to finish tasks quicker, thus being able to spend more time in these low-power modes, which lowers the average power consumption even further.

Low-power peripheral functions
Optimizing MCU sleep-state power consumption for the lowest power drain demands a holistic approach to design. In addition to the core, other blocks in the MCU will continue to draw some current when the device is in stand-by; voltage regulators, bias current generators, comparators for brown-out detection, power-on-reset circuits and so on.

In almost every case, a simple trade-off applies; the deeper the power-down state, and the more peripheral functions that are shut-off completely, the longer the wake-up time for the chip to be ready to carry out its processing task.

As applications vary so widely, it is essential that the MCU designer provides flexibility in the form of an extended suite of power-down states, so that the product designer can make the ideal trade-off of stand-by power and responsiveness for his individual project.

Designing an implementation of an ARM core that achieves deepest-sleep-state current levels in the nanoamp region is only one step in a low-energy strategy. Having available the processing power of a 32-bit core opens up new avenues to manage energy usage; at all times, it is the area under the graph of current supplied to the MCU, over time, that represents charge taken from the battery (Figure 2 below).

It is this, as much as headline figures for current consumption in specific configurations, to which the designer must pay close attention to maximize battery service life.

Figure 2: An energy friendly MCU core saves power in several distinct areas over a complete wake/operate/return-to-sleep cycle. The blue area indicates the energy saved by a more capable 32-bit core completing a task in fewer cycles than an 8-bit core would require and consuming less current in both active and sleep modes.

In the development kit for the EFM32 microcontroller, this measurement is made explicit. A fundamental part of the kit’s feature set is the Advanced Energy Monitor (Figure 3 below). This facility continuously measures current in the power rail feeding the MCU core; an analog-to-digital converter (ADC) samples the voltage across the resistor and the development kit software integrates the readings to give an accurate measurement of power over time.

Figure 3. Energy Micro’s Advanced Energy Monitoring feature tracks the total charge that the MCU has drawn from the battery over the complete operating cycle of its embedded code.

A 32-bit core will spend less time active to perform an equivalent task than will a less capable MCU: at the same time, the power used by the core while it is running should be as low as possible. IC designers focused on low power have access to many design refinements to achieve their goals.

Examples include techniques such as optimizing clock gating structures for all of the chip’s synchronous logic, and organizing the bus system and memories – both SRAM and flash – for minimum bit toggling in any given transaction.

Applying the full suite of low power design methodologies can produce an ARM Cortex-M3 core that will run representative code, from flash memory, while using as little as 180A/MHz. Careful use of these same techniques ensures that his figure scales well, down to low clock rates, and is not just a peak-performance figure.

The M3 core’s use of the Thumb2 instruction set also helps reduce the “active time”, once the MCU has been wakened and is executing application code. With features such as dual instruction fetches of compact 16-bit instructions, the efficiency of the Thumb2 ISA is well established.

In minimizing the current-times-microseconds product, the MCU designer has many more strategies to deploy. One is to minimize not only the time that the core spends in actually processing application code, but to shorten the ramp-up between the wake-up stimulus – whether that is timer-generated or event-driven – and the CPU being ready to do “real work”.

One route to minimizing the start-up time lies with provision of clock signals for the core. It is well-known that when a crystal oscillator is started from an off-state, it takes some time for its output to stabilize, before it can be used as a system clock.

Conversely, an RC oscillator may not be accurate enough as a time base for all the tasks that the MCU must complete, but will generate a regular output virtually instantaneously after it is powered on.

Part of the solution to cutting wake-up time lies in providing both; the CPU begins to run immediately power is applied, clocked by the RC oscillator, and a small control circuit transfers the clock source to a crystal oscillator as soon as it is stable. Any lack of frequency-accuracy in the RC oscillator’s output is not significant over the relatively few cycles for which it is used.

Simple tasks bypass the MCU core
Despite paying such close attention to providing the power of a capable processing core, and bringing it up in the shortest possible time, it is useful for the designer – either chip designer and system designer – to ask if a given task needs the core to at all: even the most energy-efficient core is squandering battery charge if it is wakened to carry out a trivial task.

An application – using, again, the example of an environmental sensor – might be required to make regular measurements, but only to report those measurements to a central data logger at much less frequent intervals.

Running the communications-interface software stack would certainly demand that the MCU core be wakened; but the more frequent routine of turning on the analogue-to-digital converter, commanding an A/D conversion, and accumulating the result in a low-power memory uses much less power if only the required peripherals can be set up to work autonomously under control of an interconnect matrix (Figure 4 below).

Figure 4 Using an interconnect matrix or ‘peripheral reflex system’, simple tasks such as initiating data conversions and storing the results can be carried out without waking the 32-bit processor core at all.

As applications vary so widely, a high degree of flexibility in choosing which functional blocks to power, and how they should communicate, is essential to fully exploit this concept.

Adding encryption within the power budget
It is well-known that in modern CMOS semiconductor processes, the cost in silicon area of adding functions to an IC as hard-wired blocks can be relatively small.

This leads to the slightly counter-intuitive outcome that in order to reduce power to a minimum, the most effective option is often to increase the gate count. With techniques such as advanced clock tree design, clock gating and on-chip power switches, the IC designer can readily completely shut off functions not required at any given moment.

One function that highlights this approach is that of encryption. Even seemingly mundane data is now routinely secured by encryption, typically by the algorithm known as AES. This is not a challenging task for a 32-bit MCU core but it does occupy a significant number of processor cycles, extending the microamps-times-microseconds total.

Most of those cycles are spent executing a few inner-loop computations in the algorithm; adding an AES accelerator hardware block allows the MCU to hand the AES algorithm off to dedicated hardware, get on with other processing, and get the encrypted (or decrypted) result back in far fewer cycles.

The rapidly-expanding class of energy-sensitive applications – headed by a few high-profile categories such as smart energy metering – is re-defining what it means for a product to be battery powered.

These products must offer service lives on a single battery that are comparable to the shelf-lives of the batteries themselves, and that are in the same range as the maximum intervals that battery manufacturers can specify: up to, and even beyond, 20 years. Only a highly-integrated, single-chip microcontroller offers a realistic solution for such designs.

With meticulous attention to every aspect of low-power chip design, the IC architect can now offer the product designer the power of modern, powerful 32-bit processor cores, at the same time as reducing power demands to a fraction of what was previously possible.

Rasmus Larsen is Training and Support Manager at Energy Micro, and heads the company’s technical support team and is responsible for training its worldwide sales channel. As one of the designers of Energy Micro’s first microcontroller, the EFM32, Rasmus has in-depth knowledge of the EFM32 product family. He has previously worked for Atmel (AVR) and holds a MSEE from NTNU in Trondheim, Norway.