Simplifying Power Management for MCU-Based IoT Nodes

More IoT apps, more battery-powered connected sensors and actuators. And more than time for silicon’s advanced power management features to be matched by a software layer that makes it easy to use these features.

The Internet of Things (IoT) is triggering a mass deployment of low-cost sensors or actuators in many different markets, ranging from smart homes to smart energy, transportation and industrial applications. Many of these applications will require sensors and actuators (IoT nodes) to run for months or years on coin cell or AA batteries. In these cases, energy efficiency is a significant challenge for developers.

In desktop computers and smartphones, the operating system (OS) controls power-saving activities such as dimming displays or shutting down the hard drive after periods of inactivity. These devices are based on sophisticated, high-level operating systems such as Windows, Linux® or Android™, which require high-performance and power-hungry processors. To achieve the long battery life and low-cost requirements of many IoT nodes, it is necessary to implement systems based on low-power microcontrollers (MCUs) with limited on-chip memory, precluding the use of high-level operating systems. Bringing similar easy-to-use and effective power management to MCU-based IoT platforms has become much more important for three reasons:

The silicon processes used in recent generations of MCU products result in significantly more power leakage compared to devices built using older CMOS processes. To optimize the energy efficiency needed for IoT nodes, semiconductor vendors have had to design more sophisticated power management features. Providing a traditional low-level software interface to these silicon power management features creates a steep learning curve for developers, making it unlikely they will properly exploit all the benefits.

Achieving optimal energy efficiency now requires using more complex power-down modes, where much of the MCU—CPU, peripherals and memory—is shut down or power cycled. The silicon vendor must not only provide system-level functions that implement these ultra-low power modes to insulate the user from device-specific complexities, but also a complete power management frame that addresses issues such as maintaining a reliable time base in applications that spend long periods in sleep modes.

Many developers of IoT applications lack embedded software development experience. To be successful, they will need a power management paradigm much closer to what is available in Windows or Linux, where one can select a specific power-down mode or have the operating system actively manage power.

This article will examine a power management framework that has been deployed in an embedded operating system. This framework, subsequently referred to as ‘OS power manager,’ automates almost all power management decisions and enables developers to build energy-efficient IoT nodes without having to learn any aspects of the silicon power management features. Since the implementation of an OS power manager is dependent on the power management capabilities present in the silicon, we will begin with an overview of some hardware power management features that may be present on typical low-power MCUs.

In-Hardware Power Management Features

It is helpful for embedded software developers to have a basic understanding of the underlying hardware features that assist in effective power management since the OS power manager will need to exploit these hardware resources:

Clock gating: Clock gating allows the clock to be turned off for a particular peripheral, thereby reducing the power it consumes.

Power domains: While disabling the clock to a peripheral eliminates most power consumption, there may be some power drain due to leakage. To prevent leakage, the MCU can implement power domains to completely shut off power to a particular circuit. Unlike clock gates, which will usually be specific to one peripheral (e.g. UART1), a power domain typically controls multiple peripherals, such as all the UARTs or all the serial I/O peripherals.

Wake-up generator: To implement very aggressive low-power modes, both the CPU and virtually all the peripheral domains are powered down. Since interrupts can’t normally reach the CPU in these circumstances, additional “always on” logic is required to enable a subset of peripherals to wake up the CPU.

CPU-independent high-resolution timer: Most embedded applications have some time-driven events, which make it essential that an accurate time base can endure across power saving modes. This requires a timer to be kept active while the rest of the MCU is powered down and must have sufficient resolution to maintain a 1ms or less tick count and sufficient width to avoid rollovers during periods of deep sleep. The needed resolution and width will depend on the CPU clock rate and how long the application will sleep.

Fast wake-up time and appropriate run-time performance: Although not explicitly used for power management, the MCU’s ability to wake up quickly, complete its tasks quickly and return to a low-power mode is critical to maximize time in low-power states. Key design choices include having high-frequency clock sources stabilize quickly and selecting the right CPU speed and performance.

“CPU Active” Power Management Techniques

Minimizing power consumption while the CPU is active requires reducing the power consumed by peripherals such as serial ports and radios. To do so, the OS power manager uses the clock-gating and power domains designed into the MCU silicon. Leveraging this hardware requires knowing when a particular peripheral is in use or not. The OS and its device drivers track peripheral behavior. Each device driver declares a dependency when it needs to use a peripheral. For example, when a SPI driver is invoked, it declares a dependency to the OS power manager on the specific SPI port (e.g. SPI2). The OS power manager enables the clock gate and power domain that are associated with SPI2, if they are not already enabled. When the driver completes execution, it informs the OS power manager to release the dependency on the SPI2. The power manager maintains a database of dependency counts on the clock gates and power domains. Whenever the dependency count for a clock gate or power domain goes to zero, the power manager disables them to reduce power. These peripheral power downs are done during system run-time and enhance energy efficiency.

Maximizing CPU Power Mode Efficiencies

In many IoT nodes, it is common for the low-power MCU to spend much of its time in some form of sleep mode. To maximize energy efficiency, it is critical to not only maximize the amount of time spent in sleep modes, but also utilize MCU-specific ultra-low-power modes where possible. These modes go well beyond putting the CPU into a sleep state and may even power down peripherals and power-cycle memories. It is essential to have a real-time clock or high-resolution timer kept alive across power downs to ensure proper functioning of the application’s time-based functions. As an example, the real-time clock is part of the “always on” hardware in wireless MCUs available from Texas Instruments, so the application always has access to it. However, in other silicon implementations, it may be necessary for the power manager to specifically keep a timer or clock alive. There are a number of different techniques that can be utilized to ensure efficient use of sleep modes.

Tick Suppression

Embedded applications typically employ a regular timer interrupt as a ‘heartbeat.’ This timer interrupt is used as the basis for calculating when any time-based activities should occur such as periodic functions or timeouts. For OS-based applications, this interrupt is known as the system tick, but non-OS applications will have a similar regular timer interrupt.

The chosen tick rate reflects the application’s most granular timing need, but in practice most system ticks will not result in executing a time-driven function. In energy-efficient applications, this creates two problems: unnecessary interrupts consume processor cycles and power, especially if the application requires fine-grained precision, and the application may be woken up from a low-power mode to service the system tick timer interrupt, only to find there is nothing to do. The purpose of tick suppression (also known as tickless operation) is to eliminate system tick interrupts that are not associated with an action.

Although it is possible to provide APIs for the user to implement tick suppression in the application, it is preferable to make tick suppression transparent to eliminate complexity and developer learning curves. This requires changes to core RTOS clock functionality. For example, developers had to re-implement the clock module in TI-RTOS so it automatically tracked the number of ticks until the next time-based activity in the application. Once the OS can easily obtain when the next time-based activity will occur, it can automatically suppress system timer ticks by reprogramming the timer to interrupt only when the next event occurs, rather than on a regular periodic basis. As illustrated in Figure 1, this approach can eliminate the majority of timer interrupts associated with the system tick.

The core overhead of tick suppression is low, as reprogramming the timer peripheral is simply a register write. A minor side effect is that it may take somewhat longer to execute OS calls that must return tick counts, although this is only on an MCU with poor math performance and very low clock rates. This is because the count must be calculated, as opposed to just returning a count variable that is simply incremented upon each timer interrupt.

Figure 1: Two oscilloscope traces based on TI-RTOS. The top (yellow) trace tracks a timer that is triggering every 1ms for use as a comparison against the bottom (blue) trace, which tracks triggering for a timer used to generate a 1ms system tick. In the screen on the left, the two traces line up as expected. On the right, TI-RTOS tick suppression is enabled, resulting in few interrupts, as they occur only when work is actually scheduled for execution.

Figure 1: Two oscilloscope traces based on TI-RTOS. The top (yellow) trace tracks a timer that is triggering every 1ms for use as a comparison against the bottom (blue) trace, which tracks triggering for a timer used to generate a 1ms system tick. In the screen on the left, the two traces line up as expected. On the right, TI-RTOS tick suppression is enabled, resulting in few interrupts, as they occur only when work is actually scheduled for execution.

A Power Policy Manager

Experience with earlier generations of the OS power manager, which worked on digital signal processors (DSPs) used in the mobile market, demonstrated that developers often failed to use all the capabilities available to them. As a result, their applications were not as energy efficient as they could have been. To address this issue, a program called a power policy manager was developed to provide a simple way to automatically decipher and manage power transitions. Although developers can configure the power policy manager to customize the behavior, it comes with a set of default policies that can be used without the user having to understand significant levels of detail.

When a multitasking-based application has nothing to do, it drops into an idle loop. At this point, the OS invokes the power policy manager, whose role is to determine which low-power mode can be entered. It is always safe to place an ARM® core in a WaitForInterrupt (WFI) state as register contents are maintained and application execution can be resumed with minimal latency. However, since MCU-specific power modes provide exponentially greater power savings, the power policy manager must determine if these can be used. To determine which power modes are applicable, the power policy analyzes constraints, latency and the length of time until the next scheduled event.

A frequent reason for an application to drop into the idle loop is because a task is blocked waiting for peripheral I/O operations to complete. If it is essential for correct system operation to complete the I/O operation, the application must signal this to the OS power manager; it uses a concept called a constraint to perform this communication. Transmitting data over a Bluetooth® low energy or 802.15.4 radio is an example of when setting a constraint is appropriate. An application that is waiting for acknowledgement or data from the wireless network would typically block on a semaphore, potentially resulting in the application dropping into the idle loop and the power policy being invoked. Obviously, it would be inappropriate to place the MCU into a deep-sleep mode that would shut down the radio and CPU because this would cause the incoming Bluetooth low energy packets to be lost. To avoid this, the Bluetooth low energy stack or radio driver can set a constraint while it is operating. When its action is complete, it releases the constraint. The constraint should be limited to only the power-down modes that would impair successful operation. For example, going into an IDLE state (see Table 1 for an example of different MCU-specific power states) may be safe for a particular operation, but going into a STANDBY state may not. The power manager tracks constraints in a relatively similar manner to dependencies, but the power policy manager only checks the former. The assumption is that power-downs can be done regardless of ongoing peripheral activity unless the driver or stack managing a peripheral has set a constraint.

If constraints do not prevent the system from transitioning to a lower power mode, the power policy manager must weigh information from various sources to determine whether it has time to enter (and return from) a particular power mode. Each power-saving mode is characterized by a specific latency that combines the time taken to perform the power-down operation and time required for the MCU to fully wake up and be ready for normal system execution. The power policy manager will compare the latencies of each power mode against the amount of time available before the next scheduled event (e.g. periodic function or timeout) will occur. The power policy will then choose the lowest applicable power mode and program the appropriate wake-up configuration. It programs the wake-up to occur early enough to ensure the processor is completely powered up by the time the next scheduled event occurs. When the MCU transitions to a new power mode, sleep notifications sent to drivers invoke callback functions to shut down the peripheral’s activity. The default implementations of these callbacks are minimalistic and shut down the peripheral as quickly as possible.


Figure 2: A power manager (as shown in TI-RTOS) enables ultra-low-power performance without requiring any user programming. System components, such as device drivers, are power-aware and inform the power manager when it can use more aggressive power modes. The power policy manager combines this information with the knowledge of the next scheduled event to determine which power mode to select.

Power Modes

The OS power manager provides proven implementations of a pre-defined set of power modes for the wireless MCU. These are tested to ensure reliable transitions to and from the mode. There is no need for developers to become experts in a device’s power management features or for engineering resources to develop low-level power management code.

Power modes for an ultra-low-power wireless MCU are listed in Table 1 as an example of those that can be present for an MCU that is power-optimized for an IoT node. As can be seen from the data in the table, MCU-specific power modes are critical to achieve ultra-low-power consumption.

Table 1: Current consumption at various power modes. The wake-up times and current draw are based on TI’s SimpleLink™ multi-standard CC2650 wireless MCU, which combines an ARM® Cortex®-M3 core running at 48 MHz with a Bluetooth low energy radio. In the WaitForInterrupt and IDLE measurements, no peripheral domains were active.

Table 1: Current consumption at various power modes. The wake-up times and current draw are based on TI’s SimpleLink™ multi-standard CC2650 wireless MCU, which combines an ARM® Cortex®-M3 core running at 48 MHz with a Bluetooth low energy radio. In the WaitForInterrupt and IDLE measurements, no peripheral domains were active.

WaitForInterrupt mode simply results in gating the clock to portions of the main CPU. This may be used in any situation as it has virtually no latency. The primary role of the power policy manager is to determine if the IDLE or STANDBY modes can be used, as these greatly reduce power consumption, especially the latter. The WaitForInterrupt or IDLE modes do not power down peripherals. As a result, their actual power usage will vary depending on which peripheral and associated power domains are active.

In STANDBY mode, all peripheral domains are powered down, except for always-on logic used for wake-up generation. The real-time clock in the ALWAYS ON domain is used to keep accurate time while in this state. The device’s SRAM is put in retention mode and the power supply is duty-cycled to further reduce power consumption, while maintaining vital state to avoid losing the contents of registers or memory.

The shutdown mode is primarily used for applications that need to sleep for hours, days or longer. The main advantage of this mode compared to simply turning off the whole MCU is that any pin can be used to trigger the MCU to power back up without the need for additional external circuitry. Since a full shutdown would only be used for very long power downs, the default power policy manager does not use it. The application can invoke it directly if appropriate, or the developer can modify the power policy manager to use it.


With IoT applications fueling an increase in battery-powered connected sensors and actuators, power management has become a critical technology for MCU developers. Advanced power management features implemented in silicon are of limited use unless complemented by a software layer that enables such features to be easily leveraged. The importance of ease-of-use is accentuated in the IoT market, where many developers lack embedded expertise. This article described an RTOS-based power management solution that includes low-level libraries for managing peripheral clocks and domains and transitioning to and from specific power modes. In addition, power-aware drivers enable the OS to understand when specific peripherals may be turned off. Finally, a power policy manager has the intelligence to decide when to transition to a lower power state, eliminating the need for the developer and application to manage such details.

LethabyNick Lethaby is IoT Ecosystem and TI-RTOS product manager at Texas Instruments Incorporated (TI). Lethaby has worked in TI’s Software Development Organization for more than 15 years. His principal focus has been embedded operating systems, including Linux®, Android™ and real-time operating systems (RTOS) for microcontrollers, microprocessors and DSPs. His current focus is on system software for the emerging Internet of Things (IoT). He has a B.S. in Computer Science from the University of London.

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis