Skip to content

espressif: preserve alarm.sleep_memory across software resets#10899

Draft
lzrd wants to merge 1 commit intoadafruit:10.1.xfrom
lzrd:preserve-sleep_memory
Draft

espressif: preserve alarm.sleep_memory across software resets#10899
lzrd wants to merge 1 commit intoadafruit:10.1.xfrom
lzrd:preserve-sleep_memory

Conversation

@lzrd
Copy link

@lzrd lzrd commented Mar 25, 2026

Change the "sleep memory" linker attribute from RTC_DATA_ATTR to RTC_NOINIT_ATTR.

Also, the ESP-IDF bootloader will no longer zero-initialize sleep memory on software reset (microcontroller.reset()), watchdog, or panic resets.

Added explicit clearing in alarm_sleep_memory_reset() for reset types where RTC SRAM contents are not known to be intact.

Sleep memory now persists across microcontroller.reset(), watchdog, and panic resets. This is now the same as existing deep-sleep behavior and aligns with what the hardware supports.

Programs that only relied on the existing sleep behavior should be fine.

Anyone using the new behavior should validate sleep_memory contents with a magic value and integrity check (e.g. CRC32) before trusting them. Sleep memory may contain stale data from a previous version of code.py after an autoreload or other non-zeroing software reset not planned by the programmer.

Behavior Pre- vs. Post- change:

Reset type Before After
microcontroller.reset() Zeroed Preserved
Watchdog / panic Zeroed Preserved
Deep sleep wake Preserved Preserved
supervisor.reload() Preserved Preserved
Power cycle / reset button Zeroed Zeroed
Brown-out Zeroed Zeroed

Testing

Tested on ESP32-S2 (Adafruit MagTag, 2025 version).
Manual test added at tests/circuitpython-manual/alarm/sleep_memory_persist.py

The test writes a CRC32-protected marker and the state of the tests to alarm.sleep_memory, then verifies that the data survives microcontroller.reset() and supervisor.reload().

Before patch: reset: FAIL
After patch: reset: PASS, reload: PASS

Fixes #10896

Change the "sleep memory" linker attribute from RTC_DATA_ATTR to
RTC_NOINIT_ATTR.

The ESP-IDF bootloader will no longer zero-initialize sleep memory on
software reset (microcontroller.reset()), watchdog, or panic resets.

Added explicit clearing in alarm_sleep_memory_reset() for reset types
where RTC SRAM contents are not known to be intact.

Sleep memory now persists across microcontroller.reset(), watchdog, and
panic resets. This matches the existing deep-sleep behavior and aligns
with what the hardware already supports.

Programs that only relied on the existing sleep behavior should be fine.

Anyone using the new behavior should validate sleep_memory contents
with a magic value and integrity check (e.g. CRC32) before trusting
them. Sleep memory may contain stale data from a previous version of
code.py after an autoreload or other non-zeroing software reset not
planned by the programmer.

Fixes adafruit#10896
@lzrd
Copy link
Author

lzrd commented Mar 25, 2026

I first made this change against main then rebased to 10.1.x.
I may need to go through the full build and test cycle again with a clean build to make sure that there aren't extraneous changes (e.g. '*.pot' files).

@lzrd lzrd marked this pull request as draft March 25, 2026 21:24
@dhalbert
Copy link
Collaborator

dhalbert commented Mar 26, 2026

Thanks for the PR.

The PR commit was based on main, so it will have mains circuitpython.pot. You could try rebasing your PR branch onto 10.1.x, but I'm not sure if that would work out. Another thing to do is to create a new local branch off of 10.1.x and then git cherry-pick 2e0250f into it. Resubmit as a new PR and close this one.

The docs build failed due to a temporary failure. I re-ran it to confirm that was temporary.

@dhalbert
Copy link
Collaborator

After thinking about this some more, I would rather have this as a PR against main instead of 10.1.x, so that it will appear in 10.2.0. It is a behavior change that is not necessarily a bugfix, and might break some existing code. I looked at the Learn Guide code and I don't any effects on those uses of sleep_memory, but there might be user code.

@lzrd
Copy link
Author

lzrd commented Mar 26, 2026

I'll go through another build/test cycle to make sure that everything is ok.

@lzrd lzrd marked this pull request as ready for review March 26, 2026 22:21
@lzrd lzrd marked this pull request as draft March 26, 2026 22:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants