CAF: Simple Management Protocol module

The simple management protocol module of the Common Application Framework (CAF) allows to perform the device firmware upgrade (DFU) over Bluetooth® LE.

Configuration

To use the module, you must enable the following Kconfig options:

Enabling remote OS management

The simple management protocol module supports registering OS management handlers automatically, which you can enable using the following Kconfig option:

  • CONFIG_MCUMGR_GRP_OS - This option enables MCUmgr OS management handlers. Use these handlers to remotely trigger the device reboot after the image transfer is completed. After the reboot, the device starts using the new firmware. One of the applications that support the remote reboot functionality is nRF Connect for Mobile.

Implementation details

The module periodically submits ble_smp_transfer_event during the image upload. The module registers the upload_confirm_cb() callback that is used to submit ble_smp_transfer_event. The module registers itself as the final subscriber of the event to track the number of submitted events. If a ble_smp_transfer_event was already submitted but not processed, the module desists from submitting a subsequent event. After the previously submitted event is processed, the module submits a subsequent event when the upload_confirm_cb() callback is called.

The application user must not perform more than one firmware upgrade at a time. The modification of the data by multiple application modules can result in a broken image that is going to be rejected by the bootloader.

You can perform the DFU using, for example, the nRF Connect for Mobile application. The DFU button appears in the tab of the connected Bluetooth device that supports the image transfer over the Simple Management Protocol (SMP). After pressing the button, you can select the *.bin file used for the firmware update.

After building your application for configuration with the simple management protocol module enabled, the following firmware update files are generated in the build directory:

  • zephyr/app_update.bin - The application image that is bootable from the primary slot.

  • zephyr/mcuboot_secondary_app_update.bin - The application image that is bootable from the secondary slot. The file is generated only if the MCUboot bootloader is built in the direct-xip mode.

If the MCUboot bootloader is built in the direct-xip mode, you must upload the image to the slot that is currently unused. If the MCUboot bootloader is built in the swap mode instead, you must use the zephyr/app_update.bin file. In the swap mode, the MCUboot bootloader always moves the new application image to the primary slot before booting it. For more information about the MCUboot configuration, see the MCUboot documentation.

Note

If the CONFIG_MCUMGR_GRP_IMG_REJECT_DIRECT_XIP_MISMATCHED_SLOT Kconfig option is enabled in the application configuration, the device rejects an update image upload for the invalid slot. It is recommended to enable the option if the application uses MCUboot in the direct-xip mode. The upload rejection can be used as a simple mechanism of verifying which image update should be used.