ESP32 Forum

Hi everyone,

I’m new to ESP and currently working with the ESP32-P4 on a custom board. I want to use the RTC with a backup battery so that it keeps running when the main power is removed.

I have connected VBAT to a CR1220 backup battery, following the ESP32-P4 datasheet.

I have a few questions:
1.How can I enable and use the RTC with battery backup on the ESP32-P4?
2.Which configurations need to be changed in menuconfig to support this?
3.Are there example codes available for reading/writing the RTC time and verifying that it retains the correct time after a power loss?
4.Do I need to configure any special registers or settings for RTC backup mode?

Any guidance, example code, or reference documentation would be very helpful.

Thank you!

You’ve correctly wired the VBAT pin to your CR1220 battery—but to make it active, you need to configure ESP-IDF to support VBAT.

Thank you,ahsrabrifat.
I am not familiar with the configuration. Could you please share any documentation on that? I am using ESP-IDF v5.5.

I hope the following links will help you.
https://docs.espressif.com/projects/esp ... _vbat.html
https://docs.espressif.com/projects/esp ... _time.html
https://docs.espressif.com/projects/esp ... rence.html

Hi,
@Sudheesh Did you make it work?
First link "ESP32-P4 Battery Backup Solution" is for "ESP-IoT-Solution" and not for "ESP-Idf" ... If I look into file which I need modify there is no "pmu_sleep_start" function...
Any solution for ESP-IDF? I need to keep RTC if power is loss... NTP is not option because there is no internet or loacal connection(No LAN or WiFi)...

@Sudheesh and @_Dejan_

Has anyone had luck with this? Using VSCode extension I can find VBAT settings that seem relevant. I am specifically trying to keep the RTC through power loss. Following the above links gave me a variety of results. I was able to get RTC to persist through power loss, but booting became very inconsistent. It would be nice if Espressif could provide an example or improved documentation.

You have to go into menuconfig to enable VBAT.

Could NOT get this to work. Ultimately, I had to add a DS3231 to the I2C bus. I'm currently progging a Waveshare ESP32-P4 dev board (with a 7" screen). We tried the following things to try and get them to work:

ESP32-P4 RTC Time Persistence Across Power Cycles — Approaches Tried

Hardware

• Board: Waveshare ESP32-P4-WIFI6-Touch-LCD-7B
• SoC: ESP32-P4 rev 1.3
• ESP-IDF: v5.4
• VBAT: CR1220 coin cell, measured 3.27V, seated in onboard battery holder
• VBAT circuit: CR1220 connected to ESP_VBAT pin via onboard holder (confirmed in schematic — VBAT feeds the LP domain power input)
• Peripherals using SDIO: SD card on SDMMC Slot 0 (4-bit, 40MHz), WiFi via ESP32-C6 coprocessor on SDIO Slot 1 (esp_hosted, 4-bit, 40MHz)

Problem Statement
returns epoch 0 (1970-01-01) on every boot — including soft reboots from serial DTR/RTS reset — even though the ESP32-P4 datasheet (Section 4.1.4.10) documents a 48-bit RTC Timer that provides "uninterrupted operation during any reset or sleep mode, except for power-on reset of LP system."

The goal was to maintain wall-clock time across power outages using the CR1220 battery, without relying on NTP or deep sleep.

Relevant sdkconfig
How ESP-IDF System Time Works (background)
computes:

• Code: Select all

  boot_time

  is stored in LP_STORE2/3 registers (

  Code: Select all

  LP_SYSTEM_REG_LP_STORE2_REG

  /

  Code: Select all

  LP_SYSTEM_REG_LP_STORE3_REG

  ) via

  Code: Select all

  esp_time_impl_set_boot_time()

  in

  Code: Select all

  components/newlib/port/esp_time_impl.c

• Code: Select all

  time_since_boot

  uses

  Code: Select all

  s_microseconds_offset + esp_system_get_time()

  where

  Code: Select all

  s_microseconds_offset

  bridges the ESP timer to the RTC counter

• Code: Select all

  settimeofday()

  writes:

  Code: Select all

  boot_time = now - time_since_boot

  into LP_STORE2/3
• The 48-bit RTC counter (

  Code: Select all

  esp_rtc_get_time_us()

  ) provides the monotonic reference

If LP_STORE2/3 and the RTC counter both survive a reset, time should persist.

[hr]

Approach 1: Baseline — System Calls Only (the P4 "onboard RTC" shim)

Implementation: Replaced the external DS3231 I2C driver with a shim that wraps /, treating the ESP32-P4's internal RTC as the time source.

Result: always returns epoch ~3 seconds (just boot time) after any reset. Diagnostic logging confirmed: Even a serial DTR/RTS reset (not actual power loss) reports and shows the RTC counter at ~3.3 seconds (just the time since boot started). The LP_STORE2/3 registers are zeroed.

Root cause: Every reset — including serial-triggered resets — appears as to the ROM, which zeros LP_STORE registers and resets the 48-bit RTC counter. The VBAT switching that would keep the LP domain alive during main power loss is not enabled by default.

[hr]

Approach 2: NVS Bootstrap

Implementation: On every boot, before the RTC driver reads , check if NVS contains (minutes since epoch, saved on every NTP sync). If shows year < 2025, call with the NVS timestamp to prime the clock.

Also saved (raw value at last NTP sync) to NVS, so that if the RTC counter survived a power cycle, we could compute: for second-accurate recovery.

Result: Clock was primed to approximately correct time (minute resolution from NVS). Components started immediately without the 27-second NTP wait. However, the RTC counter delta was always zero because the counter resets on every boot — so the "second-accurate VBAT refinement" path never activated. The time was stale by the duration of the power outage.

[hr]

Approach 3: PMU VBAT Auto-Switch via Direct Register Write

Implementation: Based on Espressif's ESP32-P4 VBAT documentation, set the PMU to auto-switch the LP domain to VBAT when main power drops:
Result — Partial success then crash:

The VBAT switching did work for time persistence. After power cycling (unplug, wait, replug), the boot log showed: This was the correct time, proving LP_STORE2/3 and the RTC counter survived the power cycle via VBAT.

However, both SDIO peripherals crashed on the VBAT-wake boot:

• SD card (SDMMC Slot 0):

  Code: Select all

  sdmmc_init_sd_ssr: sdmmc_send_cmd returned 0x107

  →

  Code: Select all

  ESP_ERR_TIMEOUT

• WiFi SDIO (Slot 1, esp_hosted):

  Code: Select all

  assert failed: xQueueSemaphoreTake queue.c:1709 (( pxQueue ))

Root cause: When VBAT keeps the LP domain powered, the reset reason is no longer . In lines 375-399, LP peripheral cleanup — including SDIO PLL clock gate clearing — only runs on :
When VBAT keeps the LP domain alive, stale SDIO PLL clock states, LP UART clocks, and LP pad configurations survive into the next boot, causing the SDIO host controller to initialize against corrupted state.

Additional finding: (bits [1:0] of ) is a read-only status register reflecting the current power mode. It only updates during actual PMU state transitions (sleep entry/exit), not from runtime register writes. The poll loop always timed out with "VBAT auto-switch failed to activate" even though the configuration register was written correctly — the mode only takes effect on the next power transition.

[hr]

Approach 4: LP Peripheral Force-Reset + SDIO Clock Cleanup + VBAT Enable

Implementation: Before enabling VBAT, force-reset LP peripherals and replay the cleanup:
Result — Worse crash:

The force-reset was too destructive. It wiped LP_STORE registers (including = XTAL frequency calibration) and corrupted LP ROM execution state:
After the first boot completed, subsequent boots crashed immediately in LP ROM code: Root cause: The power domain encompasses more than just SDIO-related state. The force-reset pulse zeroed critical LP system registers (XTAL calibration in LP_STORE4, RTC slow clock calibration in LP_STORE1, boot_time in LP_STORE2/3) and corrupted LP ROM state, making the LP core execute garbage instructions on subsequent boots.

[hr]

Approach 5: RTC_NOINIT_ATTR (investigated, not attempted)

Finding: We investigated using to store a struct in LP RAM that survives resets. However:

• Code: Select all

  RTC_NOINIT_ATTR

  persistence tests are explicitly disabled for ESP32-P4 in ESP-IDF 5.4 due to issue IDF-9564:

  Code: Select all

  // components/esp_system/test_apps/.../test_reset_reason.c:27-29
  #if (CONFIG_SOC_RTC_FAST_MEM_SUPPORTED || CONFIG_SOC_RTC_SLOW_MEM_SUPPORTED) && !CONFIG_IDF_TARGET_ESP32P4
  #define CHECK_RTC_MEM 1
  #endif
  

• The LP RAM linker section exists (

  Code: Select all

  lp_ram_seg

  at

  Code: Select all

  0x50108000

  , 8KB) and the macro is defined (not empty), but behavior is unvalidated on P4.
• Even if it worked, without the RTC counter surviving, we'd only have the epoch snapshot, not elapsed time.

[hr]

Summary of Findings
[hr]

Questions for Espressif

1. Is there a supported way to enable VBAT power switching for the LP domain without going through the deep sleep infrastructure? Our device runs in full-power mode and experiences unexpected power loss. We need the PMU to be pre-configured so that when VDDA drops, it automatically switches to VBAT — without having called first.

2. Can the SDIO PLL clock cleanup in be extended to also run on VBAT wake resets? The current code only clears stale LP clocks on . When VBAT keeps the LP domain alive, the reset reason changes and these cleanup steps are skipped, leaving SDIO in a broken state.

3. Is there a way to selectively reset LP peripherals (SDIO clocks, GPIO pads) without resetting the LP_STORE registers and RTC counter? is too broad — it wipes everything including XTAL calibration and boot_time.

4. What is the status of IDF-9564 ( disabled on ESP32-P4)? If LP RAM persistence across resets were reliable, it could provide an alternative path for time persistence without VBAT.

5. The component referenced in the ESP-IoT-Solution VBAT documentation — is there a timeline for it being integrated into ESP-IDF as a standard component? A proper API for VBAT management that handles the LP domain cleanup on wake would solve this cleanly.

[hr]

Resolution

We ultimately attached an external DS3231 I2C RTC module (SDA=GPIO7, SCL=GPIO8) with its own battery backup. This provides sub-second time accuracy across power cycles without any dependency on the ESP32-P4's LP domain persistence.