"I am using nRF Connect SDK (NCS) v3.1.0 and developed BLE DFU functionality by referencing the Nordic Semiconductor Academy course: 'Exercise 5: FOTA over Bluetooth Low Energy'. However, I now want this DFU functionality to be enabled only when the device is in a specific operating mode. How should I implement this?"
Hello,
In what scenario do you want this to happen? How do you want to determine whether a user is allowed to perform DFU or not?
Since all DFU images are signed by default, it is usually enough. The transfer will happen in the background, but if the image is invalid, it will never be swapped.
What is it that concerns you that makes you want this specific operating mode?
Best regards,
Edvin
Thank you for the clarification.
In my case, the concern is not about image authenticity or security, since we are already using MCUboot with signed images, and invalid images will never be swapped as you mentioned.
The reason I want to restrict DFU to a specific operating mode is mainly related to product behavior and user workflow, not security.
This device has multiple operating modes (e.g. normal operation, connected/active mode, pairing mode, and a dedicated maintenance mode). During normal operation, the device may be actively used (connected to another system, performing control or motion-related tasks), and allowing DFU at any time could cause unexpected interruptions or unsafe behavior.
Therefore, we require DFU to be possible only when the device is explicitly placed into a maintenance mode, which is entered through a controlled command sequence or physical interaction. This maintenance mode is intended for service, manufacturing, or firmware update purposes only.
In other words, DFU is intentionally treated as a maintenance operation, not a background feature available during normal runtime. The goal is to prevent accidental or unintended DFU attempts during normal use, even if the image itself is valid and signed.
Based on this requirement, I am looking for the recommended way in NCS/MCUmgr to gate or reject DFU commands depending on the current application mode.
I understand. I am still not sure having it there actually causes any inconvenience, but I am not sure exactly sure how it will be operated during normal operation.
However, I figured out it is possible.
If you add this to your application's prj.conf:
CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION=y
Then you can easily enable and disable the smp_server (DFU service) using:
smp_bt_register()
smp_bt_unregister()
Best regards,
Edvin
Thanks for the suggestion.
We actually tried a very similar approach earlier. In our implementation, we called smp_bt_unregister() at boot, and only called smp_bt_register() when the device entered Maintenance Mode.
However, what we observed is that if the device is already in an active BLE connection, calling smp_bt_register() does not make the SMP service visible to the Central. In practice, the Central never re-discovers the service, and in some cases the behavior becomes undefined.
From our understanding, this is expected, because modifying the GATT table (adding/removing services) during an active BLE connection is not supported by the Bluetooth specification. The GATT database is assumed to be fixed at connection time.
Therefore, it seems that enabling the SMP service using dynamic service registration only works reliably if it is done while not connected, followed by a disconnect/reconnect sequence.
Could you please confirm if this understanding is correct, and whether the intended usage of CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION is to enable/disable the SMP service between connections rather than during an active connection?
Enabling CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION updates the GATT table during runtime, but the service discovery (done by the central) typically happens directly after connection.
I am not sure if it is possible to force a new service discovery, but the easiest workaround is probably to make the peripheral disconnect at this point, and have the operator reconnect in "DFU mode". If it is done by service personel, that shouldn't be a big concern.
Best regards,
Edvin
Enabling CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION updates the GATT table during runtime, but the service discovery (done by the central) typically happens directly after connection.
I am not sure if it is possible to force a new service discovery, but the easiest workaround is probably to make the peripheral disconnect at this point, and have the operator reconnect in "DFU mode". If it is done by service personel, that shouldn't be a big concern.
Best regards,
Edvin
