<?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>DFU upgrade to Secure</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/80422/dfu-upgrade-to-secure</link><description>If I were to make have my devices in the field (micro-ecc, buttonless, no bonds, no Secure Communication), can I easily and safely upgrade fielded units to micro-ecc, buttonless, BONDS, and SECURE COMM ? If not, what else needs to be changed to do so</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 08 Oct 2021 12:18:41 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/80422/dfu-upgrade-to-secure" /><item><title>RE: DFU upgrade to Secure</title><link>https://devzone.nordicsemi.com/thread/333259?ContentTypeID=1</link><pubDate>Fri, 08 Oct 2021 12:18:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ab42220d-e651-4b46-aade-206bc5b6bbba</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;It depends a bit on what versions of DFU bootloader you have already. If it is the legacy DFU bootloader, then upgrading to the new Secure DFU bootloader is impossible for nRF51, and a bit tricky (with a short critical section where a reset may brick the device) for the nRF52. For details, see &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/18199/dfu---updating-from-legacy-sdk-v11-0-0-bootloader-to-secure-sdk-v12-x-0-bootloader"&gt;DFU - Updating from Legacy(SDK v11.0.0) Bootloader to Secure(SDK v12.x.0) Bootloader&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Once you are past the Legacy vs Secure DFU Bootloader hurdle, upgrading to a new Secure DFU Bootloader is straight-forward as long as the size of the bootloader does not change (in terms of the number of flash pages it uses.)&lt;/p&gt;
&lt;p&gt;The DFU Controller app will, as you write, use the BLE address + 1 for locating the device, in the case of no bonding. In the bonding case, the device address is the same (for reusing the same bonding info), and the device should have the Service Changed Characteristic. If it has not, then porting over to requiring bonding might be a bit more troublesome, as you would then have to change over to a new BLE address for both app and bootloader. This should all be solvable for the nRF52840, though, it&amp;#39;s just that there might be a few devils in the details depending on what you are going from and to.&lt;/p&gt;
&lt;p&gt;Putting on the proper appearance characteristic (same as the device when not in bootloader mode) could add some value to the end customer, yes. At least it could give a more seamless experience. However I am not sure how noticeable it will be to the end customer. If the DFU upgrade is done through an app that can do upgrades for several different types of products, then using the appearance as one of the elements for differentiating between different devices sounds like a very good idea, yes. On the other hand, at the time of connecting to the device in DFU mode, the DFU Controller should already know what device (and type of device) it has connected to, and thus should be able to provide the proper user experience without having to rely on the appearance.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>