nRF Cloud, FOTA, Device Manager app questions

RE: nRF Cloud, FOTA, Device Manager app questions

Maximilian Deubel — Tue, 28 Jul 2026 11:29:11 GMT

Hi!
Unfortunately, the transport is not very fast. It takes quite a while to transfer the image over BLE. Then, flash pages need to be moved around to apply the image. We use a dual-slot system by default, but the app is compiled to run on the first slot, so it has to be moved there. In summary, I cannot recommend using MCUBoot DFU in the manufacturing line. Use something fast, like SWD probes to program the production firmware to the devices. Our software tools interface well with Segger J-Links, but it should be relatively simple to support any kind of probe. When the device needs to be updated in customers hands, it's normal and hard-to-avoid to have these long update times.

An advanced option could be to compile the application to execute in-place to avoid the swap times: https://devzone.nordicsemi.com/f/nordic-q-a/127248/nrf54l15-applicability-of-mcuboot-direct_xip-mode/562694

Best regards,
Max.

RE: nRF Cloud, FOTA, Device Manager app questions

garrettb — Mon, 27 Jul 2026 22:24:16 GMT

One more question on this.

When I use the Device Manager app to upgrade the nRF54L15-based device, it seems to take about 140 seconds.

Is there a reason it takes this long, or is there something I might be doing wrong?

I have accepted this delay all along, but it occurs to me now, as the device is going in to production, that this is a very long time to wait, per device. If the manufacturer is to program 100's of devices this way.

Example log output:

00> *** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
00> *** Using nRF Connect SDK v2.9.2-4ab7b98fc76f ***
00> *** Using Zephyr OS v3.7.99-aa34a5632971 ***
00> [00:01:10.132,202] <inf> mcuboot: Starting bootloader
00> [00:01:10.132,620] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> [00:01:10.132,811] <inf> mcuboot: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
00> [00:01:10.132,979] <inf> mcuboot: Boot source: none
00> [00:01:10.133,119] <inf> mcuboot: Image index: 0, Swap type: perm
00> [00:01:13.537,106] <inf> mcuboot: Starting swap using move algorithm.
00> [00:03:21.861,185] <inf> mcuboot: Bootloader chainload address offset: 0xc000
00> [00:03:21.861,333] <inf> mcuboot: Jumping to the first image slot

RE: nRF Cloud, FOTA, Device Manager app questions

Natasha_C — Tue, 14 Jul 2026 20:46:00 GMT

Hi Garett,

Question 4: The “Expected Swap Time” setting in the Android app does not seem to have any affect on the process other than trigger the state change from RESETTING to UPLOAD COMPLETE. Is this meant to have a different functionality?

The "Estimated Swap Time" is a timing hint that tells the Android app how long to wait for the device to attempt reconnecting to a device (while it is rebooting due to a firmware update). It doesn't change what the device does, so setting it only affects how long the app pauses during the RESETTING phase before moving on.

Question 5: Finally, at one stage I had two releases activated in nRF Cloud. Let’s say the device was running 0.01, and 0.02 was released, and later 0.03 was released. When I then connected the app to the device, and selected Check for Updates, the app pop-up indicated that version 0.02 was available. I would have expected to indicate the newest (0.03) version. I then deleted v0.02 in nRF Cloud, and tried again, and this time it indicated v0.03 was available. Note: Neither release had the “Must Pass Through” setting selected.

We aren’t going to be able to give a definitive answer without knowing more about the device, what cohort it was assigned to at the time, and more about the releases available. Here is some more information on how the system decides which OTA release to send when a device checks in for updates: Over-the-Air Updates (OTA) | nRF Cloud Docs

Thanks,

RE: nRF Cloud, FOTA, Device Manager app questions

Natasha_C — Tue, 14 Jul 2026 19:32:13 GMT

Hi Garett,

Great to hear you were able to make so much progress!

Question 1: What is the expected behaviour of the app? When should it change state from RESETTING to UPLOAD COMPLETE?

The state changes to UPLOAD COMPLETE in the nRF Connect Device Manager app once the firmware image has been fully transferred to the device over Bluetooth LE and the device has rebooted and swapped to the new image via MCUboot.

Question 2: How is the app meant to know when the device has successfully completed the swap, and is now running the new firmware?

The app itself detects UPLOAD COMPLETE after the SMP transfer finishes and the device reconnects post-reboot. The firmware correctness is confirmed by MCUboot's test/confirm mechanism on the device side, and optionally by the application explicitly calling boot_set_confirmed() after successful initialization.

Question 3: How is nRF Cloud meant to know that a device has updated its firmware – should this information not be sent automatically from the app, after the swap occurs, without the user having to reconnect the app and device, and then select Check for Updates?

nRF Cloud does not automatically know the device has updated unless the device (or the gateway app acting on its behalf) reports back.

I'll get back to you on this one.

Thanks,