Environment
- nRF Connect SDK v3.4.1 (nrfxlib v3.4.1), modem firmware 2.0.4
- Board: nRF9151 DK, target nrf9151dk/nrf9151/ns, sysbuild with MCUboot serial recovery
- Application: LTE-M/NB-IoT session with lte_lc + MQTT/TLS (modem active before the DFU entry)
Flow and observation (2 out of 3 attempts)
1. DFU entry from the application: lte_lc_offline(); nrf_modem_lib_shutdown(); sys_reboot(SYS_REBOOT_COLD);
2. MCUboot serial recovery: upload a new application image (nrfutil mcu-manager), then `serial reset`.
3. On the next application boot we observed:
- log: `Modem domain event: Reset loop` (LTE_LC_MODEM_EVT_RESET_LOOP), and
- a non-secure SecureFault taken from the modem IPC interrupt path:
Exception came from non-secure FW in handler mode.
LR: 0x000411f9 PC: 0x00041194 R6: 0x00000000
SFSR: 0x00000048 (AUVIOL|SFARVALID) SFAR: 0x00000000
Disassembly shows PC=0x41194 inside handle_modem_rpc_msg in the precompiled libnrf_modem (`ldr r3,[r6]` with r6 = NULL - an RPC queue pointer that is not initialized yet), reached from rpc_message_handler via the modem IPC interrupt.
Counter test (no shutdown)
If the application just calls sys_reboot() without shutting the modem down, the same dfu -> recovery -> `serial reset` flow was clean: 6 out of 6 consecutive loops, no Reset loop event, no fault. An additional isolation test (set the recovery boot mode from a debugger, cold reboot into recovery, no modem interaction) was also clean.
Questions
1. Is calling nrf_modem_lib_shutdown() right before rebooting into MCUboot serial recovery (application-only DFU) a supported sequence? The Modem bootloader documentation requires nrf_modem_shutdown() only for a modem firmware update; our flow updates only the application.
2. Is the handle_modem_rpc_msg NULL-queue crash a known issue when the modem is re-initialized shortly after a graceful shutdown plus two resets? Note: per the %MDMEV documentation the Reset loop restriction counts more than 7 resets without a graceful +CFUN=0, but here the modem was shut down gracefully before the first reset and only two resets happened - so we do not understand how the event was triggered either.
3. What is the recommended sequence for entering serial recovery from a running application: keep the modem running, or shut it down first (and in that case, anything else to observe)?
Current workaround: we removed the shutdown from the DFU entry - the modem stays running across the reset into recovery and the failure no longer occurs. No negative effect observed so far. We can provide full register dumps, the application ELF and further logs on request.