FOTA updates on nRF54L Series devices

You can update the firmware of the device over the air, thus without a wired connection. Such an update is called a FOTA (firmware over-the-air) update. You can also use FOTA updates to replace the application. See the MCUboot and NSIB page for general Device Firmware Update (DFU) information, such as supported methods for sending and receiving updates on the device. Currently, FOTA updates are supported only for the application core. For more information about introducing immutable MCUboot bootloader, refer to Adding MCUboot as an immutable bootloader.

Note

The nRF54L SoC’s support hardware Key Management Unit (KMU), designed to provide authentication keys for DFU purposes. Ensure you complete the KMU provisioning during your device’s DFU setup with KMU enabled. Failing to do so may prevent your application from booting properly.

FOTA over Bluetooth Low Energy

Note

The Bluetooth LE FOTA method is suited for local, proximity-based updates. For production fleet management where you need to manage update rollouts across large production fleets, target specific device cohorts, monitor update progress, and roll back on failure, you can use nRF Cloud powered by Memfault to manage FOTA updates remotely from the cloud. See nRF Cloud FOTA for further details on nRF Cloud FOTA.

FOTA updates are supported using MCUmgr’s Simple Management Protocol (SMP) over Bluetooth®. The application acts as a GATT server and allows the connected Bluetooth Central device to perform a firmware update. To use FOTA over Bluetooth LE, samples must support Bluetooth peripheral role (CONFIG_BT_PERIPHERAL).

By default, the application supports SMP handlers related to:

  • Image management

  • Operating System (OS) management, which is used to reboot the device after completing firmware uploads

  • Erasing the settings partition to prevent booting a new application with incompatible content that was written by the previous application

To enable support for FOTA updates, do the following:

  • Enable the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU Kconfig option, which implies configuration of the following:

    Note

    The CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU Kconfig option enables the device to use MCUmgr for performing firmware over-the-air (FOTA) updates using Bluetooth LE. It can be used along with other samples, and is meant as a demonstration of the default DFU configuration over Bluetooth.

    Note

    To prevent an unauthenticated access to the device over SMP, it is strongly recommended to enable the CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN option. This will enforce a remote device to initiate a pairing request before accessing SMP characteristics.

If necessary, you can modify any of the implied options or defaulted values introduced by the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU Kconfig option.

You can either add these Kconfig options to the configuration files of your application or have them inline in a project build command. Here is an example of how you can build for the Bluetooth: Peripheral LBS sample:

 west build -b board_target -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

When you connect to the device after the build has completed and the firmware has been programmed to it, the SMP Service is enabled with the UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84. If you want to add SMP Service to advertising data, refer to the MCUboot SMP Server sample.

Testing steps

To perform a FOTA update, complete the following steps:

  1. Locate the dfu_application.zip archive in the build directory. The archive is automatically generated after adding the DFU configuration and building your project.

    Note

    For each image included in the DFU-generated package, use a higher version number than your currently active firmware. You can do this by modifying the VERSION file in the application directory or by making changes to the application code. For the semantic versioning, modify the CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION Kconfig option. For the monotonic counter (HW), modify the SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE Kconfig option. Otherwise, the DFU target may reject the FOTA process due to a downgrade prevention mechanism.

  2. Download the dfu_application.zip archive to your mobile phone. See Output build files (image files) for more information about the contents of update archive.

    Note

    nRF Connect for Desktop does not currently support the FOTA process.

  3. Use the nRF Connect Device Manager mobile app to update your device with the new firmware.

    1. Ensure that you can access the dfu_application.zip archive from your phone or tablet.

    2. In the mobile app, scan and select the device to update.

    3. Switch to the Image tab.

    4. Tap the SELECT FILE button and select the dfu_application.zip archive.

    5. Tap the START button.

    6. Initiate the DFU process of transferring the image to the device:

      • If you are using an Android phone or tablet, select a mode in the dialog window, and tap the START button.

      • If you are using an iOS device, tap the selected mode in the pop-up window.

      Note

      For samples using random HCI identities, the Test and Confirm mode should not be used.

    7. Wait for the DFU to finish and then verify that the new application works properly by observing the new device name visible in the Device Manager app.

    8. After confirming if the advanced tool mode was used, reset the device again. This ensures that the new application runs correctly and allows you to revoke old signature keys if desired.

FOTA update sample

The MCUboot SMP Server sample demonstrates how to set up your project to support FOTA updates.

When working in the nRF Connect SDK environment, ignore the part of the sample documentation that describes the building and programming steps. In nRF Connect SDK, you can build and program the MCUboot SMP Server sample as any other sample using the following commands:

 west build -b board_target -- -DEXTRA_CONF_FILE=overlay-bt.conf
 west flash

Make sure to indicate the overlay-bt.conf overlay configuration for the Bluetooth transport like in the command example. This configuration was carefully selected to achieve the maximum possible throughput of the FOTA update transport over Bluetooth with the help of the following features:

Consider using these features in your project to speed up the FOTA update process.

Provisioning of keys for Hardware KMU

Note

The MCUboot bootloader does not yet support KMU for nRF54LM20.

In case of FOTA implementations using the MCUboot bootloader, which includes hardware cryptography and KMU, you must complete key provisioning before booting any application. Otherwise, the bootloader might not boot the firmware setup and might take unwanted actions. Refer to Provisioning the KMU for detailed description.

Build configuration additions for MCUboot in the direct-xip mode

FOTA updates are also supported when MCUboot is in the direct-xip mode. In this mode, the MCUboot bootloader boots an image directly from a given slot, so the swap operation is not needed. It can be used either with or without the revert mechanism support. For more information about the direct-xip mode and the revert mechanism support, go to the Equal slots (direct-xip) section on the Bootloader page.

Note

Direct-xip mode cannot be combined with image encryption. In addition, when building a project with direct-xip for the nRF54L SoC targets, a static partition manager file is required for partitioning. See NCSDK-30119 issue on the Known issues page.

To use MCUboot in the direct-xip mode together with FOTA updates, do the following:

See how to build the Bluetooth: Peripheral LBS sample with MCUboot in the direct-xip mode when the revert mechanism support is disabled:

 west build -b board_target -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DSB_CONFIG_MCUBOOT_MODE_DIRECT_XIP=y -DCONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Optionally, if you want to enable the revert mechanism support, complete the following:

See how to build the Bluetooth: Peripheral LBS sample with MCUboot in direct-xip mode when the revert mechanism support is enabled:

 west build -b board_target -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DSB_CONFIG_MCUBOOT_MODE_DIRECT_XIP_WITH_REVERT=y -DCONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Note

When building the application with MCUboot in direct-xip mode with revert mechanism support, the signed image intended for flashing is automatically marked as confirmed (Pre-confirmation).

Both the SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP and SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP_WITH_REVERT Kconfig options automatically build application update images for both slots. To read about the files that are built when the option is enabled, refer to the MCUboot output build files page.

Note

Support for FOTA updates with MCUboot in the direct-xip mode is available since the following versions of the nRF Connect Device Manager mobile app:

  • Version 1.8.0 on Android.

  • Version 1.4.0 on iOS.