Power Manager Architecture#

Energy Modes Overview#

The Power Manager manages system energy modes based on requirements from software modules. The following energy modes are available:


Energy Mode	Description
EM0	System is fully operational. All peripherals are available. The CPU is executing code.
EM1	The CPU is in sleep mode and is not executing any code.
EM2/EM3 (1)	High frequency clock sources are shut down. Peripherals that require a high frequency clock are unavailable or have limited functionalities.
EM4 (2)	Ultra-low power shut-off mode. System resets on wake-up. Power Manager will not automatically enter EM4. You must explicitly call `sl_power_manager_enter_em4()`.

Notes:
EM2 and EM3 energy modes have been merged from a software perspective starting with Series 2 devices. When entering deep sleep, the EMU hardware evaluates which modules in PD0 are active and powers down as many subdomains as possible. To reach EM3 power levels, peripherals must be disabled or run on ULFRCO.
EM4 is managed separately from other energy modes by using the dedicated sl_power_manager_enter_em4() API, because it requires different decision-making logic and causes a system reset when the device wakes up.

Power Manager Features#

The Power Manager implements a requirements-based architecture that automatically optimizes power while abstracting hardware complexity. Think of it as an intelligent power broker managing competing demands from software modules.

Features Overview#


Feature	Purpose
Requirements Management	Tracks module energy mode needs
Energy Mode Selection	Chooses optimal sleep depth
Event Notifications	Broadcasts power transitions
Wake-up Management	Optimizes clock restoration
EM4 Control	Ultra-low power management
Optimization Options	Advanced power adjustments
Execution Modes (Series 3)	Performance scaling

Requirements Management#

The requirements management system uses reference counting to coordinate power needs across multiple modules:

Reference Counting: Multiple modules can add/remove the same requirement safely
Thread Safety: Atomic operations safe in ISR context
Debug Tracking: Use sl_power_manager_debug_print_em_requirements() to retrieve the EM requirements at a given time for debugging or optimization purposes

Energy Mode Selection#

The selection always respects the most demanding requirement to prevent system failures.


Input	Output
No Requirements	EM2/EM3 Deep Sleep
EM1 Requirements	EM1 Light Sleep

SIXG301 Case

Since the SIXG301 doesn’t support EM2 or EM3, the Power Manager provides two variants of EM1, each with a different power optimization strategy:


EM1 Type	Power Optimization
EM1 with EM1 Requirements	Standard EM1 Light Sleep
EM1 without Requirements	HCLK divider maximized + Optional SYSCLK→HFXO switch

Event Notifications#

Provides callbacks for power transitions. Here are some use cases:

Before Transition: Save context, prepare hardware for sleep
After Transition: Restore context, reinitialize peripherals

Important Considerations:

Callback Performance: Keep callbacks brief to minimize impact on power transition timing
Error Handling: Callbacks cannot prevent power transitions. Handle errors gracefully
Thread Safety: Callbacks execute in power manager context. Use appropriate synchronization when needed
EM Requirements: Cannot add/remove EM requirements within transition callbacks because this would cause undefined behavior

Wake-up Management#

The wake-up management system provides timing optimization that minimizes power consumption while guaranteeing real-time responsiveness:

Synchronous Events (Sleep Timer): Automatic advance restore with precise timing guarantee. Clocks are ready when needed
Asynchronous Events (Interrupts): Fast response with optional restore via EM1 requirements. Note that adding EM1 requirements from ISR during EM2 sleep will block until system restore is finished

EM4 Control#

Specialized ultra-low power with reset-based operation:


Aspect	Behavior
Entry	Manual only via `sl_power_manager_enter_em4()`
Wake-up	Full device reset with state restoration required
Data Persistence	BURAM registers only - RAM not retained
Pin States	Configurable retention with unlatch after wake-up

Optimization Options#

Power optimization features for fine-tuning system behavior:

Voltage Scaling: Supply optimization to balance performance versus power
Schedule Wake-up Tuning: Advanced timing parameters for clock restoration optimization

Schedule Wake-up Tuning Parameters:


Parameter	Function	Impact
Restore Overhead	Early wake-up margin for clock restoration	Positive = safer (wake earlier), Negative = more aggressive (wake later, risk missing deadlines)
Minimum Off-Time	Deep sleep duration threshold to prevent short cycles	Higher = prevents frequent deep sleep entry/exit overhead

Advanced Feature Warning: These parameters directly affect real-time behavior and power efficiency. Incorrect values can cause missed deadlines or increased power consumption. Use Energy Profiler and oscilloscope measurements when tuning these parameters.

Execution Modes (Series 3)#

Dynamic clock frequency management for Series 3 devices:


Mode	Clock Source	When to Use	Power Impact
Performance	SOCPLL	Heavy computation	Higher consumption, max speed
Standard	HFRCODPLL	Normal operation	Balanced power/performance

Backward Compatibility: APIs do nothing on Series 2 devices. The same code works across device families.

Dependencies#

The Power Manager integrates with multiple platform components and hardware interfaces:

Hardware Dependencies#


Component	Function	Integration Details
Energy Management Unit (EMU)	Energy mode control	Direct hardware interface for voltage scaling and EM4 pin retention
High-Frequency Crystal Oscillator (HFXO)	Clock management	Managed automatically based on energy mode requirements for power optimization
RTC Peripheral	Sleep timing	Provides timing services for sleep timer functionality and scheduled wake-up operations
Low-Frequency Oscillators	Sleep timing	Used as a clock source for RTC for sleep timer functionality and deep sleep timing
GPIO Hardware	Pin state control	EM4 pin retention and unlatch capabilities for maintaining system state during deep sleep

Software Dependencies#


Component	Dependency Level	Purpose
Clock Manager	Required	HFXO management, timing calculations, and clock source information
Sleep Timer	Required	Schedule wake-up optimization and timing calculations for power-optimized wake-up sequences
Device Abstraction	Required	Device-specific headers and CMSIS for hardware register access and device feature detection
SL System/Main	Recommended	System initialization and main loop for proper component lifecycle
RTOS	Optional	FreeRTOS integration when present for automatic idle task sleep management

Development Tool Dependencies#

Simplicity Studio: IDE integration with component configuration and debugging support
Energy Profiler: Real-time power measurement integration for power consumption analysis
Universal Configurator: Configuration interface for power management settings and optimization parameters

Operating Mode Architecture#

Operating System Comparison#


Aspect	RTOS Operation (Micrium OS/FreeRTOS)	Bare-Metal Operation
Sleep Management	Automatic - enters lowest possible energy mode when OS enters idle task	Manual - application must call `sl_power_manager_sleep()` when idling (included in main template by default)
Coordination	Respects RTOS scheduler state for safe sleep entry	Uses sleep decision callbacks for application control
Requirements	Tasks can add/remove requirements as needed	Application manages requirements directly
Wake-up Handling	System resumes when tasks are resumed, posted, or delays expire	Application controls sleep/wake decisions through callbacks

Bare-Metal Sleep Decision Callbacks#

When operating without an OS, the application has two entry points for sleep decision-making. These callbacks provide fine-grained control over when the system can enter sleep modes.


Callback Function	When Called	Return Value
`app_is_ok_to_sleep()`	Once at the beginning of `sl_power_manager_sleep()`	`true` = allow sleep, `false` = stay awake
`app_sleep_on_isr_exit()`	After every interrupt during sleep	`SL_POWER_MANAGER_IGNORE` = let Power Manager decide `SL_POWER_MANAGER_SLEEP` = force return to sleep `SL_POWER_MANAGER_WAKEUP` = force wake up