RE: VPR hibernate

Håkon Alseth — Wed, 01 Jul 2026 12:22:24 GMT

Hi,

Thanks for sharing these measurements. This is very interesting to look at!

Given that the rest of the system state is similar, regardless of running off of Cortex M33 or the RISC-V, I guess it makes sense that they perform equal (or very much close to).

Kind regards,

Håkon

RE: VPR hibernate

bios-bob — Wed, 01 Jul 2026 02:09:02 GMT

an early peek into the fruits of my labor -- a tiny BLE peripheral stack (written in EM•Script) which runs on the FLPR and executes from a *single* 16K SRAM block.... quite remarkably, it's power profile is essentially identical to the same code running on the main M33 cpu....

RE: VPR hibernate

Håkon Alseth — Mon, 29 Jun 2026 14:30:33 GMT

Hi Bob,

That is great to hear! Let me know if you run into any VPR related issues, or have any questions.

I hope you have a wonderful day!

Cheers,

Håkon

RE: VPR hibernate

bios-bob — Mon, 29 Jun 2026 13:22:46 GMT

hi hakon,

this actually filled in the missing pieces for me....

my bare-metal FLPR program is now able to awake from an idle state that consumes only 1.2uA....

RE: VPR hibernate

Håkon Alseth — Mon, 29 Jun 2026 08:56:02 GMT

Hi Bob,

I must first apologise for throwing a lot of links and information at you. The support for lower power modes on VPR is considered experimental at this time, as the functionality is still work-in-progress.

Since you mention errata, I will share the link here for reference

https://docs.nordicsemi.com/r/bundle/errata_nrf54l15_rev2/page/err/nrf54l15/rev2/latest/err_l15_new.html

and it is specifically erratum 16, 17, 18 that is affecting the VPR peripheral directly.

We have a generic introduction to the nRF54L-series VPR here:

https://docs.nordicsemi.com/r/bundle/ngl_004/page/gl/ngl_004/frontpage.html

[quote user=""]

when my FLPR code "idles" using the WFI instruction, power consumptions remains around 500uA -- which is consistent with what i've read elsewhere....

[/quote]

This is because the default sleep state is WAIT (actually "RESET", but this is very similar in terms of keeping clocks running):

https://docs.nordicsemi.com/r/bundle/ps_nrf54l15/page/vpr.html-register.nordic.vprnordicsleepctrl

To reach a deeper sleep, the .SLEEPSTATE field must be changed to for instance DEEPSLEEP/HIBERNATE. However; this also requires the application to actively retain RAM.

The documentation in the datasheet is not that verbose, and we have a specific chapter in the previously linked VPR guidelines:

https://docs.nordicsemi.com/r/bundle/ngl_004/page/gl/ngl_004/sleep_mode_operation.html

Hibernation / RAM retaining support for VPR was added recently, and it is available in the ncs v3.4.0-rc releases (v3.4.0-rc2 being the latest):

https://github.com/nrfconnect/sdk-zephyr/commit/0f7c3590bdae4aff059357b3f46378166a8a4659

https://github.com/zephyrproject-rtos/zephyr/pull/106190

And there is a improved solution just being merged in upstream zephyr as well:

https://github.com/zephyrproject-rtos/zephyr/pull/111480

You should be on a bleeding edge tag (v3.4.0-rc1 or newer) to obtain errata workarounds as well as hibernate support for VPR.

Hibernate is the default sleep mode in v3.4.0-rc1 and newer, so no need to do an active change.

PS:

Errata #18 (https://docs.nordicsemi.com/r/bundle/errata_nrf54l15_rev2/page/err/nrf54l15/rev2/latest/anomaly_l15_18.html) is not handled yet in the code base.

The workaround here is effectively to do a dummy-write to the NRF_VPR memory map after waking up from WFI. In zephyr, this is where it goes to idle:

https://github.com/nrfconnect/sdk-zephyr/blob/main/arch/riscv/core/cpu_idle.c#L16

And you should append something like this after waking up from WFI:

int volatile * const vpr_reg = (int *) 0x5004C804;
*vpr_reg = 0x1234;

Please note that the above workaround is not finalised, so the polished solution will likely look a bit different.

Let me know if you have any questions or run into any issues.

Kind regards,

Håkon