Power Manager#

Overview#

Power manager is a platform-level software module that manages the system's energy modes. Its main purpose is to transition the system to a low-energy mode when the processor has nothing to execute. The energy mode the system will transition to is determined each time the system goes to sleep using requirements. These requirements are set by the different software modules (drivers, stacks, application code, etc.). Power manager also ensures strict control of some power-intensive resources, such as the high-frequency external oscillator (commonly called HFXO or SYXO). Power Manager also offers a notification mechanism through which software module can be notified of energy mode transitions via callbacks.

Energy Modes Overview#

As a general rule, the following energy modes are available. The description provides an overview of the functionalities lost compared to the previous energy mode.

The EM2 and EM3 energy modes have been merged because, starting with series 2 devices, the low-frequency oscillators are no longer automatically shut down in EM3 as they were on series 0 and 1 devices. When entering deep sleep, the EMU hardware module evaluates which modules (including oscillators) in PD0 are active and powers down as many of PD0's subdomains as possible where no modules are enabled. To maximize the power saving and reach the EM3 power numbers, peripherals can be disabled or need to run on ULFRCO. Refer to your device's reference manual to see which modules are in which PD0's subdomains.

The EM4 energy mode has been omitted from this list as it is provided through separate functionality from the other energy modes. See Entering EM4 for more details.

When the system transitions to a low energy mode, it can be awakened to EM0 through interrupts. Upon an interrupt, the system returns to the highest energy mode (EM0). However, if the system was in a deep sleep mode (EM2 or EM3), it may not fully restore all resources immediately upon waking. For detailed information, refer to the Waking up from sleep section.

For more information on the different energy modes, refer to your device's user manual.

Power Manager Design Considerations#

Power manager acts as the intermediary between the various software modules and the device.

Any piece of software can interact with power manager. There are two main interfaces, as described below.

Requirements#

APIs allow you to add and remove requirements on energy modes. Requirements should only be added and removed on EM1, since the system will automatically enter deep sleep in the absence of EM1 requirements. Refer to your chip's reference manual to determine what operations are possible in each energy mode.

The normal use case for these APIs is to add an EM1 requirement before starting a given operation (using one or more peripherals) requiring a high-frequency clock and removing this requirement once the operation is completed. The more efficient and refined your operations and add/remove requirements blocks are, the more power-efficient your application will be.

For example, when transmitting data on a USART, the system can go to sleep. However, it can only sleep in EM1 mode as otherwise the USART would stop working. The correct way of handling this is to add a requirement on EM1 when the transfer is set up, and remove the requirement on EM1 once the transfer complete ISR is triggered.

The requirements are added and removed via the following APIs:

void sl_power_manager_add_em_requirement(sl_power_manager_em_t em);
void sl_power_manager_remove_em_requirement(sl_power_manager_em_t em);

You must always call the functions sl_power_manager_add_em_requirement() and sl_power_manager_remove_em_requirement() as a pair. If you omit to remove a requirement previously added on a given energy mode, that will cause your application to be unable to sleep to a lower energy mode.

You can add and remove requirements from ISR. This is useful to perform a full restore of the different clock sources when waking-up from a deep sleep energy mode (more information on that in the Waking up from deep sleep section). Upon return from a function call to sl_power_manager_add_em_requirement(), power manager guarantees that all resources related to the requested energy mode are fully restored and available. You should however add requirements from an ISR only when this is absolutely necessary, as this can impact power consumption and interrupt latency.

Note that software provided by Silicon Labs as part of the different SDKs has, for the most part, a proper and efficient integration with power manager. You don't have to add and remove requirements for operations performed by these SDK functions unless stated otherwise in the module's user manual.

Notifications#

Power manager offers a notification mechanism. This mechanism allows any piece of software to be notified of any energy mode transition. When transitioning from a high energy mode to a lower one (for example, from EM0 to EM2), the listeners are notified before the transition. When transitioning from a low energy mode to a high energy mode (from EM2 to EM0, for example), the listeners are notified after the transition is completed. The main purpose of these notifications is for the different software modules to "adapt" to the new energy mode applied. For instance, a given software module may not need to have a requirement on EM1 to perform a given operation, but may have to do some modifications to continue to perform its operation in EM2. These modifications can be applied in the notification callback. You must use these notifications from your application if you need to perform such operations. Note that the notifications may be called from an ISR context.

The following API is available to subscribe to notifications. The events to subscribe to are configurable.

void sl_power_manager_subscribe_em_transition_event(sl_power_manager_em_transition_event_handle_t     *event_handle,
                                                    const sl_power_manager_em_transition_event_info_t *event_info);

Note that it is not possible to add and remove requirements from a notification.

The Process of Entering a Sleep Mode#

When Using an Operating System#

When your application uses an Operating System (Micrium OS kernel or FreeRTOS, for example), the process of going to sleep is fully handled by the OS. The system will automatically enter the lowest possible energy mode (depending on the requirements currently set) when the OS enters idle mode (i.e. when all the tasks are pending on something, delayed or suspended). Power manager will ensure the system resumes its operations as soon as a task is resumed, posted or that its delay expires.

Baremetal Applications#

When on a baremetal environment, the process of bringing the system into sleep is your application's duty. You are required to call a function named sl_power_manager_sleep() when your application is idling. Once you call this function, power manager will enter in a sleep loop and won't exit this loop until a system wake-up is requested after an ISR. Two entry points to this sleep loop are provided and used by power manager to determine if it is safe to enter/return to a low energy mode. These entry points are implemented as function callbacks. Power manager offers a contributions mechanism, as multiple different software modules can contribute to the decision. The software provided by Silicon Labs offers a full integration by contributing to these callbacks when needed.

Two fixed functions are available for your application to implement and contribute to these two entry points decision:

• app_is_ok_to_sleep()

• app_sleep_on_isr_exit()

Waking Up from Sleep#

The device wakes up from sleep when an interrupt occurs, transitioning the system back to the EM0 energy mode where the CPU resumes code execution and processes the interrupt's ISR. However, the system's state during ISR execution will vary depending on the energy mode the system was in during sleep. For instance, if the system was in EM1, it will be fully restored upon ISR entry. In contrast, if it was in a deep sleep mode (EM2/EM3), some clock sources may not be immediately restored, depending on the wake-up source and system requirements.

Waking Up from Deep Sleep#

When waking up from deep sleep and when possible, the device will only restore a fast startup RC oscillator to provide a high frequency clock source for the CPU for the ISRs execution. The reason being that the process of restoring all the clock sources can be time-consuming and requires energy. Depending on the operation that needs to be performed in these ISR, having only one RC oscillator clocking the CPU may be sufficient. It is more energy efficient to not restore all the clock sources in the cases where an ISR with simple processing is executed, and the system can get back to a deep sleep mode.

See the sections Synchronous events and Asynchronous events for more information on the events that cause a full clock sources restore by power manager. Note that when the system gets back to thread mode (if an OS task is posted or if a decision to wake-up is taken using the sleep_on_isr_exit entry point in a baremetal application) power manager will always perform a full restore before.

Following table provides examples of clock sources that are not always automatically restored when waking up from deep sleep.

Synchronous Events#

Synchronous events are real-time timed events that are expected to occur in the future. Processing these events will require a full restore of the clock sources. Since the process of restoring the clock sources can be time-consuming, power manager will ensure it wakes up in advance and proceeds with a full restoration of the clock sources to be ready in time to process the synchronous event. When the Sleeptimer uses the SYSRTC timer peripheral, the Peripheral Reflex System (PRS) will be used to schedule advance wake-ups for the Power Manager. The PRS channels 1 and 2 will be used by the sleep timer and become unavailable. For more information on sleep timer hardware clocks configurations, refer to the Sleeptimer user manual.

To register an event that will be considered as synchronous by power manager, you must use the timer functionality provided by the Sleeptimer module. Any timer (periodic or one-shot) created with the argument option_flags set to 0 will be considered as a synchronous event that requires a full restore of the clock sources on expiration. If you create a timer with the option flag SL_SLEEPTIMER_NO_HIGH_PRECISION_HF_CLOCKS_REQUIRED_FLAG, you won't have a guarantee that all the clock sources will be restored on expiration. For more information on how to create a timer, refer to the Sleeptimer user manual.

Asynchronous Events#

Asynchronous events are any other events (ISRs) that occur in the system. Those events are unexpected by their nature. When they occur and the system was deep sleeping, the High Frequency clock sources are not guaranteed to be restored. As for normal operations, if you need to perform or initiate an operation that requires some specific clock sources from your ISR, you must add a EM1 requirement to force a restore of the High Frequency clock sources. If you add a requirement on EM1, upon return of the function sl_power_manager_add_em_requirement() the high and low frequency clock sources are guaranteed to be available and ready.

Note that a call to sl_power_manager_add_em_requirement() that triggers a high frequency clock restore will take some time to execute and will stop the CPU for some time. If this is a problem for your application, consider making sure that a requirement on EM1 is added before entering sleep mode.

The time required to restore the clock sources depends on many factors. Refer to your device's datasheet and user manual for additional details.

Tips and Tricks to Optimize Your Power Consumption with Power Manager#

Refine your requirement blocks as much as possible#

You may be tempted to have a very broad coverage of operations between the moment you add a requirement and the moment you remove it. While this offers some simplicity benefits, this is not very efficient. In order to achieve better power consumption, the periods where a requirement is added must be as small and as refined as possible. This will avoid cases where the system enters sleep mode in a high energy mode when it could enter a lower one.

Fine tune the restore time overhead#

As described earlier, restoring the clock sources (especially the high-frequency clock sources) can be time-consuming. Since this restore time can vary depending on many factors (external crystal type, ambient temperature, etc.) power manager implements a mechanism to measure the time required to restore certain high-frequency clock sources. This restore time is used when deep sleeping to trigger a clock sources restore in advance in expectation of an upcoming synchronous event. In order to maintain real-time responsiveness of your application, it is vital to have a restore time that is not too short, as that would cause the clock sources not to be ready on time. For that reason, power manager always adds a safety margin to the restore time it measures. However, since the system consumes more power when these clock sources are restored, the shorter this restore time is, the better the energy consumption will be. The functions sl_power_manager_schedule_wakeup_get_restore_overhead_tick() and sl_power_manager_schedule_wakeup_set_restore_overhead_tick() are offered to fine tune this safety overhead.

Please note that, due to hardware limitations on series 2 devices supporting EM1P energy mode, the power manager is not always able to measure the high-frequency clock restore time. Since the default restore time includes a large margin, the restore time may be longer than needed. Therefore, if higher power consumption than expected is observed, sl_power_manager_schedule_wakeup_set_restore_overhead_tick() can be used to reduce the restore time by passing a negative overhead.

Entering EM4#

Power Manager is responsible for initializing the Energy Management Unit (EMU) which offers EM4 support. Support for EM4 is provided through separate functionality from the other sleep modes, as the Power manager will never take the decision to enter this energy mode.

As described in this document, the power manager bases its decisions of sleeping in a given energy mode on requirements that are added and removed by the different software modules. Given the very different nature of EM4, this approach is not well-suited for making a decision to enter this energy mode. Most of the time, when the decision is made to enter EM4, the sleep period will be fairly long, and the wake-up source will be quite basic (e.g., GPIO interrupt, low energy timer compare match, etc.). As such, in most circumstances, your application is in the best position to take this decision.

A good approach for your application is to enter EM4 when power manager is about to enter a low-energy mode. This is possible by subscribing to a notification of entering a low energy mode (see Notifications for more details). In this notification callback, you can evaluate if you want to enter EM4 instead. To enter EM4, you can simply call the function: sl_power_manager_enter_em4(). Keep in mind that waking up from this energy mode will result in a system reset. Restoring previous states after wake-up is the responsibility of your application. Refer to your device's reference manual for more information on the EM4 energy mode.

Additionally, the Power Manager provides support for EM4 pin retention. Use the SL_POWER_MANAGER_INIT_EMU_EM4_PIN_RETENTION_MODE configuration to set the pin retention mode in EM4. When enabled, pins retain their state through EM4 entry and wake-up. The retained pin state can be released after wake-up by calling the sl_power_manager_em4_unlatch_pin_retention() function.

Be aware that entering the EM4 energy mode will abort any operation that requires a higher energy mode. If, for example, you need a transfer to complete on the UART via DMA before entering EM4, you must wait for its completion. This can be achieved by polling the STATUS register of the controller.

Execution Modes#

The Execution Modes feature is available on Series 3 devices, which can be enabled by setting the configuration SL_POWER_MANAGER_EXECUTION_MODES_FEATURE_EN. When this feature is active, the system can dynamically switch between Standard and Performance modes during normal execution in EM0.

Performance mode typically increases the system clock frequency, providing enhanced performance at the expense of an increased power consumption. The exact specifications and behavior of Standard and Performance modes are device-specific.

Although it is generally not recommended to keep Performance requirements when entering sleep, since entering sleep would indicate that the application doesn't require performance at this stage, the Power Manager ensures that the same Execution Mode as before sleep is restored upon waking-up.

To manage these modes, use the following APIs:

• sl_power_manager_add_performance_mode_requirement(): Add a requirement on the Performance mode. If no previous requirement were added, this will activate the Performance mode.

• sl_power_manager_remove_performance_mode_requirement(): Remove a previously added requirement. If the last requirement is removed, this will deactivate the Performance mode and restore the Standard mode.

SIXG301 Devices#

On SIXG301 Devices, enabling the SL_POWER_MANAGER_EXECUTION_MODES_FEATURE_EN config will override the SL_CLOCK_MANAGER_SYSCLK_SOURCE config in Clock Manager.

The HFRCODPLL and SOCPLL settings used for the different Executions Modes will be based on the oscillators' configuration in the sl_clock_manager_oscillator_config.h files.

SIXG301 Device Sleep Specificities#

The SIXG301 device is unique among Silicon Labs devices as it does not support EM2/EM3 deep sleep mode. When the system enters sleep, it transitions only to EM1. In this mode, the high-frequency clocks remain active, and the PD1 power domain stays powered on during sleep.

To optimize power savings, the Power Manager differentiates between two types of EM1 sleep:

1. EM1 with requirements: Entered when EM1 requirements are present.

2. EM1 without requirements: Entered when no EM1 requirements are present, indicating the system would be ready for deep sleep (EM2/EM3) on series 2 devices. In this case, the Power Manager assumes no high-frequency modules are actively in use and automatically maximizes the HCLK branch divider to reduce power consumption further.

An additional feature is available to enhance power savings when entering EM1 sleep without requirements, which is by default enabled:

• SYSCLK Switching: Enable the SL_POWER_MANAGER_SYSCLK_SWITCH_TO_HFXO_IN_SLEEP_EN configuration to switch SYSCLK from SOCPLL to the HFXO source upon sleep entry. SYSCLK will automatically switch back to SOCPLL upon waking. Note that SOCPLL requires approximately 36 µs to lock when resuming from sleep.

For additional power savings, the QSPI clock can be switched between its default PLL-based clock to a RCO-based clock. The Clock Manager module provides the sl_clock_manager_get_ext_flash_clk() and sl_clock_manager_set_ext_flash_clk() APIs, allowing the application to retrieve and modify the QSPI clock source at runtime. Note that switching the QSPI clock source requires approximately 300 µs, which is a non-negligible delay. Adjusting the QSPI clock source can impact the overall application performance by altering the external flash communication speed. Therefore, it is recommended that the application, having a comprehensive understanding of its operational requirements, determines the appropriate timing for such changes.