Persistent pstate improvements #3192

2026-09-11T11:05:19-05:00

will-v-pi commented

2026-09-11 11:05:19 -05:00

(Migrated from github.com)

This now determines the persistent pstate at link time and uses that in low_power_persistent_pstate_get, rather than calculating it at runtime (it cannot be done at compile time, because it depends on the size and location of the persistent data section).

I've kept the option for runtime calculation by setting PICO_LOW_POWER_PERSISTENT_PSTATE_STATIC=0 (e.g. custom linker scripts that don't provide the new __persistent_data_pstate__), with the logic copied from the linker script to avoid differing logic in the two places. Also added tests to make sure they give the same value.

Add pstate_bitset_to/from_uint32 for use with scratch registers and with __persistent_data_pstate__, rather than powman_power_state directly

Also add pstate_resume_func_common for common pstate_resume_func stuff in tests, rather than duplicating it everywhere

This now determines the persistent pstate at link time and uses that in `low_power_persistent_pstate_get`, rather than calculating it at runtime (it cannot be done at compile time, because it depends on the size and location of the persistent data section). I've kept the option for runtime calculation by setting `PICO_LOW_POWER_PERSISTENT_PSTATE_STATIC=0` (e.g. custom linker scripts that don't provide the new `__persistent_data_pstate__`), with the logic copied from the linker script to avoid differing logic in the two places. Also added tests to make sure they give the same value. Add `pstate_bitset_to/from_uint32` for use with scratch registers and with `__persistent_data_pstate__`, rather than `powman_power_state` directly Also add `pstate_resume_func_common` for common `pstate_resume_func` stuff in tests, rather than duplicating it everywhere

kilograham (Migrated from github.com) reviewed

2026-09-11 11:05:19 -05:00

peterharperuk commented

2026-09-11 11:17:05 -05:00

(Migrated from github.com)

Sorry, dumb questions... what's the advantage of doing this at link time rather than runtime? Is PICO_LOW_POWER_PERSISTENT_PSTATE_STATIC a good name. I guess PICO_LOW_POWER_PERSISTENT_PSTATE_RUN_TIME=1 would be more obvious to me (to get back the old behaviour?)

will-v-pi commented

2026-09-11 12:16:43 -05:00

(Migrated from github.com)

Sorry, dumb questions... what's the advantage of doing this at link time rather than runtime? Is PICO_LOW_POWER_PERSISTENT_PSTATE_STATIC a good name. I guess PICO_LOW_POWER_PERSISTENT_PSTATE_RUN_TIME=1 would be more obvious to me (to get back the old behaviour?)

It saves about 100 bytes of code, and about half that in CPU cycles

Yeah, the variable name probably needs improvement - PICO_LOW_POWER_PERSISTENT_PSTATE_RUN_TIME is probably better

> Sorry, dumb questions... what's the advantage of doing this at link time rather than runtime? Is PICO_LOW_POWER_PERSISTENT_PSTATE_STATIC a good name. I guess PICO_LOW_POWER_PERSISTENT_PSTATE_RUN_TIME=1 would be more obvious to me (to get back the old behaviour?) It saves about 100 bytes of code, and about half that in CPU cycles Yeah, the variable name probably needs improvement - `PICO_LOW_POWER_PERSISTENT_PSTATE_RUN_TIME` is probably better

peterharperuk (Migrated from github.com) reviewed

2026-09-14 04:13:14 -05:00

src/rp2350/pico_platform/script_include/section_platform_end.incl

					
				@ -5,0 +28,4 @@

				    ASSERT(__persistent_data_end__ - __persistent_data_start__ <= SRAM_STRIPED_END - SRAM_BASE, "Persistent data is too large")

				    /* Assert end is in striped sram */

				    ASSERT(__persistent_data_end__ <= SRAM_STRIPED_END, "Persistent data ends outside striped sram")

Is <= right?

peterharperuk (Migrated from github.com) reviewed

2026-09-14 04:31:30 -05:00

src/rp2_common/pico_low_power/low_power.c

					
				@ -704,0 +702,4 @@

				    /* start in sram0, so OR that in */

				    __persistent_data_pstate__ |= ((uint32_t)__persistent_data_start__ >= SRAM_BASE && (uint32_t)__persistent_data_start__ < SRAM4_BASE) ? POWMAN_POWER_DOMAIN_SRAM_BANK0_BITS : 0;

ditto

will-v-pi (Migrated from github.com) reviewed

2026-09-16 03:55:41 -05:00

src/rp2350/pico_platform/script_include/section_platform_end.incl

					
				@ -5,0 +28,4 @@

				    ASSERT(__persistent_data_end__ - __persistent_data_start__ <= SRAM_STRIPED_END - SRAM_BASE, "Persistent data is too large")

				    /* Assert end is in striped sram */

				    ASSERT(__persistent_data_end__ <= SRAM_STRIPED_END, "Persistent data ends outside striped sram")

Yes, for the end checks, as the end address is set to the next address you can place data

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin 'powman-fixups:powman-fixups'

git switch 'powman-fixups'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'develop'

git merge --no-ff 'powman-fixups'

git switch 'powman-fixups'

git rebase 'develop'

git switch 'develop'

git merge --ff-only 'powman-fixups'

git switch 'powman-fixups'

git rebase 'develop'

git switch 'develop'

git merge --no-ff 'powman-fixups'

git switch 'develop'

git merge --squash 'powman-fixups'