<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BLE DFU</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/126119/ble-dfu</link><description>&amp;quot;I am using nRF Connect SDK (NCS) v3.1.0 and developed BLE DFU functionality by referencing the Nordic Semiconductor Academy course: &amp;#39; Exercise 5: FOTA over Bluetooth Low Energy &amp;#39;. However, I now want this DFU functionality to be enabled only when the</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 22 Dec 2025 07:32:50 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/126119/ble-dfu" /><item><title>RE: BLE DFU</title><link>https://devzone.nordicsemi.com/thread/557500?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2025 07:32:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5fbaae92-f82a-4943-a79f-1299fa81a284</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Enabling&amp;nbsp;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.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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 &amp;quot;DFU mode&amp;quot;. If it is done by service personel, that shouldn&amp;#39;t be a big concern.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE DFU</title><link>https://devzone.nordicsemi.com/thread/557492?ContentTypeID=1</link><pubDate>Mon, 22 Dec 2025 01:40:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1fa699de-f68d-4cff-bd98-3993b31a2dfa</guid><dc:creator>nicky_liu</dc:creator><description>&lt;p data-start="193" data-end="221"&gt;Thanks for the suggestion.&lt;/p&gt;
&lt;p data-start="228" data-end="422"&gt;We actually tried a very similar approach earlier. In our implementation, we called &lt;code data-start="312" data-end="333"&gt;smp_bt_unregister()&lt;/code&gt; at boot, and only called &lt;code data-start="359" data-end="378"&gt;smp_bt_register()&lt;/code&gt; when the device entered Maintenance Mode.&lt;/p&gt;
&lt;p data-start="429" data-end="707"&gt;However, what we observed is that if the device is already in an active BLE connection, calling &lt;code data-start="525" data-end="544"&gt;smp_bt_register()&lt;/code&gt; 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.&lt;/p&gt;
&lt;p data-start="714" data-end="959"&gt;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.&lt;/p&gt;
&lt;p data-start="966" data-end="1152"&gt;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.&lt;/p&gt;
&lt;p data-start="1159" data-end="1403"&gt;Could you please confirm if this understanding is correct, and whether the intended usage of &lt;code data-start="1252" data-end="1305"&gt;CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION&lt;/code&gt; is to enable/disable the SMP service between connections rather than during an active connection?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE DFU</title><link>https://devzone.nordicsemi.com/thread/557436?ContentTypeID=1</link><pubDate>Fri, 19 Dec 2025 14:07:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e76c2bcf-5fc1-425d-b6e0-8a9f1b99ad0a</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;However, I figured out it is possible.&lt;/p&gt;
&lt;p&gt;If you add this to your application&amp;#39;s prj.conf:&lt;/p&gt;
&lt;p&gt;&lt;span&gt;CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION=y&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Then you can easily enable and disable the smp_server (DFU service) using:&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;smp_bt_register()&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;smp_bt_unregister()&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Edvin&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE DFU</title><link>https://devzone.nordicsemi.com/thread/557410?ContentTypeID=1</link><pubDate>Fri, 19 Dec 2025 08:59:16 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b0cbd320-0af4-4b0e-a016-9587e35e88df</guid><dc:creator>nicky_liu</dc:creator><description>&lt;p data-start="964" data-end="998"&gt;Thank you for the clarification.&lt;/p&gt;
&lt;p data-start="1005" data-end="1189"&gt;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.&lt;/p&gt;
&lt;p data-start="1196" data-end="1335"&gt;The reason I want to restrict DFU to a specific operating mode is mainly related to&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;strong data-start="1280" data-end="1318"&gt;product behavior and user workflow&lt;/strong&gt;, not security.&lt;/p&gt;
&lt;p data-start="1342" data-end="1698"&gt;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.&lt;/p&gt;
&lt;p data-start="1705" data-end="1994"&gt;Therefore, we require DFU to be possible&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;strong data-start="1746" data-end="1815"&gt;only when the device is explicitly placed into a maintenance mode&lt;/strong&gt;, which is entered through a controlled command sequence or physical interaction. This maintenance mode is intended for service, manufacturing, or firmware update purposes only.&lt;/p&gt;
&lt;p data-start="2001" data-end="2261"&gt;In other words, DFU is intentionally treated as a&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;em data-start="2051" data-end="2074"&gt;maintenance operation&lt;/em&gt;, 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.&lt;/p&gt;
&lt;p data-start="2268" data-end="2419"&gt;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.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE DFU</title><link>https://devzone.nordicsemi.com/thread/557039?ContentTypeID=1</link><pubDate>Tue, 16 Dec 2025 07:19:30 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:fdc4bb51-4f2b-4be2-9dfc-77891679adba</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;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?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;What is it that concerns you that makes you want this specific operating mode?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>