AN1508: SiWG917 Power Manager Application Note

The Power Manager is a comprehensive solution designed to optimize power usage in SiWG917, helping users achieve better energy efficiency and increased battery life. It incorporates FreeRTOS tickless idle mode, which minimizes power usage by transitioning the SiWG917 M4 into a low-power state when FreeRTOS operates on the Idle task.

This document provides an overview of the key features of Power Manager with tickless idle mode. Additionally, it covers important considerations when working with the Power Manager.

Users of the Power Manager must have comprehensive knowledge of SiWG917 M4 power states. Information about the SiWG917 low-power modes and current consumption in different power modes and power states is available in AN1430: SiWG917 Low-Power Application Note.

1. Power Manager Architecture

The Power Manager is a platform-level service that manages the M4 power states and their transitions when requested by the application. These requirements are set by different software modules (drivers, stacks, application code, and so on).

Application tasks represent tasks running in the application. Users call the Power Manager service APIs from the application tasks.

Power Manager Service Layer interacts with the application layer tasks. It is a layer over the existing internal core API layer, simplifying the process for users to develop their applications.

Middle Layer is a supporting layer for Power Manager service. It validates the power state transitions.

Internal API Layer is the low-level driver that interacts with the hardware layer where register-level configurations are done.

1.1 Features of Power Manager

• It serves as an interface between software modules and the device, offering APIs to efficiently manage and configure the power state transitions of SiWG917.
• The SiWG917 M4 entry into a power state is determined by requirements. Using the requirement APIs, requirements for a specific power state can be added or removed.
• It offers a notification mechanism, providing an option for subscribing/unsubscribing to events during state transitions (e.g., while entering or leaving any state). Based on the subscription, the Power Manager provides notifications through a callback function to the application. The notification events include Power State Transition, exit from sleep, and exit from standby mode. The main purpose of these notifications is for different software modules to adapt to the new power state.
• The Power Manager checks if it is safe to sleep and then enters sleep.
• The clock scaling feature differentiates system clock configuration in PS4 and PS3 active states. It can be switched between performance and power-save. By default, it is configured as power-save at the time of state change.

Note: PS1* check release notes on the current support for PS1 with Power Manager.

1.2 Advantages of Power Manager

Integrating Power Manager into an application is seamless and provides the following configurations. Configurations made in the UC (Universal Configurator) in Simplicity Studio are saved, allowing the Power Manager APIs to be reused as needed.

• Handles peripherals, RAM banks, and wake-up source configuration. Required peripherals can be enabled/disabled to reduce power consumption. This includes enabling RAM retention and powering on peripherals, and setting wake-up sources.
• Provides easy and convenient ways to control all power modes (Active, Standby, and Sleep) as well as supporting all power state transitions (PS4, PS3, PS2, PS1, PS0).
• To prevent race conditions and ensure secure concurrent access, the Power Manager APIs include safeguards such as enabling and disabling interrupts.
• Power Manager uses a sleep timer for precision timing.

Note:

• The state hierarchy ranges from PS4 to PS0, with PS4 being the highest power state. However, the sleep mode in any power state is considered the lowest state. The Power Manager, with tickless mode, enables the system to enter sleep mode when the scheduler has no tasks to process.
• To know more about the Power states, please visit AN1430: SiWG917 Low-Power Application Note.

2. Components

Power Manager Components facilitate the user to configure RAM retention, peripherals to remain powered on/off, and set wake-up sources prior to the M4 entering sleep mode. The following are the Power Manager components (enabled using the UC in Simplicity Studio):

• Power Manager
• Power Manager Configuration
• Wakeup Source Configuration
• Calendar Wakeup
• GPIO Wakeup
• Deep Sleep Timer
• Wireless Wakeup
• UULP peripheral component for the selected wake-up source
• Low Power

To know more about installing components for Power Manager integration, please visit Power Manager Integration.

2.1 Power Manager Component

Power Manager service is initialized with the installation of this component; the user does not need to initialize the Power Manager service.

The following components are automatically installed when the Power Manager component is installed.

2.1.1 SI91X TICK-LESS MODE Component

The Tickless idle mode feature will suspend the SiWG917 M4 and keep it in sleep when no tasks are scheduled to run.

2.1.2 Power Manager Configuration Component

There are two components pertaining to the Power Manager configuration:

• Power Manager Advance Configuration
• Power Manager Configuration

These components provide control over peripheral enable/disable and RAM retention. Peripheral and RAM retention is configured with the installation of this component; user intervention is not required.

Note: The user can install either 'Power Manager Configuration' or 'Power Manager Advance Configuration' component.

2.1.2.1 Power Manager Configuration

This component is a basic configuration component where the user can select which peripherals need to be powered on/off according to the domain of the peripheral.

Peripheral Configuration

• High Power Peripherals (available in PS4/PS3 power states)
• Low Power Peripherals (available in PS2 power states)
• Ultra Low Power Peripherals (available in all power states)

The peripheral availability in different power states and the list of different groups of peripherals for which power is controlled through software is given in the 'M4 Power States' section of AN1430: SiWG917 Low-Power Application Note.

RAM Configuration

This component also provides configuration for RAM retention. Two options are provided to configure the RAM banks: using size or bank number. The user needs to select any one option.

Note: If both RAM banks using size and bank numbers are enabled, RAM banks using size will be configured by default.

2.1.2.2 Power Manager Advance Configuration

This component is an advanced configuration component where unwanted peripherals and RAM banks are powered off by default, as shown in the following figure. Configurations in this are made to achieve optimum power consumption.

Peripheral Configuration

• High Power Peripherals (available in PS4/PS3 power states)
• Low Power Peripherals (available in PS2 power states)
• Ultra Low Power Peripherals (available in all power states)

Note: SiWG917 M4 current may vary as per the selection of peripherals in addition to the default configuration.

RAM Configuration

The default configuration for RAM retention is already configured to provide the lowest SiWG917 M4 current. However, if required, the user can configure the RAM banks using size or bank number.

Note: SiWG917 M4 current may vary as per the selection of RAM banks in addition to the default configuration.

2.1.3 Wakeup Source Configuration Component

This component provides the initialization and configuration for the UULP (Ultra Ultra Low Power) wake-up sources used in PS4 sleep/PS3 sleep/PS2 sleep.

The UULP wake-up sources that are provided are as follows:

• Calendar or Alarm Wakeup
• GPIO Wakeup
• Deep Sleep Timer Wakeup
• Wireless Wakeup

Note: The user must install the respective UULP peripheral components that are selected as a wake-up source. This will get all the dependencies and files related to the peripheral selected.

2.1.3.1 Calendar or Alarm Wakeup

Calendar wakeup or Alarm wakeup source can be enabled and configured in terms of seconds and milliseconds. By default, the alarm wake-up source is configured with a 5-second alarm trigger. This wakeup source can be enabled using the toggle.

The alarm timer starts running as soon as the wakeup source is initialized prior to M4 sleep and triggers an interrupt upon the timer expiry. The M4 wakes up upon this interrupt.

Note: Millisecond timer is recommended to be used when M4 is in active state. Because the sleep and wake-up transition of M4 takes ~8 ms. The suggested minimum value for this timer is 100 ms.

Alarm time reconfiguration during runtime is not possible with Power Manager. If a user wants to change alarm time at runtime, the user should configure the alarm wake-up source manually with the 'sl_si91x_power_manager_set_wakeup_sources()' API without using UC. In this case, the initialization of the wake-up source should be done by the user in the application.

Note: The alarm timer is periodic as it is configured every time M4 enters sleep inside the 'sl_si91x_power_manager_sleep()'.

2.1.3.2 GPIO Wakeup

There are 4 UULP GPIOs (0 to 3) available, as mentioned in the following figure, which can act as a wake-up source. Enabling the GPIO Wakeup allows the user to select the desired GPIO pin as a wake-up source.

The SiWG917 M4 wakes up based on the input from the configured UULP GPIO. Users can configure the polarity of the GPIO wakeup source.

2.1.3.3 Deep Sleep Timer

Deep Sleep Timer is used as a wakeup source for the SiWG917 M4 in sleep. This timer works only during M4 sleep. The sleep time is configurable in microseconds.

Note: Even if the user configured the timer when M4 is in active state, this timer will start when M4 enters sleep mode. The maximum configurable time is 2^32 microseconds (~71 minutes).

2.1.3.4 Wireless Wakeup

This wake-up source is used when the user wants to wake up M4 when a wireless remote message is received by the NWP (Network Processor). Upon receiving the message, NWP will trigger the M4 to wake up.

2.2 Low Power Peripheral Component

The Low Power Peripheral component is for using the ULP peripheral in the PS2 state. The installation of this component will move the required driver files to RAM. In PS2 state, the flash will be turned off, and M4 can execute from RAM.

Note: Initialization and configuration of the peripheral should be done by the user manually in the application.

For more information, please refer to Power Manager Components Integration.

3. Power Manager APIs

This section describes some of the APIs offered by Power Manager. For more information on APIs and API examples, see the Power Manager APIs documentation.

4. Power Manager with Tickless Idle

Power Manager Tickless Mode is a feature provided by FreeRTOS that allows the SiWG917 to reduce power consumption by entering a low-power mode when there are no tasks to execute.

In traditional RTOS implementations, a periodic timer interrupt, known as a tick, is used to keep track of time and trigger the RTOS scheduler to determine which task should run next. However, in applications where power consumption is critical, the continuous generation of timer interrupts can be inefficient and lead to unnecessary power consumption.

Tickless mode in FreeRTOS addresses this issue by dynamically adjusting the timing of the tick interrupt based on the requirements of the tasks. When there are no tasks ready to execute, the SiWG917 M4 can enter sleep mode, effectively reducing the frequency of timer interrupts and conserving power.

Note: As Tickless Idle mode configures SysRTC as a mechanism to generate the Real-Time Operating System (RTOS) ticks. These ticks are essential for the RTOS to manage timing and scheduling tasks effectively. It is strongly advised against utilizing the SysRTC peripheral for any purpose other than its designated functionality.

4.1 Implementation

A low-power idle hook function that FreeRTOS calls when there are no tasks ready to execute is implemented. This hook function should put the SiWG917 M4 into sleep.

Notes:

1. The application tasks call osDelay, vTaskDelay, osSemaphoreAcquire, or other blocking functions, leading the scheduler to consider them idle. When there are no tasks to be executed, the application will execute the FreeRTOS idle hook.
2. The application checks if the expected idle time is greater than or equal to a predefined threshold (configEXPECTED_IDLE_TIME_BEFORE_SLEEP), which is set to 100 milliseconds. If the condition is met, the application suspends all tasks.
3. The application then calls a function specifically designed to handle the M4 transition to low power mode (portSUPPRESS_TICKS_AND_SLEEP(xExpectedIdleTime)), and IRQs are disabled to ensure that no interrupts occur while the system is preparing to enter low power mode.
4. Then the application checks for the following before letting M4 go to sleep:
   • Check Active Events: It checks if any ongoing tasks or operations require the system to remain active (e.g., data transmission, sensor readings, or critical computation). It also checks if any requirement is added, and the device goes to sleep if there is no power manager requirement added.
   • System Flags: Internal flags or states that indicate whether it is appropriate to sleep or not are likely checked. This includes checking for pending packets from NWP while M4 is going to sleep.
   • Flash operation: Check if there are any flash write operations (like NVM command) in progress. The device goes to sleep if there are no flash operations.
5. If the M4 processor is ready to go to sleep mode, it calls the M4 sleep API (sl_si91x_power_manager_sleep()) to put the M4 processor into sleep mode.
6. The M4 processor wakes up from sleep mode when a predefined wakeup source triggers it. Once it wakes up, the duration for which the system was in sleep mode (known as sleep ticks) is added to the RTOS.
7. IRQs are enabled after the system wakes up from sleep mode, and all tasks that were suspended are resumed. The application continues normal operation.

Note:

• The user must be cautious when using osSemaphoreAcquire and osDelay, as the M4 enters sleep during this configured delay time and will not serve any event interrupts.
• The Power Manager component should install the wireless wake-up and SysRTC component for the sleep timer as a wake-up resource by default. It is highly recommended not to install these components explicitly.

If no tasks are ready to run, the kernel enters tickless idle mode. The system wakes up upon sleep timer expiration or any wake-up source configured. Here's a basic flowchart to illustrate the system's behavior.

Note: Users can take the SL_POWER_MANAGER_TICKLESS_IDLE example application in WiSeConnect release as a reference, which demonstrates the power manager service APIs, state transitions (PS4, PS3, and PS2), and sleep-wake up (PS4, PS3, and PS2 sleep with RAM retention) with tickless idle mode.

4.2 Use Cases

4.2.1 Application with Peripheral only

Tickless idle mode activates sleep functionality automatically when the scheduler goes to idle. Power Manager has APIs that prevent the system from entering sleep mode.

When a requirement is added for a power state, the system is prevented from entering sleep as there is a requirement higher than sleep mode added. Make sure to remove the higher requirement added if the user wants to let the M4 enter sleep mode in tickless idle mode. For instance, during data transmission on a USART, the system can enter sleep mode if there is any delay during transmission. To address this, the Power Manager adds a requirement on PS4 before initiating the transfer and removes the requirement once the transfer is complete, thereby preventing the M4 from entering sleep mode.

Below is the flow for how to handle peripherals across sleep wakeups with tickless idle.

4.2.2 Application with Wireless Functionalities and Peripherals

A sequence flow illustrating a use case for wireless applications that utilize peripherals with tickless idle mode.

1. Power state (PS4) requirement is added to prevent the M4 entering sleep during any delay unintended.
2. The SiWG917 initializes the NWP and M4 peripheral.
3. The NWP is configured as a WLAN station, connects to an Access Point (AP), and establishes a connection to the Cloud.
4. The NWP is set to Connected Power Save mode (Associated Power Save).
5. The peripheral activity is carried out, and data is collected. The peripheral is un-initialized before entering M4 sleep.
6. The power state requirement is removed, allowing the M4 to enter sleep.
7. The M4 is waiting on a semaphore with a defined wait time. The RTC timer, UULP GPIO, and Wireless message are defined as wakeup sources.
8. The M4 enters the last active state (PS4) sleep mode with retention as the scheduler is idle.
9. Upon a GPIO interrupt/ RTC timer expiry/ wireless message/ semaphore wait time expiry, the M4 wakes up.
10. Upon M4 wakeup, add the power state requirement (PS4).
11. For performing the peripheral activity again, re-initialize the peripheral, and execution continues from step 5.

5. Sequence Diagram

On boot-up, the power manager starts with PS3 powersave state (40MHz), and after that, the application adds its required states through API calls.

The sequence diagram for transition from PS3 to PS2 state is as follows.

The Power Manager service is initialized by default using the sl_si91x_power_manager_init() function, which sets the processor to the PS3 state with a clock speed of 40 MHz (Power Save). All possible events are subscribed to using the sl_si91x_power_manager_subscribe_ps_transition_event() function, which includes the callback function address.

To add a requirement for the PS2 state, the sl_si91x_power_manager_add_ps_requirement() function is used. The sli_si91x_power_manager_update_ps_requirement() function then updates the power state requirement, current state, and requirement table, ensuring that the added requirement is a valid transition.

The sl_si91x_get_lowest_ps() function validates all power state requirements and returns the possible state transition based on the state hierarchy. For example, if both PS4 and PS2 state requirements are added, the function will return PS4 as the possible transition since it is considered higher than PS2. The system will not transition to PS2 until the PS4 requirement is removed. However, here, as only the PS2 state requirement is added, the function will return PS2 as the possible transition.

Finally, the sli_si91x_power_manager_change_power_state() function updates the power state from PS3 to PS2, and the ps3_to_ps2_state_change() function executes this transition using internal APIs.

5.1 Power State Transitions

This section provides a simple illustration for power state transition using Power Manager APIs.

• To add a power state requirement: sl_si91x_power_manager_add_ps_requirement(sl_power_state_t state)
• To remove a power state requirement: sl_si91x_power_manager_remove_ps_requirement(sl_power_state_t state);

Note:

• Requirement table stores the requirements for each power state, and based on that, the power manager decides the current state.
• The sl_si91x_power_manager_get_requirement_table() API is used to get the current requirements on all the power states.
• If a task wants to enter a low power mode (such as PS3 or PS2), it first checks if any other task has a higher requirement.
• When multiple tasks request a state transition, the Power Manager maintains the possible state transitions. It is recommended that a task checks the requirement table before switching and performs the state change accordingly.

6. Considerations

This section focuses on considerations when working with Power Manager.

6.1 Add/Remove PS requirement

The current state of the M4 is the most recent active state it transitioned to. For instance, if the PS4 state requirement is added and then removed, followed by the addition and removal of the PS3 state, the current state of the M4 would be PS3.

In a multi-threaded application:

• There may be many requirements added, and Power Manager is maintaining the highest state requested.
• All the requirements of the higher power state must be removed for the M4 to transition to the next lower power state.

If multiple requirements are added, the state will change upon removing all the requirements.

6.2 Remove peripheral requirement

If any peripheral is disabled in the PS4 state (for example, disabling SSI), upon switching to the PS2 state and then back to the PS4 state, all peripherals will be powered on during the state transition. The sl_si91x_power_manager_remove_peripheral_requirement() can be used again to disable the required peripherals.

6.3 Measuring power consumption

To measure the power consumption of only:

• NWP - Configure M4 in PS0 without any RAM retention.
• M4 - Configure NWP in DEEP_SLEEP_WITHOUT_RAM_RETENTION (Deep Sleep without RAM retention when the device is not associated with AP).

7. Appendix

8. Revision History

Revision 1.0

June, 2025

Initial release.