Power Manager Appendix#

Glossary#

• Energy Mode (EM): Hardware power state (EM0=active, EM1=sleep, EM2=deep sleep, EM3=stop, EM4=shutoff)

• EM1P: Subset of EM1 enabling radio operation while the core and high-speed peripherals are powered down. Entered when radio is active and EM2 is requested. Core sleeps, but HFXO and radio (RX only) remain active.

• Requirement: Software constraint preventing sleep deeper than specified energy mode

• Schedule Wake-up: Planned wake-up event with timing optimization

• Pin Retention: Feature maintaining GPIO pin states through EM4 reset

• HFXO: High Frequency Crystal Oscillator (external high-precision clock source)

• LFRCO: Low Frequency RC Oscillator

• Universal Configurator (UC): GUI-based configuration tool

• API: Application Programming Interface

Related Documentation#

• Power Manager API Reference - Complete API documentation with function signatures, parameters, and return values

• Clock Manager Documentation - Essential companion for oscillator configuration

• Sleep Timer Documentation - Critical for low-power timer management and schedule wake-up optimization

• HFXO Manager Documentation - Series 2 specific crystal oscillator management

• Simplicity Studio 5 User Guide - Complete IDE documentation

• Energy Profiler User Guide - Advanced power consumption analysis tool

Extended Examples#

Using Event Notifications#

#include "sl_power_manager.h"

static sl_power_manager_em_transition_event_handle_t power_event_handle;

void my_power_transition_callback(sl_power_manager_em_t from, sl_power_manager_em_t to) {
  if (from < to && to >= SL_POWER_MANAGER_EM2) {
    save_application_context();
  } else if (from > to && from >= SL_POWER_MANAGER_EM2) {
    restore_application_context();
  }
}

void app_init(void) {
  sl_power_manager_em_transition_event_info_t event_info = {
    .event_mask = (SL_POWER_MANAGER_EVENT_TRANSITION_ENTERING_EM2 | SL_POWER_MANAGER_EVENT_TRANSITION_LEAVING_EM2),
    .on_event = my_power_transition_callback
  };
  // When entering or exiting EM2, call the callback to manage the application context
  sl_power_manager_subscribe_em_transition_event(&power_event_handle, &event_info);
}

Schedule Wake-up Tuning#

#include "sl_power_manager.h"

// Battery-optimized configuration
void configure_for_battery_life(void)
{
  // Allow later early wake-up for power savings (risk: potential to be late for scheduled events)
  sl_power_manager_schedule_wakeup_set_restore_overhead_tick(-5);
  
  // Prevent frequent short deep sleep cycles
  sl_power_manager_schedule_wakeup_set_minimum_offtime_tick(30);
}

Execution Modes (Series 3 Only)#

#include "sl_power_manager.h"

// Optimize for Series 3 execution modes
void configure_series3_power_optimization(void)
{
  // Add performance requirement when high processing needed
  sl_power_manager_add_performance_mode_requirement();
  
  // Do some intensive processing...

  // Remove when returning to standard execution
  sl_power_manager_remove_performance_mode_requirement();
  
  // Series 3 automatically manages SYSCLK switching (SOCPLL ↔ HFXO)
  // Power Manager coordinates with 36μs SOCPLL lock time
}

FAQ#

Q: When should I add a requirement on an energy mode?

A: Add EM1 requirements when your module needs immediate responsiveness or high-frequency clocks (UART high baud rates, precise timing, interrupt latency <1μs). Adding requirements for other energy modes does nothing and serves no purpose:

• EM0 requirements: Meaningless since EM0 is the active state, not a sleep mode

• EM2 requirements: The hardware automatically manages EM2/EM3 subdomains based on peripheral usage

• EM3 requirements: The Power Manager cannot decide to enter EM4 without an explicit call to sl_power_manager_enter_em4(), so EM3 requirements are unnecessary

• EM4 requirements: Meaningless since EM4 is the lowest energy mode

Q: How does pin retention work in EM4?

A: Configure SL_POWER_MANAGER_INIT_EMU_EM4_PIN_RETENTION_MODE, set pin states before EM4 entry, and call sl_power_manager_em4_unlatch_pin_retention() after reset to release pins back to peripheral control.

Q: What happens if I remove a requirement I never added?

A: This creates undefined behavior. Always track requirement state in your module and only remove requirements you have added.

Q: Why is my system consuming more power than expected?

A: Common causes include: persistent EM1 requirements preventing deep sleep, UART/SPI drivers blocking sleep, GPIO leakage current, unused peripheral clocks enabled, or voltage scaling disabled. Use sl_power_manager_debug_print_em_requirements() to identify active requirements.

Q: What's the difference between EM2 and EM3?

A: Starting with Series 2 devices, EM2 and EM3 have been merged. The EMU hardware automatically powers down as many subdomains as possible. To reach EM3 power levels, peripherals must be disabled.

Q: When should I use EM4 vs EM2/EM3?

A: Use EM4 for ultra-low power when you can tolerate system reset on wake-up and have long sleep periods. Use EM2/EM3 for applications needing faster wake-up and preserved RAM state.

Q: How does Power Manager work with RTOS?

A: With FreeRTOS or Micrium OS, Power Manager automatically handles sleep in the OS idle task. Do not call sl_power_manager_sleep() manually. The system enters the lowest allowable energy mode when all tasks are blocked.

Q: How do I preserve data across EM4 resets?

A: Use Backup RAM (BURAM) registers to store critical data. BURAM survives EM4 resets while regular RAM is lost. Copy data to/from BURAM->RET[] before EM4 entry and after wake-up.