CONFIG_PM_DEVICE_RUNTIME breaks nrf9151

[Alexey Papkovskiy]

We have been trying to upgrade nRF connect SDK from v3.1.1 to v3.2.1 and run into the following issue:

When we enable CONFIG_PM_DEVICE_RUNTIME=y after flashing, the device gets inaccessible via J-LINK.

It is easy to reproduce on nrf9151dk, blinky sample, by adding the following config:

CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y
CONFIG_PM_DEVICE_POWER_DOMAIN=y
CONFIG_POWER_DOMAIN=y

After flashing, the device becomes inaccessible via J-LINK.

nrfutil device reset
❌ Failed to reset 1051215211, Failed to attach to target: 
The Application core access port is protected Error: One or more reset tasks failed:
 * 1051215211: Failed to attach to target:
 The Application core access port is protected (All) (NotAvailableBecauseProtection)


The operation was unavailable for some of the devices because they had readback protection enabled. These devices might be possible to unlock using the `recover` subcommand. See `nrfutil device recover --help` for more information.

If CONFIG_PM_DEVICE_RUNTIME is disabled, everything works as expected. 

[Alexey Papkovskiy]

Thanks for the clarification. I agree that missing test coverage is likely the main reason why issues like the shell bypass case slip through. Areas that are not exercised by automated tests will inevitably depend on real-world usage to reveal problems.

That said, the observation that prompted my original comment still stands: the issues I mentioned did not make it into official Zephyr releases, but they did appear in the NCS SDK. So even if they originated in upstream Zephyr at some point in time, they were already fixed again before a stable Zephyr release was cut.

From the perspective of someone using the SDK, this creates the impression that the integration point between Zephyr and NCS sometimes happens during a window where a regression briefly exists upstream but has not yet been corrected in the fork.

In any case, thanks for the explanation and for looking into this.

Best regards,
Alexey