Battery Life Calculator for Freescale Microcontrolers

We get many questions from customers asking what the IDD of a particular MCU is at a specific voltage/frequency/temperature combination. Obviously we cannot take data on all of MCUs across all possible combinations of operating conditions. So to help customers answer questions about power consumption under various conditions we created a battery life calculator.

 

How does it work?

This battery life calculator is a small executable program that allows the user to enter the operating conditions (voltage/frequency/temperature) along with battery capacity, the percentage of time the application spends in each of the MCUs modes (run, wait, stop3, stop2 and stop1), and a periodic wakeup interval. The calculator takes this information and determines the average current the MCU is consuming and an estimation of the resulting battery life.

 

MC9S08GB/GT Battery-life Calculator. Click to enlarge.

 

How does it calculate battery life?

The calculator was created by measuring currents on a few typical samples under many different conditions. The data results were analyzed and equations created for each mode of the MCU (i.e. run, wait, stop3, etc.) that fit the data as much as possible. The results of each equation are averaged together based on the percentages and wakeup interval the user provides. This resulting average current is then used to calculate the battery life based on the provided values of the battery capacity and an estimate of the battery self-discharge current for the type of battery. Capacities and self-discharge currents are provided for some common alkaline and lithium batteries.

 

Which devices are covered?

Currently, we only have a calculator for the MC9S08GB/GT 8-bit MCU family, but we are working on versions for the new QE128 Flexis Duo. The MC9S08GB/GT can be downloaded free of charge from:

http://www.freescale.com/files/microcontrollers/software/app_software/HCS08BATTCALC.zip?fpsp=1

 

-Scott

Flash in battery-powered applications

One advantage Freescale microcontrollers have over many of our competitors is that our flash memories can be programmed and erased at low voltages. On most low voltage 8-bit S08 and 32-bit ColdFire® MCUs (the ones specified to run from 1.8V to 3.6V), the flash memories can be written and erased across the entire operating voltage range.

This provides several advantages for battery-powered applications:
· No worries about battery level for user-programmable applications,
· No worries about battery level for firmware updates
· Ability to save the current RAM/register states when the battery gets close to its end of life.

User-programmable applications
It is fairly easy to see the advantage of programmability across battery-life in a user programmable application. A programmable remote control is a good example of such an application. With no limitations on battery voltage, users can add or change functions on their remotes whenever needed.

If the MCU places limitations on programming voltage, then the user has to change to fresh batteries when adding the new DVD player to the master remote. Alternatively, the remote has to maintain the settings in RAM, meaning the user has a limited amount of time to replace batteries when they are drained.

Firmware updates
Let’s take the example of a monitored home security system that includes battery-powered wireless sensors throughout the house. Suppose the manufacturer of the system has a software upgrade to improve the security of the wireless transmissions. If the MCUs used in the battery-powered sensors cannot re-write the flash across the entire battery voltage range, then the company that installed the system either has to contact the homeowners to instruct them to install fresh batteries in every sensor or send a technician out each home to perform the update.

Using MCU’s that can rewrite flash across the entire battery voltage range, the upgrade can be made without concern for the current voltage output of the batteries. The manufacturer can therefore provide a remote way to upgrade the firmware through the monitoring system without having to contact the homeowner, making the process much more efficient and reliable.

Saving the current state
The last advantage I want to discuss is saving the current state of the system. Some smoke detectors and carbon monoxide detectors will keep a running count of their sensor readings in RAM to keep track of the highest readings for the last hour, day, week, etc.

With a voltage-limited flash, these values can only be saved into flash when the detectors have relatively fresh batteries or when AC line powered. If the power goes out or the batteries aren’t replaced before going dead, the RAM contents will be lost.

With a flash that programs across operating voltage, the RAM contents can be saved as the batteries get near end-of-life or if the power goes out and backup power is available from a capacitive storage.

-Scott

ColdFire vs. S08 in Low Power Applications

Hopefully by now you’ve heard of Freescale’s first family Flexis(TM) microcontrollers. These are families of 8-bit S08 MCU’s paired with families of pin and peripheral compatible 32-bit ColdFire(TM) V1 MCUs. The first Flexis MCUs, the QE family, are also some of the lowest power MCUs Freescale has produced.

Since the Flexis QE family is designed for minimum power consumption, the question arises, “Which one is better for a low power design?” Let’s take a look…

Specs
If we look at just the raw supply current specs for the S08 QE vs the V1 QE, we see that the S08 typically consumes half as much power in run and low power run modes, but is only slightly lower in the stop3 mode and is equal to the V1 in the lowest power stop2 mode.

Figure 1: Supply current comparison of the V1 QE128 and the S08 QE128

CPU Workloads
So based solely on these specs, you would probably favor the lower power S08 QE. However, we need to look at how much work the CPUs must perform while in run mode. The 32-bit V1 CPU has far more horsepower than the 8-bit S08. For one thing, the V1 executes instructions at the CPU frequency and the S08 executes instructions at the bus frequency, which is 1/2 of the CPU frequency. In addition, the V1 has far more CPU registers and, of course, utilizes 32-bit instructions/operands for more efficient data processing.

In a previous post (Clock Management for Low Power Application, July 13th), I discussed the concept of running fast to spend as much time in the lowest power mode possible. With this philosophy, you can easily see how a more powerful CPU will complete any calculations faster and therefore be able to spend more time in the lower power stop modes, thereby lowering the overall MCU average power consumption.

Same Peripherals
So, the V1 QE should be lower power on average than the S08, right? Well, not necessarily. Both the S08 QE and V1 QE use the exact same peripherals. Therefore, the V1 doesn’t get a performance advantage when a peripheral’s operation is the only thing preventing a return to a low power mode. For instance, if an IIC transmission is the only task left before entering stop2 mode, the IIC doesn’t run any faster on V1 just because the CPU is more powerful. Both MCUs will have to wait the same amount of time for the transmission to complete.

Also, these peripherals were designed for 8-bit CPUs. So the S08 is very efficient when it comes to setting up and using the on-chip peripherals. The V1 does have 8-bit instructions to improve its efficiency with these peripherals, but this does limit its performance advantage over the S08. So when much of the CPU’s time is spent accessing peripherals versus pure data manipulation, the V1’s energy use per task is not much different than the S08’s.

Which to Choose?
As you can see, there is not a simple answer to choosing the right CPU core for obtaining the lowest power. In general, if the application requires a fair amount of number crunching, particularly 16-bit and 32-bit data, then the V1 will probably be the best choice. Conversely, if the application requires the CPU to spend more time configuring and waiting on peripherals than number crunching, then the S08 will likely be the best choice.

Of course, if you think you made the wrong choice, the compatibility of the Flexis MCUs makes switching to the other core a piece of cake!

-Scott

Brownout protection in low power designs

A frequent question that comes up about low power designs using our microcontrollers has to do with brownout detection. I’d like to use this week’s posting to address the MCU features that help protect these devices from brownouts.

What happens in a brownout?

There are two main problems a brownout can cause. First, if the VDD reaches a point where the logic is still operating properly but the program memory (usually flash) does not read correctly, a runaway code condition can occur, and it continues until the VDD rises back to a safe operating range and a reset occurs. In this case, the danger is only when the CPU is actively executing code. If the MCU is in a low-power mode where the memory is not being accessed, the runaway code condition can’t occur.

Second, when the VDD falls below the digital logic’s safe operating level, brownouts can corrupt the RAM and registers content, which, if undetected, can result in unexpected operation of the application. In this case, even if the device is in a low-power mode, the corrupted data can still cause problems when the MCU wakes from the low-power state, even after the VDD has returned to a safe operating level.

Features for protecting against brownouts

Freescale MCUs have two primary features to protect against brownouts: a low voltage detector (LVD) and a power-on reset (POR). The MCUs also have system protection features (watchdog, illegal address and illegal opcode resets) that help recover from improper operation should a brownout occur.

Low voltage detection
The LVD can protect against both brownout cases listed above. LVD module features vary somewhat between devices, but in all cases the LVD can be configured to generate a reset when the VDD falls below the LVD trip point. The trip point is chosen to cover the MCU’s appropriate safe operating point.

Now one of the drawbacks of the LVD is that it consumes extra current when operating. On the 8-bit S08 and 32-bit ColdFire® V1 MCUs it requires the internal voltage regulator to be running, which consumes roughly 70 uA of current. Therefore, you typically want to disable the LVD when in the low power stop modes. These LVDs have the option to automatically disable detection when entering stop mode and re-enable detection upon exit from stop mode.

So this provides protection when the MCU is in run mode, but how do we protect against brownout in stop modes?

Power-on reset

Many of the 8-bit HC08 and S08 MCUs and all of the ColdFire V1 MCUs have an active POR versus a passive POR used on older devices. This active POR sets the POR trip point at the level where the digital logic is operational. Therefore, if the VDD falls below the point where RAM and registers can be corrupted, a POR occurs and holds the device in reset until the VDD recovers and the device can be re-initialized.

Because the POR doesn’t release until the chip logic is functional, the LVD circuit will be operational once the POR releases reset. Since most MCUs will enable the LVD when a POR occurs, the MCU is further protected until VDD reaches a safe operating point for the program memory.

Unlike the LVD, the active POR consumes very little power, only about 100-200 nA. Also, unlike the LVD, the active POR is not optional. It is always on, even in the low power stop modes, so there is no lapse in coverage.

So with the always-on protection of the POR and use of the optional LVD reset, you can have excellent protection against brownout conditions, even in low power modes, without significant impact to your battery life.

-Scott

System Hardware Strategies to Extend Battery Life

Last time, I talked about software strategies for reducing power. This time, I’d like to talk about hardware strategies. From a hardware standpoint, controlling power to peripherals, both internal to the MCU and external, can save considerable power. It is straightforward enough to disable on-chip peripherals using the MCU’s control registers. But it may not be as obvious to disable peripherals external to the MCU. Using general I/O pins, power can be controlled to external circuits.

Power discreet and IC components

Now discreet components such as LEDs and photosensors may be obvious candidates for controlling with I/O, but just about any circuit can be controlled in a similar fashion. If the component requires more current than the MCU can provide directly, buffers can be used as power switches to these circuits. In some cases, simply connecting several I/O pins in parallel can provide enough current.

Use hardware modules for monitoring input

Another hardware/software trick is to use modules with interrupts to monitor external signals versus polling the input. If you just need to observe a rising or falling edge, use an interrupt pin. If you need to know a relative time the edge occurred, use a timer input capture. Both timers and pin interrupts can operate in several low power modes.

For analog signals, a comparator combined with an ADC channel can create a very efficient monitor. The Freescale MCU’s comparator uses a fraction of the current of the ADC module. Configure the comparator to run in a low power mode and trip at a threshold voltage. When the MCU wakes, the ADC can measure the same signal for a more accurate reading. Several Freescale MCUs even have comparators and ADC channels on the same pins to make this simple.

Configure I/O pins for lowest power

The MCU’s I/O pins themselves can be a source of excess current if not configured properly. Unused pins need to be terminated to prevent a floating input from creating a high current path. This is frequently overlooked when using an MCU that comes in a variety of packages.

We tend to forget that the pins available in the highest pin count version are still on the silicon in the lower pin count versions. Any input pin left floating will become a frustrating source of excessive current, many times only under certain circumstances, such as temperature variations. In these cases, an internal pull-up should be enabled, or, if the pin is an I/O, it can be configured as an output (data is irrelevant if it is driving an open circuit).

New Low Power Run and Low Power Wait Modes. What’s new about them?

Hi, folks,

If you are one of our microcontroller customers, hopefully by now you have heard about our newest MCU family, the Flexis(TM) QE series, which unites our 8-bit S08 MCUs with our new higher-performance 32-bit ColdFire V1 MCUs. We have introduced a few new features on this family intended to help you extend battery life. Two new features I’d like to discuss in detail are the new low power run and low power wait modes.

Issue: the need to run slow
In my first posting, I discussed using the high clock frequencies to reduce average system current by reducing the amount of time spent in higher power run mode and maximizing time spent in the lowest power stop modes. However, this approach may not always be practical. For example, you may need to run a peripheral that doesn’t run in one of the stop modes, such as a timer or UART.

All of our S08 and ColdFire MCUs have on-chip voltage regulators that are active anytime the MCU is in run or wait modes. Therefore the MCUs have a DC offset current that never goes away in these modes. As a result, the slower the operating frequency, the less efficient the MIPs per uA becomes.

Why can’t all peripherals run in stop mode?
There are a couple of reasons many peripherals cannot run in the stop modes. In these modes, the system bus clock is disabled to save power. The peripherals that can run in stop mode either do not require a clock (e.g., analog comparator) or have a built-in clock source (e.g., analog-to-digital converter). The changes to enable the system bus clock in stop modes are non-trivial.

Another reason is that the voltage regulator goes into a low power “loose” regulation mode when one of the stop modes is entered. In this loose regulation state, the regulator can only supply enough current to power a few modules. The current required to run all modules would drain the regulator causing voltage drops that could fall below the minimum operating voltage.

Solution: low power run and wait modes
To resolve these issues, our designers created a new voltage regulator that can provide enough current in its loose regulation mode to power all peripherals at a limited frequency. However, we still had the issue with the bus clock being off in stop modes.

Instead of redesigning our clock architecture to allow the bus clock to run in stop modes, we decided to create two new modes: low power run and low power wait. As you might guess from the names, these modes are simply the standard run and wait modes with the voltage regulator in loose regulation. By taking this approach, we are able to offer full functionality of our peripherals in a very low power state. In addition, the low power run mode allows code execution at a much more efficient MIPs per uA at low frequencies.

Using low power run and wait modes
Using the new low power modes requires configuring just a couple of modules: the clock source (ICS on the QE family) and the low voltage detect (LVD). The clock source must be configured to be running off of an external clock or the crystal oscillator. The reason for this is that the internal clock sources for the S08 and V1 MCUs require a current source that needs the regulator to be in full regulation mode. Therefore, the internal clocks must be disabled. Also, the CPU clock frequency must be limited to 250 kHz to ensure that the regulator is not overloaded if all modules were to be enabled.

The LVD module must also be disabled to enter the low power modes since it requires a bandgap voltage reference that is only available when the regulator is in full regulation. Now we did pull a little trick here. The LVD module can either be disabled by clearing the LVD enable bit (LVDE) or the module can be enabled as long as the LVD stop enable bit (LVDSE) is clear. In this second case, when the MCU is in standard run or wait modes, the LVD is active. When low power run or wait is entered, the LVD will automatically shut down and then restart when the low power mode is exited.

Not a one-off solution
I hope you found this discussion useful and even more importantly, I hope you find these new low power modes useful. These new modes will be standard on our low voltage S08 and ColdFire V1 MCUs moving forward, so it is beneficial for us to make sure our customers are aware of them and understand how the modes can benefit your low power applications.

-Scott

Clock Management for Low Power Applications

For this posting, I’d like to discuss some tips on conserving power through clock management. Many designers equate low power to slow clock frequencies. However, depending on what the MCU is doing and what low-power modes are available on the MCU, running at top speed can actually save power.

What is clock management?

If the MCU has an efficient low-power mode, then you will save the most power by spending the most time in this mode. So if the CPU needs to execute code before returning to sleep, running at the fastest possible speed to complete code execution and return to low-power mode can burn less current than running constantly at slow speeds.

Example of clock management

Take for example the following scenario, a control panel gets a variable update once every 1 second and it takes 16,000 bus cycles to compute the data to be displayed. Running with a typical 32 kHz crystal and assuming a common divide-by-two bus clock, we have a 16 kHz bus, in which case it takes 1 full second to complete the calculations. Now, if we can run at 10 MHz bus clock, it only takes 1.6 milliseconds to complete the calculations and 999.4 milliseconds can be spent in a low power mode.

Other considerations

Of course, not every task an MCU has to perform will benefit from top speed performance. Let’s say our control panel example has a wireless data link. The time required for the wireless communication may not require an 8 MHz bus rate if the wireless data rate is fairly slow. In this case, to minimize power consumption, we want to run the MCU as slow as possible until the wireless communication is complete.

Flexible clock sources

So ideally, we need an MCU with a flexible clock source. Many MCUs have frequency-locked loops (FLLs) and/or phase-locked loops (PLLs) that support multiple frequencies. These allow you to multiply and divide the bus speed to meet the needs of the task and minimize power consumption. The best examples allow the use of external or internal reference clocks and allow you to switch the FLL/PLL on and off on the fly without the need to reset the device.

Feedback

Since this is the first post, let me know if you found it helpful by adding a comment. Also, let me know what low power topics you’d like to see addressed in future posts.

-Scott