Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SleepMemory for RP2040 #5081

Closed
hierophect opened this issue Jul 30, 2021 · 0 comments · Fixed by #8015
Closed

Add SleepMemory for RP2040 #5081

hierophect opened this issue Jul 30, 2021 · 0 comments · Fixed by #8015
Milestone

Comments

@hierophect
Copy link
Collaborator

Adding RP2040 sleep memory is actually kind of tricky because of the way we handle the general RAM during deep sleep. Unlike every other port, the RP2040 is actually incapable of fully shutting down the RAM during deep sleep - even the lowest power settings still retains all data. In an effort to be as close as possible to the other ports, which typically lose all memory when deep sleeping, the RP2040 port currently implements a watchdog reset after deep sleeping, resetting all RAM except for a specific collection of watchdog registers which store the alarm information.

Because there's no specific region of memory like STM's BKUPSRAM or the ESP32S2 low power banks that bypasses our deep sleep (because the RP2040 expects that all memory should be available across deep sleep), implementing SleepMemory will require removing the watchdog reset and treating true deep sleep more like a "fake" deep sleep. This will require API changes like removing the NORETURN label on common_hal_alarm_enter_deep_sleep, and probably has a bunch of little gotchas that will need to be accounted for. However, once those are finalized, SleepMemory can be implemented simply as a static array in regular memory.

This feature is required for #5080.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants