Environment
- nRF Connect SDK v3.4.1 (sdk-mcuboot: tag ncs-v3.4.1, commit 8122be0)
- Board: nRF9151 DK, board target nrf9151dk/nrf9151/ns; sysbuild with MCUboot; serial recovery over the DK VCOM (UART)
- Modem firmware 2.0.4; host: Windows + nrfutil (mcu-manager)
Summary
When the application requests serial recovery through the bootloader-request subsystem, MCUboot enters serial recovery but never clears the consumed request. After the first use, the device enters serial recovery on every reset and the application no longer boots. Because the request lives in retained SRAM, only a full power cycle clears it - pin resets, `nrfutil mcu-manager serial reset` and watchdog resets all re-enter recovery.
This contradicts the documented one-shot behavior of bootloader requests ("The bootloader always erases the boot mode requests after processing them, ensuring that the special mode is entered only once.").
Configuration used
- MCUboot (sysbuild/mcuboot/prj.conf):
- CONFIG_NRF_MCUBOOT_BOOT_REQUEST=y
- CONFIG_NRF_BOOT_SERIAL_BOOT_REQ=y
- CONFIG_RETENTION=y, CONFIG_RETAINED_MEM=y, CONFIG_CRC=y
- The request area is a 16-byte `zephyr,retention` node (top of the non-secure SRAM, 0x2003FFF0 on nRF9151) selected through the `nrf,bootloader-request` chosen property; prefix [0B 01].
- Application:
- CONFIG_MCUBOOT_BOOTUTIL_LIB=y (so the bootutil boot-request API can be linked from the application; our configuration also had CONFIG_NRF_MCUBOOT_BOOT_REQUEST=y).
Steps to reproduce
1. Build the configuration above and flash both images.
2. From the application: call boot_request_init(); boot_request_enter_recovery(); then sys_reboot(SYS_REBOOT_COLD);
3. MCUboot enters serial recovery (expected).
4. Send `nrfutil mcu-manager serial reset` (or press the reset button).
5. Observed: the device enters serial recovery again instead of booting the application. Every further reset re-enters recovery.
6. Reading the retained area with a debugger shows the recovery request (0x01) is still present after serial recovery has been entered.
Analysis (sdk-mcuboot, tag ncs-v3.4.1)
- boot/zephyr/main.c, inside main():
#ifdef CONFIG_NRF_BOOT_SERIAL_BOOT_REQ
if (boot_request_detect_recovery()) {
BOOT_LOG_DBG("Staying in serial recovery");
boot_serial_enter(); /* never returns */
}
#endif
boot_request_detect_recovery() (boot/bootutil/zephyr/src/boot_request.c) only reads the entry - it does not clear it.
- The only boot_request_clear() call in the tree is at boot/zephyr/main.c:898, on the normal boot path after boot_go(). It is unreachable whenever the request has just been consumed by the block above.
- For comparison, the Zephyr boot-mode entrance in the same file (CONFIG_BOOT_SERIAL_BOOT_MODE -> io_detect_boot_mode() in boot/zephyr/io.c) calls bootmode_clear() before returning true - that entrance is correctly one-shot.
- The firmware-loader variant uses the same detect-only pattern (boot_request_detect_firmware_loader() in boot/zephyr/firmware_loader.c); we have not tested it, but it may have the same problem.
Impact
Once triggered, the application cannot boot again until the retained SRAM area is cleared by a full power cycle (or an external write). On a battery-powered product this effectively requires a battery disconnect; no reset recovers it.
Workaround we switched to
We abandoned the boot-request entrance and use the Zephyr retention boot-mode entrance instead:
- Application: CONFIG_RETENTION_BOOT_MODE=y; bootmode_set(BOOT_MODE_TYPE_BOOTLOADER); sys_reboot();
- MCUboot: CONFIG_RETENTION_BOOT_MODE=y, CONFIG_BOOT_SERIAL_BOOT_MODE=y (clears the value on entry - one-shot);
- Devicetree: a `zephyr,boot-mode` chosen node pointing at a `zephyr,retention` area.
This works correctly, but the boot-request entrance (the first alternative offered by Kconfig) is unusable as-is.
Suggested fix
Call boot_request_clear() (or clear only the boot-mode entry) right before boot_serial_enter() in the CONFIG_NRF_BOOT_SERIAL_BOOT_REQ block of main.c, so the request is consumed exactly once, as documented.
Question
Can you confirm this is a defect and that a fix is planned? Should the firmware-loader entrance be fixed the same way? We can provide the failing sequence details and memory dumps on request.
