Advanced Sleep-Mode Techniques for Enhanced Battery Life in Real-Time Environments

Whether they're used in smart meters, wireless sensor nodes or mobile health monitoring products, microcontrollers are at the heart of many real-time applications which demand prompt response to real-world events. In many of these applications, microcontrollers (MCUs) rely on sophisticated sleep mode techniques which suspend most or all their operations to minimize energy consumption, allowing them to run for years or even decades on their limited energy sources. These real-time environments pose special challenges for the designer and programmer because the same sleep states that reduce an MCU's energy consumption often also reduce its ability to quickly respond to an event.

This article will help you understand the techniques and architectural features you'll need to ensure your sensor/control network can reliably support all its real-time tasks while still maximizing battery life.

New applications require long service life

The advent of inexpensive, energy-efficient embedded processors and Smart Object technologies have fueled the growth of intelligent distributed networks for applications like Smart Buildings/Smart Homes, Smart Grid, security, environmental monitoring, and energy management systems. The same technologies are also being used to add intelligence to existing products like Smart Meters for energy, gas and water distribution as well as Health, Fitness and Portable Medical equipment. While the operational and design requirements vary widely, all these applications must operate reliably for years using the limited energy resources available from their batteries or energy harvesting systems.

The AA alkaline cells commonly used to power many distributed system elements have an initial capacity of 1500-2500 mAh but, when their self-discharge rate is factored in, a designer should count on having roughly 1000 mAh available for use over the battery's nominal 5-7 year service life (Figure 1).

Figure 1: Shelf life vs. temperature for an AA/LR6 Alkaline Battery. Courtesy of Energizer Battery Manufacturing Inc.

Some applications, (such as smart wireless water and gas meters) which are buried or otherwise difficult to access, face even bigger challenges. To achieve service lives of 10-20 years, they use batteries with specialized low-leakage chemistries. As a result, the meter’s energy budgets must be aggressively trimmed to maintain pricing that’s competitive in the Global marketplace.

For these applications, it’s not unusual to see power budgets of 5-20 µA (average/steady state). A typical design might have an energy budget that allocates 20 percent of the available capacity to transmit activities, 30 percent for receiving commands, and 20 percent for data collection and system maintenance. This leaves a mere 30 percent of the battery’s capacity to support the system’s Sleep/Idle mode where it will spend more than 99 percent of its life. Likewise, the wireless nodes in distributed sensor networks which rely on thermal or photovoltaic energy harvesting systems must subsist on energy budgets of 1-2 mAh/day.

Managing mcu wake time is critical

If a power-constrained application is properly implemented, most energy-intensive subsystems (RF and PHY-layer transceivers, displays, etc…) are already designed to spend only as much time in their active state as they need to so it’s likely that the MCU represents one of the best opportunities to optimize the system’s overall power budget. The majority of these additional energy savings can be achieved by making optimum use of the MCU’s Standby and Sleep modes.

Most modern MCUs have more than one low-power mode (typically, "Sleep/Standby", "Deep-Sleep", and "Off"), with varying levels of CPU, memory, and I/O functionality. The specific functionality of "Sleep/Idle" and "Deep-Sleep" modes varies from processor to processor but the general principles involved are basically the same.

Generally, the deeper the sleep, the less power is consumed by the MCU.

However, the power savings come at a price since waking from a deeper sleep mode takes more time. Some of the factors that affect wake time include:

• Hysteresis and propagation delays within the wake-up circuitry
• Startup and stabilization of power management for the MCU core
• Re-starting and stabilizing the CPU clock circuit
• Restoring the processor's registers and other internal configurations
• Restoring system memory
• CPU cycles required to service the interrupt which triggered the restart

Real-time responsiveness vs. energy savings

Achieving low power operation is relatively easy if all the events that the host processor must deal with are predictable. If energy savings were the only concern, the system would default to its’ Off/Shutoff Mode. In this case, the processor can enter a power-down mode after programming its real-time clock (or other timing logic) to trigger the wake-up process early enough to insure it’s ready for the next event. Some examples of the more predictable events that require a processor to enter its active mode include:

• Many applications using ZigBee/802.15, Wi-Fi, and other wireless technologies need time-slotted protocols which require the host processor to periodically check for messages from other network nodes.
• Real-time clock interrupts for system-related tasks, regularly-scheduled arrivals of collected data, and other predictable external events.

Unfortunately, most of the applications described in the previous section also require the MCU to respond to unscheduled events in real time - or at least semi-real time. Examples of these events include:

• Motion/acceleration data, threshold/alarm conditions, power interruptions, and other important, unscheduled events may require the host processor to respond within a few milliseconds or microseconds to prevent system damage or avoid loss of critical data.
• Some wired and wireless protocols transmit at random intervals, requiring the processor, or a dedicated radio controller, to be ready to respond to an incoming packet at any time.

From these examples, it's easy to see that, if the sleep mode you choose is too deep, the MCU's return to normal operation may take too long to respond in a timely manner to whatever triggered the wake state. Missing an Alert/Alarm may mean losing critical data, unacceptably slow response to a user command, or impairing the response time of an entire network.

Low-power rtos – innovation or oxymoron?

Complicating matters further are real-time operating systems (RTOS) which are beginning to gain acceptance in some embedded applications because of the deterministic behavior and simplified programming they can bring to a design. Along with its advantages, an RTOS brings another level of technical challenges. Designers wishing to implement an RTOS must address all the issues discussed so far but they must also keep in mind that:

• Many RTOSs require the MCU to be in its active (or at least its standby) state and only a handful (such as AVIX and FreeRTOS) are equipped to support them in their Deep-Sleep/Off modes.
• RTOSs usually carry additional overhead, both in terms of code size and, more important, the number of instructions required to recover from sleep mode or perform other tasks where microseconds matter.

Fortunately, good hardware design and smart coding practices can make it possible to enjoy the benefits of RTOS in many energy-constrained applications. Some of the basic issues involved with developing low-power RTOS-driven systems will be discussed towards the end of this article.

A closer look at sleep

One of the primary ways to optimize a low-power embedded design is to find the lowest sleep mode that still provides adequate response to real-time events. Before we go through the steps required to identify the Sleep Mode(s) best suited for a particular application, it’s useful to get a feel for the MCU’s power consumption, available functionality, and how long it will take to return to an active state in each of its Standby/Sleep modes.

To illustrate the characteristics of each Sleep Mode state, we will use Energy Micro’s EFM32 "Gecko" family of Energy-optimized 32-bit MCUs. Although the Gecko architecture has been optimized to perform beyond the basic requirements of each mode, most MCUs used for these types of applications will have similar operating states and characteristics (Figure 2).

Note: Many MCU architectures have a single "Deep Sleep" mode that includes some features of the EFM32’s EM2 and EM3 energy states.

Figure 2: EFM32 Family’s Energy Mode Transitions. Courtesy of Energy Micro.

Sleep/Standby – (Known as "EM1" for the EFM32) – Enables quick return to active mode (usually via an interrupt) at the expense of a little higher power consumption. In this mode:

• The high- frequency clock MCU oscillator remains running but the CPU clock tree is disabled. This enables the CPU to resume executing instructions on the next clock cycle following the wake-up trigger.
• The high frequency peripheral clock trees are active, allowing high-speed peripherals such as DMA, high-speed UART/USART, ADC/DAC, and AES encrypt/decrypt to function autonomously.
• The 32.768 kHz low-frequency oscillator stays on, allowing low-speed peripherals to remain operational.
• The MCU's pointer and configuration registers' states are preserved, eliminating the need to Save on power-down, or Restore on Power-Up. Keeping the register contents intact typically saves hundreds to thousands of instruction cycles for each wake-up.
• Random access memory remains active and can be accessed by the DMA.
• Power consumption: EMF32 = 45 μA/MHz; Typical equivalent 32-bit MCU = 200 µA
• Time to return to active mode: EMF32 = 1 clock cycle.

Deep Sleep – (Known as "EM2" for the EFM32) – Leaves the MCU’s critical elements active while disabling high frequency system clocks and other non-essential loads. In this mode:

• The high frequency MCU oscillator is off.
• The 32.768 kHz low-frequency oscillator used to clock on-chip peripherals remains on, allowing selected low-energy functions to remain operational. (This includes the LCD Driver, RTC, Watch Dog Timer, Low-Energy UART (LEUART), Touch Sense Interface, and the I2C/USB busses).
• Power-on Reset, Brown-out Detection circuits also remain active.
• Full retention of RAM and CPU registers allows MCU to return to active state quickly and resume the program quickly.
• Power consumption: EMF32 = as low as 900 nA (with RTC running from a precise clock source)¹ ; Typical equivalent 32-bit MCU = 10 μA to 50 μA.
• Time to return to active mode: EMF32 = 2 µs; Typical equivalent 32-bit MCU = 5 µs to 8 µs.

Stop – (Known as "EM3" for the EFM32) A deeper version of Deep Sleep Mode which enables further power savings while retaining limited autonomous peripheral activity and fast wake-up. In this mode:

• The high- and low-frequency oscillators are disabled.
• The MCU’s pointer and configuration registers’ states are preserved.
• Full contents of RAM are retained.
• Power-on Reset, Pin reset EM4 wakeup and Brown-out Detector remain active.
• The CPU can be woken-up by an asynchronous external interrupt or several internal sources including, its analog comparators (ACMP), pulse counter (PCNT), and when addressed by an I2C master.
• The EFM32 retains full internal memory in both EM2 and EM3 states, while memory is lost in some comparable MCUs.
• Power consumption: EFM32 = 0.59 μA; Typical equivalent 32-bit MCU = 10 μA to 30 μA.
• Time to return to active mode: EMF32 = 2 µs; Typical equivalent 32-bit MCU = 5 µs to 8 µs.

Off – (Known as EM4 or "Shutoff Mode" in the EFM32) – This "near-death" state preserves the minimum compliment of functionality needed to trigger wake-up from an external stimulus. The energy savings come at the cost of a significantly longer wake-up time. In this mode:

• All functions and clocks are powered down, except for interrupt monitoring circuitry on the Reset pin, GPIO pin wake-up, and a Real-Time Counter.
• Restart requires device reset or interrupt and a cold-start MCU core and the high frequency RC oscillator which must power-up and stabilize before the CPU can execute its first instruction.
• Like most MCUs, the EFM32’s registers, and the main memory contents are lost and must be re-loaded. However, the EFM32 includes a 512-byte memory block that is retained even in this state.
• All device configuration information is lost, except for GPIO pin assignments.
• Power consumption, EFM32 = 20 nA (400 nA with RTC running); Typical equivalent 32-bit MCU = 1.5 µA.
• Processor’s time to return from Shutdown to Active mode: 160 µs for EFM32.

Backup Battery Mode - A unique Energy Micro feature. This mode offers an attractive alternative to Shutoff Mode which preserves a few more critical functions and enables a much faster wake-up. It is typically used only if the main power supply fails and the system is on backup power. In this mode:

• The RTC remains active.
• A selected 512-byte block of the CPU’s RAM is retained.
• The MCU draws only 400 nA – An Energy Micro EFM32 MCU in this mode would take roughly 7 years to consume roughly 25 percent of the capacity of a pair of AA cells (de-rated to 1000 mAh each).
• Although typically used for backup/battery change operation, EM3A may be an excellent alternative to Shutoff Mode for some applications.

Which sleep mode?

Once the wake-up times and power levels for each of the MCU’s Sleep Modes are understood, it’s relatively easy to find the one that provides maximum power savings while ensuring that your design will be able to respond quickly enough to real-time events. The selection process involves taking a close look at several aspects of the target application, your system, and the MCU that powers it. As an example, we’ll use a battery-powered module that monitors the conditions a cargo shipping container experiences during transport (Figure 3):

Figure 3: This commercially-available cargo container monitor mounts on the container’s main door. It uses a low-power MCU to record GPS coordinates, temperature (optional), shock/vibration, door openings, and events that might indicate tampering. Courtesy of Starcom Systems.

1. List all the alarm/alert conditions generated by the application and identify the one that has the shortest time it can tolerate before it is attended to.

   The container monitor is typically equipped with a GPS receiver, temperature sensors, contact switches to detect tampering, and accelerometers to measure the bumps, jolts and shocks that occur along the way. It is also usually equipped with one or more radio interfaces, according to the application’s requirements.

   Under normal circumstances, the MCU will remain in sleep mode most of the time, emerging for a few milliseconds every 10 or 15 minutes to record temperature conditions. Activity from the tamper detect switches does require attention in real time but the window of timely response to that event is measured in hundreds of milliseconds or even seconds. The processor must, however, be able to wake up and begin measuring shock and vibration levels within a millisecond or less of the time its accelerometer inputs exceed a pre-programmed threshold level.
   
   

2. For each Standby, Sleep, and Deep Sleep mode, add up all the delays involved between the time the Alert or Alarm condition is generated and the time the MCU is ready to begin attending to it.

   Continuing with the example of the shipping container monitor, we can assume that the accelerometer sense/comparator circuitry has little or no delay but, depending on the sleep mode it’s in, the MCU will experience delays of a few microseconds to hundreds of milliseconds before it can begin paying attention to the alarm event that woke it up.
   
   

3. Add in the execute time of the code required to service the Alert/Alarm condition to get the total delay between a critical event and the time the MCU responds.

   The length of this part of the application code will vary widely from application to application. It will also depend on whether the MCU must go through an interrupt service routine (ISR) or jump directly to the code that deals with the event at hand. Compare the maximum response time of each Sleep Mode and identify the lowest-power mode that falls within the application’s maximum tolerable delay.
   
   

4. Verify that the Sleep Mode you’ve selected has the resources you require. For example, if the application requires an RTC, it cannot go below Deep Sleep.

If the Sleep Mode you’ve selected does not provide the needed battery life, there are several other techniques you can use to fine-tune your design which will be covered in the next section.

Other strategies for minimizing cpu activity

As important as they are, Sleep Modes are only one variable in the power management equation. Like any complex equation, how Sleep Mode is used for a particular solution is dependent on its companion variables. The strategies listed below are a sampling of how these other variables can be used to take best advantage of an MCU’s sleep modes.

• Identify the routine low-level functions your application will require and identify MCU architectures that can handle as many of them as possible using on-chip hardware which does not require CPU intervention. Besides the counter/timer/RTC functions, found on most MCUs, some advanced architectures (including Energy Micro) handle:
  • A/D conversions and autonomous data collection
  • Monitoring alarm thresholds (analog and digital)
  • Hardware accelerated encryption/decryption
  • Display control/refresh
  • Touch screen management
• If the MCU you use can conduct memory transfers and other transactions between internal and external peripherals autonomously, be sure to take advantage of it. For example, an I2C bus transceiver or UART that can autonomously receive and buffer packets to memory, allows the MCU to remain in sleep mode until action on the incoming messages is actually required. Some MCUs’ peripherals require external hardware or CPU intervention.
• If your MCU is based on the ARM Cortex architecture, you can shorten CPU response time by using an optional configuration that lets the CPU wake-up on an interrupt request and jump directly to the application code. Jumping past the interrupt service routine (ISR) cuts 12 clock cycles from the MCU’s response time along with any other code overhead associated with the ISR.

Selecting a processor clock speed that’s appropriate to your application is another tool that can be used to fine-tune both the design’s operating power and the time it spends in Sleep Mode. In many cases, the processor speed that results in the lowest overall energy use may not be the slowest clock speed.

The idea of running a device faster to conserve energy may seem counter-intuitive, but a semiconductor’s energy consumption is the sum of its static consumption (which is present regardless of clock frequency) and its active consumption (which increases with operating speed (MIPS/μW)) usually declines as clock frequency increases. So, if we assume that doubling the clock frequency means cutting the time it takes the CPU to complete a task (Figure 4a) by half or more, the increase in dynamic power is offset by the reduced processing time while the static power consumption applies for a shorter period and will be cut roughly by the same percentage (Figure 4b).

Figure 4: Using a faster clock speed to reduce an MCU’s execution times can reduce its overall power consumption.

Additional power savings can often be achieved by maximizing the transmission speeds of your wired and wireless links. This is because PHYs for many wired (power line, Ethernet, etc.) and wireless (Wi-Fi, ZigBee, etc.) often consume as much or more power than the MCU itself. Unless there are other considerations (such as longer link negotiation times at higher transmission rates), the transceiver’s power consumption can be minimized by insuring the processor’s clock speed is sufficient to allow it to handle data at the transceiver’s maximum available transmit/receive rate.

RTOS issues

Most applications discussed here use a "Main Loop"-style architecture with time-critical subroutines driven by interrupts generated by the real-time clock or peripheral I/O elements. Some embedded code is still written at the assembly level but more capable MCUs, improved compilers, and advanced software tools are making it possible to program many applications in C/C++ or similar high-level languages.

There is also a growing number of low-power designs which use a real-time operating system (RTOS) to tame potentially unruly applications by insuring deterministic response to both scheduled and unscheduled events.

Both C and RTOS offer advantages for real-time embedded applications including simplified development and code that tends to be more robust. The resulting code’s structure also enables stable code modifications for future upgrades. Finally, the well-defined layers and interfaces afforded by an RTOS allow it to employ useful middleware such as network stacks and I/O drivers.

Despite these advantages, RTOSs also have some issues that have kept them from being more widely used in the lightweight, power-constrained environments common to the applications discussed here. Most obvious is that an RTOS usually requires 32-bit MCUs which typically require a much larger energy budget than the 8- or 16-bit MCUs that are commonly used in these applications.

Running an RTOS also raises concerns about whether it requires the use of hardware blocks within the MCU (such as timers or real-time clocks) which may not be available in its deeper sleep states. Most RTOSs offer limited or no support for Sleep Modes but there is a small, but growing number of products that are Sleep Mode-friendly, including AVIX-RT and FreeRTOS.

AVIX boasts one of the fastest benchmark scores in the industry, low latency, and a very light memory footprint. It can be used on most MCUs which are built around the ARM Cortex-M3 32-bit processor as well as several other processors but it has been specially optimized to make full use of the EFM32’s low energy modes.

FreeRTOS is an open-source, cross platform operating system standard for microcontrollers that supports 28 architectures and 17 tool chains. It is free to download, and free to deploy and can be used in commercial applications without any requirement to expose your proprietary source code. It is also available as OpenRTOS, a commercially licensed and supported version that includes fully featured professional grade USB, file system and TCP/IP components.

While both RTOS products support multiple MCU architectures, Energy Micro’s EFM32 family has several architectural features that help them make optimum use of its low-energy modes which will be discussed in the following section.

The Energy Micro advantage

Most of the techniques and design practices covered so far can be applied to any MCU designed for use in energy-constrained applications. In this section, we will take a closer look at some of the special features in Energy Micro’s EFM32 architecture that make it the most energy-friendly MCU for both traditional and RTOS-based embedded applications.

All members of the EFM32 family are equipped with a rich compliment of analog and digital peripheral elements (Figure 5). Most of these elements are so-called Autonomous Peripherals (APs) which can function without CPU intervention and remain active in one or more Sleep Modes. This contrasts sharply with most MCUs, whose lowest energy-saving modes only support very basic keep-alive functions such as GPIO wake-ups and RTC operation.

Figure 5: This annotated block diagram of the EFM32 MCU illustrates how many of its peripherals remain available in each of its low-power modes. Courtesy of Energy Micro.

In addition to the counters/timers, ADCs/DACs GPIO and serial communications found on most MCUs, Energy Micro’s compliment of APs includes:

• Capacitive Sense Processor – senses touch pad contact and coordinates within an n-by-n grid (up to 16 points) without CPU. Remains active down to the EM2 energy mode.
• LCD driver – can drive numeric LCD or TFT display via DMAs from memory without CPU.
• Analog Comparators –enable monitoring of threshold voltages for alert/alarm conditions without CPU intervention.
• Low Energy UART (LEUART) with DMA can remain in EM2 while receiving a large amount of data without waking up the CPU.

The activities of most peripheral functions, including serial communications, counters/timers, analog and digital comparators and higher-level I/O are coordinated by a separate low-power Reflex Bus. Events and signals from one peripheral can be used as input signals or triggers by other peripherals and ensure timing-critical operation and reduced software overhead. These advanced features enable Energy Micro’s EFM32 family of MCUs to bring the computational power of a 32-bit device to an application while consuming only as much (and often less) energy as a typical 16-bit product.

The EFM32 also contains features that allow an RTOS to run in an efficient manner and make the best use of its energy-saving Sleep/Deep-Sleep modes. Some of the most important features include:

• Many of the EFM32’s clocks and counters are available in its Sleep (EM1), Deep Sleep (EM2), and Stop (EM3) Modes, including a Backup Real-Time Clock. This greatly reduces the amount of processor overhead the RTOS has to use to maintain its timing references.
• Retention of active memory, CPU pointers, and configuration registers in Sleep (EM1), Deep Sleep (EM2) and Stop (EM3) Modes dramatically reduces the time and code overhead required for the MCU’s return to its Run (EM0) mode.
• The lighter code and faster execution speed enables an RTOS to operate transparently to the application.
• Even with the inevitable added overhead imposed by RTOS, the EFM32’s 32-bit RISC core enjoys faster execution and enhanced sleep mode features greatly reduce the time it spends in its active mode. In many applications, these features allow it to enjoy a total energy budget that’s equal to, or less than many 16-bit MCUs.

Conclusions

Achieving maximum battery life for your embedded system will still require some trial-and-error, but the techniques described in this article can help minimize the time it will take to find the right balance between real-time responsiveness and energy savings that’s right for your application. Most of what’s been illustrated here can be applied to any of the low-power MCUs available on the market today but Energy Micro’s EFM32 Gecko series offers a combination of fast wake-up, low power consumption and high levels of functionality in all modes that make it a superior choice for many applications.

Hopefully, this article has also whetted your appetite for using an RTOS in low-power embedded applications. While not all applications will benefit from an RTOS, Energy Micro’s advanced architecture ensures that power consumption is no longer a barrier for designs which require the stability, manageability and deterministic performance that an RTOS offers.

Footnotes:

1. Stand-by current for the EFM32 in Deep Sleep (EM2) mode was measured under the following conditions: Power supply = 3 V, Ambient temp = 25 degrees C.
   
   Typical operating current was measured for the complete microcontroller and any external oscillators, including the RTC (running on the internal precision oscillator), with brown-out detection, full RAM and register retention active. Current in Deep Sleep (EM2) RTC mode was measured with the RTC running from the internal 32 kHz low-frequency oscillator.