Hi, I have implemented a soft UART in the VPR FLPR. I am having trouble power managing it. I see an unexplained extra 500 uA current draw after I start the CPR until I reset the CPU.
Environment
- Device: nRF54L15
- SDK: nRF Connect SDK v2.9.2 (also checked sdk-nrf v3.2.4 + sdk-zephyr ncs-v3.2.4) (we need ANT support, 2.9.2 is the only SDK that allows this. ANT for 3.2 is promised "March 2026", of which there are two days remaining.)
Summary
Once the FLPR (VPR) coprocessor on nRF54L15 has been started via nrf_vpr_cpurun_set(vpr, true), the VPR peripheral block draws ~500 µA that cannot be recovered without a full system reset. The 128 MHz PLL is confirmed NOT running (CLOCK.PLL.STAT.STATE = NotRunning). The excess current comes from the VPR peripheral block itself.
Use case
This is a bit-banged UART, because the only available pins were on P2, and were not the dedicated UARTE pins. I need to power it off when not in use, because "bit banged UART" and "cr2032 powered" are conflicting ideas...
Isolation testing
We systematically isolated the current source:
| Configuration | Boot current |
| baseline (no FLPR code at all) | 500 µA |
| VEVIF TX/RX enabled, MBOX enabled, flpr_uart_dev enabled, VPR launcher disabled (FLPR never started) | 500 µA |
| VPR launcher enabled (FLPR starts, enters WFI) | 1000 uA |
| Hardware UARTE instead of FLPR (VPR/VEVIF disabled), same shell lifecycle | 500 µA after shell session |
Conclusion
The VEVIF/MBOX hardware draws zero extra current. The extra 500 µA appears only after `nrf_vpr_cpurun_set(vpr, true)` has been called.
Register state during excess current
PLL=Off CPURUN=Stop: after NDMRESET
NRF_CLOCK->PLL.STAT: STATE = NotRunning (128 MHz PLL is off)
NRF_VPR130->CPURUN: EN = Stopped (after CPURUN=false + NDMRESET)
What we tried
| Approach | Result |
| nrf_vpr_cpurun_set(vpr, false) | CPURUN only affects state after reset |
| CPURUN=Stopped + NDMRESET pulse via DEBUGIF.DMCONTROL | CPURUN reads Stopped, PLL reads Off, current unchanged |
| FLPR sets NRF_VPR_CSR_SLEEP_STATE_SLEEP before WFI | Partial: ~650 µA at boot (vs ~1 mA), no effect after active session |
| FLPR sets NRF_VPR_CSR_SLEEP_STATE_DEEP_SLEEP before WFI | No improvement over SLEEP |
| FLPR sets NRF_VPR_CSR_SLEEP_STATE_HIBERNATE | No improvement |
| nrf_clock_task_trigger(NRF_CLOCK, NRF_CLOCK_TASK_PLLSTOP) | No improvement (PLL was already off) |
| Disabling MBOX/VEVIF RX via mbox_set_enabled_dt() | No improvement |
| Not starting VPR at boot, only on demand | Boot = 500 µA, but after one start/stop cycle = 1 mA |
Questions
1. What mechanism powers down the VPR peripheral block on nRF54L15 after it has been started? Is there a register analogous to `NETWORK.POWER.FORCEOFF` on nRF5340?
2. The PLL is off and CPURUN is Stopped, yet the VPR peripheral draws ~500 µA. What is consuming this power?
3. Is there a way to return the VPR peripheral to its pre-nrf_vpr_cpurun_set(true) state without a full system reset?
4. Are there plans to add PM_DEVICE support to the nordic_vpr_launcher driver?
Notes
- SDK 3.2.4 VPR launcher still has no PM support
- SDK 3.2.4 DT binding made execution-memory optional but doesn't address power-down
- nRF54H20 has LRCCONF per-domain power control; nRF54L15 does not
- nRF54L15 product spec does not document a VPR peripheral power gate
