Fixing Zephyr Deep Sleep Backup SRAM Retention on STM32

When designing battery-powered embedded systems, engineers often face the challenge of preserving critical data across deep sleep cycles. While external EEPROM or battery-backed RAM are common solutions, they add cost, board space, and complexity. STM32 microcontrollers offer an integrated alternative: backup SRAM retention. This article explains how to leverage this feature in Zephyr to maintain data integrity during deep sleep, with concrete configuration steps, code examples, and verification techniques.

+------------------+        +------------------+        +------------------+
|   MAIN DOMAIN    |        |  BACKUP DOMAIN   |        |     VBAT        |
|   VDD Powered    |  -->   |  VBAT Powered    |  -->   |  Coin Cell /    |
|  [CPU + SRAM]    | STANDBY| [RTC + BKUP SRAM]| RETAIN |  Supercap      |
|  DATA LOST       |        |  DATA KEPT       |        |  Keeps Alive    |
+------------------+        +------------------+        +------------------+

Problem: Data Loss During Deep Sleep

Many embedded applications require periodic sensor logging, security key storage, or runtime state preservation. When the system enters deep sleep (e.g., STM32 standby mode), the main power domain is cut off, causing standard SRAM to lose its contents. Engineers frequently resort to external EEPROM or supercapacitor-backed RAM to avoid data loss, but these solutions increase hardware costs and design complexity. For cost-sensitive applications, an on-chip solution that requires no external components is preferable.

Root Cause: Power Domain Collapse in Low-Power Modes

STM32 microcontrollers partition power into multiple domains: the main domain (VDD) powers the CPU, peripherals, and standard SRAM; the backup domain (VBAT) powers the RTC, backup registers, and a small SRAM section. During standby or shutdown modes, the main domain is powered down while the backup domain remains active if VBAT is present. However, standard SRAM lies in the main domain and loses power, whereas backup SRAM resides in the backup domain and retains data as long as VBAT is supplied.

Zephyr’s default SRAM allocation uses the main domain, meaning any data stored there vanishes during deep sleep. Without explicit configuration, developers cannot access the backup SRAM region, leading to apparent data loss after wake-up.

Solution: Configuring and Using Backup SRAM in Zephyr

Zephyr provides hardware-specific drivers and device tree bindings for STM32 backup SRAM. The solution involves three steps: enabling the backup SRAM driver, reserving a memory region via device tree, and accessing the data through Zephyr’s sram-backup API.

Step Overview: Three-Step Configuration

Enable driver → reserve region via device tree → access through Zephyr API. Each step builds on the previous, ensuring the backup domain is properly initialized before data access.

Step 1: Enable the Backup SRAM Driver

Activate the STM32 backup SRAM driver in the kernel configuration:

# In your Zephyr project's .config file
CONFIG_SRAM_BACKUP=y

This option enables the driver that manages the backup SRAM region, making it available for allocation and access.

Step 2: Reserve Backup SRAM via Device Tree

Define a reserved memory region for backup SRAM in your board’s device tree source (.dts) or overlay file:

/ {
    sram_backup: sram-backup {
        compatible = "zephyr,sram-backup";
        reg = <0x38800000 0x800>; /* Example: 2KB at 0x38800000 */
        zephyr,memory-region = "SRAM_BACKUP";
    };
};

The reg property specifies the physical address and size of the backup SRAM block. Consult your STM32 reference manual for the exact address (typically in the backup domain, e.g., 0x38800000 for STM32F4 series). The zephyr,memory-region label creates a memory region that Zephyr’s memory manager can allocate from.

Step 3: Access Backup SRAM in Application Code

Use the sram-backup API to read and write data before entering deep sleep:

#include <zephyr/device.h>
#include <zephyr/drivers/sram_backup.h>
#include <string.h>

#define BACKUP_SRAM_NODE DT_LABEL(zephyr_sram_backup)

void backup_critical_data(void)
{
    const struct device *sram_dev = device_get_backup_sram(BACKUP_SRAM_NODE);
    if (!device_is_ready(sram_dev)) {
        return;
    }

    /* Example: Store a 32-bit security token */
    uint32_t token = 0xA5A5A5A5;
    sram_backup_write(sram_dev, 0, &token, sizeof(token));

    /* Example: Store sensor calibration data */
    struct sensor_calibration {
        float offset;
        float gain;
    } cal = { .offset = 1.2f, .gain = 0.98f };
    sram_backup_write(sram_dev, sizeof(token), &cal, sizeof(cal));
}

void restore_critical_data(void)
{
    const struct device *sram_dev = device_get_backup_sram(BACKUP_SRAM_NODE);
    if (!device_is_ready(sram_dev)) {
        return;
    }

    /* Restore security token */
    uint32_t token;
    sram_backup_read(sram_dev, 0, &token, sizeof(token));

    /* Restore calibration data */
    struct sensor_calibration cal;
    sram_backup_read(sram_dev, sizeof(uint32_t), &cal, sizeof(cal));
}

The sram_backup_write() and sram_backup_read() functions handle the low-level access to the backup SRAM region. Data written here persists across deep sleep as long as VBAT is present.

Verification: Ensuring Data Persistence

To verify backup SRAM retention, follow these steps:

1. Write known data: Before entering deep sleep, write a pattern (e.g., 0x5A5A5A5A) to a known offset in backup SRAM.
2. Enter deep sleep: Use Zephyr’s power management API to put the system into standby mode.
3. Wake and read: After wake-up (triggered by RTC alarm or external interrupt), read back the same offset.
4. Compare: If the data matches the written pattern, backup SRAM retention is working correctly.

Example Verification Code

#define TEST_OFFSET 0
#define TEST_PATTERN 0x5A5A5A5A

bool verify_backup_sram(void)
{
    const struct device *sram_dev = device_get_backup_sram(BACKUP_SRAM_NODE);
    if (!device_is_ready(sram_dev)) {
        return false;
    }

    /* Write test pattern */
    uint32_t pattern = TEST_PATTERN;
    sram_backup_write(sram_dev, TEST_OFFSET, &pattern, sizeof(pattern));

    /* Enter standby mode (requires PM configuration) */
    pm_state_force(0, &(struct pm_state_info){ .state = PM_STATE_STANDBY, .substate_id = 0 });

    /* After wake-up */
    uint32_t readback;
    sram_backup_read(sram_dev, TEST_OFFSET, &readback, sizeof(readback));

    return (readback == TEST_PATTERN);
}

Note: The pm_state_force() function is a simplified example. Actual standby entry requires configuring Zephyr’s power management subsystem, including setting up wake-up sources (e.g., RTC alarm) and ensuring VBAT is connected.

Trade-offs and Considerations

While backup SRAM retention eliminates the need for external memory, it comes with limitations:

• Size constraints: Backup SRAM is typically small (4KB to 32KB depending on the STM32 series), limiting the amount of data that can be retained.
• VBAT dependency: The backup domain requires a valid VBAT connection (usually a coin cell or capacitor) to retain data during main power loss.
• Wake-up latency: Exiting standby mode may take longer than sleep or stop modes due to power domain stabilization.
• Initialization overhead: The backup SRAM driver must be initialized before use, adding a small boot-time penalty.

For applications requiring more than a few kilobytes of retained data, consider combining backup SRAM for critical tokens/settings with external EEPROM for larger logs.

Summary

Backup SRAM retention in STM32 microcontrollers provides an elegant, cost-effective solution for preserving critical data across deep sleep cycles in Zephyr applications. By enabling the dedicated driver, reserving a memory region via device tree, and using the sram-backup API, engineers can retain security keys, calibration data, and runtime state without external components. Proper verification ensures data persistence, and understanding the trade-offs helps designers balance size, power, and complexity. For battery-powered embedded systems where every microamp and millimeter counts, backup SRAM retention is a valuable tool in the low-power design arsenal.

Related Reading

• Zephyr Power Management Deep Dive
• Debugging Zephyr Kernel Panic on STM32
• Memory Alignment and Padding in Embedded C
• Watchdog Timer Design for Reliable Embedded Systems

References

1. STMicroelectronics. “STM32F4 Series Reference Manual.” RM0090, 2022. https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
2. Zephyr Project. “Power Management.” https://docs.zephyrproject.org/latest/services/power_management.html.
3. Zephyr Project. “SRAM Backup Driver.” https://docs.zephyrproject.org/latest/doxygen/html/group__retained__mem__interface__backend.html.
4. ARM. “ARMv7-M Architecture Reference Manual.” https://support.arm.com/documentation/ddi0403/latest.
5. Texas Instruments. “Low-Power Design Techniques.” Application Report SLUA355, 2010.
6. NXP Semiconductors. “Backup Power Domain in LPC55xx.” User Manual UM10914, 2020.