RE: nRF54L15 hangs in MCUBoot

gjea — Fri, 31 Jul 2026 15:40:19 GMT

Thanks for the quick turnaround. I applied PR #4332 to my local v3.4.0 tree and tested it on the nRF54L15 DK with the attached reproducer. It does fix the reported case — the board now boots cleanly through every watchdog cycle instead of hanging on the first boot.

Two things I think are worth looking at before it lands, though.

1. The GRTC is not actually left running when STOP_AT_UNINIT=n. nrfx_grtc_uninit() clears MODE.SYSCOUNTEREN unconditionally; STOP_AT_UNINIT only gates the additional TASKS_STOP. I re-ran my bounded read probe with the PR applied, so the LFCLK is now kept alive, and the post-uninit read still never completes:

grtc_probe_mode  = 0x00000000    /* MODE cleared by nrfx_grtc_uninit() */
grtc_probe_tries = 10000000      /* bound exhausted                    */
grtc_probe_sch   = 0x40000000    /* BUSY still set                     */

So keeping the 32 kHz source does not make the counter readable — it is switched off, not asleep. The PR works by removing the caller (the calibration-timer abort), which is the same mechanism as the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n workaround, rather than by fixing the teardown order.

2. The hang is still reachable wherever STOP_AT_UNINIT=y, which is the default for every non-MCUboot image. sys_clock_disable() is also called from sys_reboot() (zephyr/lib/os/reboot.c:42), and with STOP_AT_UNINIT=y the PR's added condition is satisfied, so the preprocessor output is identical to unpatched. Measured on the DK:

	`STOP_AT_UNINIT=n` (MCUboot)	`STOP_AT_UNINIT=y` (default elsewhere)
v3.4.0 as shipped	hangs	hangs
PR #4332	boots	hangs — same PC, `MODE = 0`, `BUSY` set, counter frozen at 97.9 ms
release LFCLK before `nrfx_grtc_uninit()`	boots	boots

Simply moving the onoff_release() block above nrfx_grtc_uninit() covers both columns, and I think it also matches your own diagnosis more closely: if the problem is that the 32 kHz source is released while the GRTC still needs it, the fix is to release it before tearing the GRTC down rather than to skip the release in one build configuration.

Separately, would you consider bounding the retry in nrfy_grtc_sys_counter_get(), or early-returning when nrfx_grtc_init_check() is false? It would not have prevented this hang — nothing on the read side can, once the counter is off — but it turns a silent lockup into a detectable error, and case 126653 shows a second, unrelated caller wedging in the same loop at PRE_KERNEL_1.

See the attached file 'nrf54l15-grtc-sys-clock-disable-ordering.diff' for a suggested fix.

devzone.nordicsemi.com/.../nrf54l15_2D00_grtc_2D00_sys_2D00_clock_2D00_disable_2D00_ordering.diff

RE: nRF54L15 hangs in MCUBoot

Vidar Berg — Fri, 31 Jul 2026 10:37:49 GMT

Update: it turns out the 32 KHz clock source is released even though the GRTC is configured to keep running after sys_clock_disable(). Thanks to your report and reproducer, the developer was able to quickly identify the issue and create this PR: https://github.com/nrfconnect/sdk-zephyr/pull/4332/changes/14bcb67edfd6a0ecd6dd024676b6aac335338617

RE: nRF54L15 hangs in MCUBoot

Vidar Berg — Thu, 30 Jul 2026 13:47:00 GMT

Hello,

Thank you for reporting this and for providing a sample to reproduce. I will need some time to review and discuss with the developers. Will update as soon as I know more.

Best regards,

Vidar