Energy Optimization Tools for Ultra-Low-Power Microcontrollers
By Wolfgang Lutsch, MSP430 Tools Engineer,
Texas Instruments with Lynnette Reese, Technical Staff, Mouser Electronics
Low Power MCU Design Series Featured Products Related Applications
The actual energy consumption over the lifetime of an application is a consideration of both the average and peak power consumption. A ULP engineer has several parameters and dependencies to consider with low power applications:
Runtime environment, e.g., temperature
Capacity: the total amount of stored energy. Is it limited or unlimited?
Power: peak current, as in the maximum current that the battery can maintain.
Energy Source: Where is the power coming from? For example, battery or energy harvester.
Energy Sink: What is consuming the power? For example, an embedded application or circuit.
Performance requirements, as in what certain tasks must execute in a given period of time?
Power consumption over time, or average consumption.
Ultra-Low Power Design Challenges
Given the above ULP parameters and the various dependencies or trade-offs of those parameters, the ULP engineer has four high-level questions to answer:
Can I perform the required task in the maximum available time?
Can my energy source support the required peak consumption?
Can I achieve the expected operational lifetime of my application?
Can I answer the above three criteria with "Yes" under typical and worst-case conditions?
The "ULP Need-to-know" List
When designing with embedded microcontrollers with a focus on ultra-low power, an engineer has three main areas to be concerned with, to be covered in further detail later on. Organizing from the top-down at a high level:
Know the application, its basic operation, features, and the available energy budget.
Know the features and parameters of the energy source.
Know the features of the MCU:
Power Management & Clock System
ULE peripheral features, strength and weakness
Power Modes and their energy efficient use
The main point is that a developer needs to know his application well, what the real goal is, what he needs to do, and the available energy budget. One typically approaches a new project with a focus on the requirements of the whole design, but with ULP, the parameters or specifications of the energy source also have a huge impact on the architecture of an embedded system.
The Power Profile Basics
One metric a ULP engineer definitely needs to be familiar with is the power profile of his application. Another name for power profile is "activity profile."
The basic premise of ULP applications is that they operate from a limited energy resource in one or both ways: either they are limited in the total amount of energy or the peak power that can be supplied by the source. The second basic consideration is the overall life-time of the ULP application, which can be as long as over 10 years of operational life from one battery, such as in utility metering. Primary batteries as energy resources have charges in the range of 50mAh up to <1000mAh. Some energy harvesting applications have even more critical available-energy budget conditions. Presently it is reasonable to consider a time scale of 3 to 10 years for the majority of ULP applications.
In energy harvesting , the application scenario is even more complex. Some applications can expect energy from the harvesting system when activity is needed; others may need to bridge by days or months without energy in the operation of a harvester. Energy harvesters can be intermittently available (e.g., solar ) or provide relatively constant energy from ambient sources (e.g., thermoelectric or geo-thermal.) The key to a good ULP application is that the active time of the application is reasonably low.
Figure 1: Good ULP applications have an MCU with a low amount of active time.
The power budget, source and sink, need to be understood. You can do some rough calculations when you know the parameters on both sides. For example, based on your end goals, how much is your MCU going to be active?
In Figure 1, the average current is only for the digital portion of the microcontroller plus the oscillator to generate the timing of the period:
IAVG = IStand-By + IActive * tActive / tperiod
Assume that:
IActive = 2mA; IStand-By = 500nA; tperiod = 1s; and IAVG = 1.5μA
Therefore:
tActive = {(1.5μA – 0.5μA) / 2000μA)} * 1s = 500μs
and
CyclesActive ≈ 500[ μs] * {2000 [µA] / 200 [ μA* μs]} ≈ 5000 [cycles]
Ultra-low power applications use only a portion of the time in each period, which makes the activemode reasonably low.
The Power Profile: An Example
Generating a power profile is very important. It allows you to calculate the average current in the interval, or the minimum energy that needs to be available (or harvested) in each interval. Also, it highlights the peak current that the power stage must deliver. Sometimes an example can best demonstrate the impact to the average current demand of a shorter or longer sleep period. In this case, assume a timeslot is 1ms and the period is 1s, which is a reasonable assumption for a wireless sensor network (WSN.)
Phase
Current
Slots
Wakeup
500μA
0.1
CPU
2mA
2
Analog
1mA
1
RF
15mA
1
DMA
1mA
1
Table 1: Example cycles of a wireless sensor network where ILP = 2µA.
Assume that the low power current consumption is 2µA.So at every 1000th time slot, we have action, which translates to an average current consumption of 23.5µA:
IAVG = (0.5x0.1 + 2x2 + 1 + 15 + 1)mA/1000 + 2μA = 21.5 μA
However, the same scenario with a 20s period looks like this, because the active cycle is every 20,000th time slot:
IAVG = (0.5x0.1 + 2x2 + 1 + 15 + 1)mA/20000 + 2μA = 1.06 μA
Figure 2: An application power profile example.
The Energy Profile
The energy profile of a microcontroller-based application has become more and more important, as well as the power profile. MSP430x1/2/3/4xx devices are based on ≥ 350nm processes and use clock gating for low-power modes. MSP430x5/6xx and MSP430FR5xxx devices are based on ≤ 180nm processes and use clock and power gating for low-power modes.
In 180nm and smaller process nodes, current leakage consumes energy which is simply lost.
Figure 3: Energy Profile is hard to calculate and requires actual measurement.
The Power Profile and Energy Profile Benchmarking
One highly regarded means of comparison is benchmark testing with competitive solutions. Much of the benchmark data collected has a clear message. Benchmarks are published with a solid background and the expectation of transparency, a fair selection of product, and equivalency of comparisons.
However, some otherwise reputable benchmarks are published that need careful consideration. Parameters should be scanned when looking at comparison/benchmarks, especially when part names are not mentioned and benchmark software or hardware is not mentioned or cannot be identified.
Another consideration is whether the code that was used is available to examine. Is it public? Is the hardware circuit or component accessible? Tools and compiler versions and options may not be listed. Benchmark testing strengths and weaknesses are not known and perhaps some technology is not mentioned. Any published benchmark needs to be read with a critical eye and should be subject to a critical review.
Consider the Power and Energy Profile of the Application
The power profile and energy profile of ultra-low power applications are needed to partition hardware and software according to the abilities and features of the energy resource. The profile is necessary if you are to design-in optimum hardware and software capabilities, with consideration for value-added features and cost containment. Lastly, the power and energy profiles define the energy resource and power system as meeting the application conditions.
There are three main criteria in battery-sourced applications. First, select the optimum energy efficient operating conditions. Second, limit the maximum current to avoid voltage drops that can generate a reset. And third, make sure the system’s lowest voltage matches the discharge level of the battery.
Review: the Engineer’s "ULP Need-to-know"
After general considerations concerning ULP application design, next on the Engineer’s "ULP Need-to-know" list is the microcontroller: Know the features of the MCU. You should be familiar with the power management and clock system, the ultra-low energy features of your peripherals, and their strengths and weaknesses. Lastly, the ULP engineer should know the available power modes and their energy efficient use.
Choosing the right Microcontroller – What is actually important?
Some criteria is obvious for ULP decision-making, such as starting off with an MCU that is optimized for low power, starting with the fabrication process. Some MCUs are just engineered to the best overall ULP end-game in mind, like the Texas Instruments ULP MSP430FR5xx series of FRAM MCUs, with advanced power management systems.
Power consumed is made up of many factors, regardless of which MCU is chosen. Even if you would choose leading technology, you have to consider that firmware is half of the equation when it comes to ULP designs. It is crucial that the embedded software (Firmware) actually makes use of the ULP hardware capabilities.
Silicon and hardware design are half the equation. In hardware, power consumption is made up of many factors:
Supplying appropriate operating voltage
Selecting appropriate clock source and frequency
Using external power domains for peripherals when possible
Half of the design power conservation is is spent in firmware and software code. Optimized firmware can help developers fully leverage ULP capabilities. Every unnecessary instruction executed is a portion of the battery wasted that will never return. Every parameter in this equation can be influenced by embedded software, since: Energy = Current x Voltage x Time. Software matters. Effective code is a must. But optimizing for power consumption is a non-trivial task! Firmware development in practice means that the engineer is busy thinking about an application’s functionality and ULP has second priority. The engineer simply does not have such coding rules in mind during development.
Energy efficient software structure can only be optimized best with energy efficiency in mind from the first. For example, a simple yet inefficient copy process can eat more energy than necessary. Pointing to an object is more energy efficient, especially if it happens several times a minute.
However, engineers do have many tools and resources available these days. Code generation tools are now more ULP aware, can help identify areas for ULP improvements in the program code, and provide suggestions for how to improve the code being examined. One example is the ULP AdvisorTM Code Analysis Tool for MSP430TM MCUs, which focuses explicitly on software optimization for ultra-low-power. Other resources include MCU-dedicated forums and Wikis online that can help find specific answers or recommendations.
Some General ULP Design Recommendations
Terminate Unused GPIO
When an unused port pin is left undefined or non-terminated, the floating voltage or shoot-through current on the pin can increase the overall current consumption. Depending on the actual number of available general purpose IOs, one risks considerable additional supply current due to undefined input voltages. Digital input pins are subject to shoot-through current; input voltages between VIL and VIH cause shoot-through if input is allowed to "float" (left unconnected.)
Port I/Os should be driven as outputs, driven to Vcc or ground by an external device, or have a pull-up/down resistor. One other task is to initialize or terminate each port. Either configure them as an output pin or as input, terminated with an external resistor.
However, you still have to be careful and know your environment. For example, don’t terminate an in-use GPIO or terminate an already-terminated GPIO with another external pull-up resistor. Actual ULP savings might not be simply black and white. Static code analysis is not the whole truth about ULP, either. Measuring the actual energy consumption of the application is also required to perform ULP optimizations. In reality, you can only improve what you can actually measure.
ULP Rule: Use Low Power Modes
The use of low power modes (LPM) is a huge factor in energy savings. Don’t neglect to investigate them all. The objective is to minimize the time the microcontroller spends in active mode and maximize the time in LPMs. Peripherals can be configured to operate without CPU intervention, and the CPU only needs to wake up to perform critical tasks and quickly return to LPM again.
Resolve to be clever and use LPMs everywhere, i.e. while waiting for certain peripheral tasks to complete, waiting for an interrupt, spinning in a while (1) loop, and so forth. ULP with firmware with the MSP430 is easy. You can enter LPMs with just one line of code.
µLP Rµle | Leverage Interrµpts
Use LPMs in your application when the application is waiting for a flag to be set. Enable interrupts and configure the microcontroller's peripherals to wake up the CPU when the peripheral's status flag is set.
Rather than waiting and periodically polling an event flag, the CPU should enter an LPM and leverage one of the integrated peripherals to wake up the CPU. Constantly polling a status flag will keep the application in active mode, which will greatly increase power consumption and reduce battery lifetime. For instance, while an ADC is performing its sample-and-hold conversion, the CPU and the rest of the system can sleep in an LPM. As soon as the conversion result is ready for further processing, the ADC triggers an interrupt event that wakes up the CPU form its sleep state.
ULP Rule : Use timers, not while() loops
Leverage one of the microcontroller’s LPMs, and use one of the timer modules to wake up the CPU after a set amount of time. Low-power microcontrollers usually have various timers and clocks that can be configured to function without CPU intervention. When a delay is required, one of the timer peripherals can be leveraged to generate the delay without the CPU staying active. This method significantly reduces power consumption. These timers can enable the MCU to stay in an LPM until the timer wakes up the CPU. In a microcontroller, the CPU is the largest contributor to the overall power consumption. When an application executes a delay, if the CPU stays in active mode, a significant amount of power and energy is wasted.
Firmware: Leverage DMA for data transfers
The DMA peripheral can be configured to automate the data or memory transfer process without CPU intervention, and hence reduce the power consumption. The DMA will then operate with no impact to the CPU, and the CPU can continue in any power mode undisturbed. Alternatively, the DMA can also operate in parallel with the CPU for maximum performance and speed when the CPU is active.
Conclusion
In conclusion, the engineer’s ULP "need-to-know" list is comprised of three main concepts:
Know the application, its basic operation, features, and available energy budget. Know the features and parameters of the energy source. Know the features of the MCU, the power Management and clock system, the ULE peripheral features and the strength and weakness of each. Get familiar with power modes and the use of each mode. Create and review your software for energy efficiency. Use static code review, e.g. ULP AdvisorTM software, to assist with ways to save energy in coding ULP. And be sure to physically measure current consumption before and after software modifications for a window into the effectiveness of your tactics. Ultra low power design can range from the simple and minimalist to completely optimized for maximum energy efficiency; but common sense says to take advantage of power savings whenever possible, especially when it’s easy to do.
In his current role Wolfgang is responsible for the Product Management of next generation development tools for ultra-low power microcontrollers.
Perú
