Simplifying power management

The Internet of Things (IoT) is triggering a mass deployment of low cost sensors or actuators in many different markets, ranging from smart home to energy, transportation and industrial applications. Many of these applications, agricultural soil moisture sensors, as an example, 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. The operating system used in these devices - Windows, Linux or Android - cannot run on the low cost microcontrollers (MCUs) used in IoT applications due to limited on-chip memory. Bringing similar easy-to-use and effective power management to MCU-based IoT nodes has become much more important for several reasons:

• The silicon processes used in recent MCU product generations result in significantly more power leakage compared to older CMOS devices. To meet the energy efficiency requirements of IoT nodes, semiconductor vendors have had to design more sophisticated power management features that require a greater learning curve for developers.
• 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.
• 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 OS. 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, this article will begin with an overview of some hardware power management features that may be present on low power MCUs.

In-hardware power management features
It is helpful 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 enables 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.
• Wake-up generator: In ultra-low power modes, both the CPU and virtually all the peripherals 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: To maintain an accurate application timebase during long power down modes, the ‘always on’ logic must have a timer with resolution to maintain a 1ms or less tick count and sufficient width to avoid rollovers during periods of deep sleep.
• Fast wake-up time and appropriate run-time performance: The ability of the MCU to wake-up quickly, complete its tasks quickly and return to a low power mode is critical to maximise time in low power states. Key design choices include having high frequency clock sources stabilise quickly and select the right CPU speed and performance.

Automating power management for MCU applications
Experience with earlier generations of the OS power manager, which provided a rich set of APIs to utilise the underlying silicon power management features, demonstrated that developers often failed to use many of the capabilities available to them. As a result, their applications were not as energy efficient as they could have been. To address this issue, an automated approach to power management was developed to effectively place the MCU in ultra-low power states without user intervention.

This automation was achieved by taking an integrated approach to power management that involved enhancements to stacks, device drivers and the OS kernel as they became more ‘power aware’. A power manager was created that contains all the low level routines required to transition the MCU to or from ultra-low power states. In addition, the power manager stores critical data to enable power management decisions to be made, such as the latency associated with a low power mode and whether a particular peripheral subsystem is engaged in a critical data transfer operation. The OS kernel has an inherent knowledge of when events are scheduled to occur in the future. APIs were added to enable applications (including power management software) to query when the next scheduled event would occur. The OS time management was also re-implemented so that timer interrupts would occur only when there was activity to be done, rather than on every clock tick.

Above: This diagram, based on the actual implementation of the TI-RTOS power manager, demonstrates the interaction of different software components, , to enable ultra-low power performance without requiring any user programming.

A program called a power policy manager is configured by default to automatically decide when a power state transition can be made and then manages the transition and wake-up conditions. If desired, developers can reconfigure the power policy manager to customise the behaviour.

When a multi-tasking-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 by analysing constraints, latency and the length of time until the next scheduled event.

An application will often drop into the idle loop when waiting for peripheral I/O operations to complete. If it is essential for correct system operation to complete this I/O operation, the application must signal this to the OS power manager using a concept called a constraint. Transmitting data over a Bluetooth low energy (BLE) 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 invoking the power policy.

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 BLE packets to be lost. To avoid this, the BLE stack or radio driver is enhanced to set constraints around critical operations.

When its action is complete, it releases the constraint. Constraints are typically limited to only the power-down modes that would impair successful operation. For example, going into an IDLE state may be safe for a particular operation, but going into a STANDBY state may not. The power manager assumes that power-downs can be done safely 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 characterised 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 wake-up configuration 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.

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. Power modes for an ultra-low power wireless MCU are listed in Table 1 (below) as an example of those that can be present for an MCU that is power optimised 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.

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.

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 default power policy manager does not use this, but the application can invoke it directly if appropriate, or the developer can modify the power policy manager to use it.

Summary
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. This paper presented an integrated approach to power management software that includes a power policy manager. The power policy manager decides when to transition to a lower power state and selects the optimal low power state, eliminating the need for the developer and application to manage such details.

Nick Lethaby will be presenting at the electronica Embedded Platforms Conference on 11th November.