<?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>Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/44853/background-dfu-update-problem-on-nrf52832</link><description>We are attempting to replicate the background DFU process presented in the example DFU over TFTP. Reference SDK that we are using is 15.2 
 What we do: 
 - We are trying to update only application code (no bootloader, no SD) - Our application retrieves</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 02 Apr 2019 12:17:27 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/44853/background-dfu-update-problem-on-nrf52832" /><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/179757?ContentTypeID=1</link><pubDate>Tue, 02 Apr 2019 12:17:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:77d52a0e-b7a1-405b-9191-e62f18a232f7</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;I just spoke with one of our developers, and he told me that they have had a few issues with the TFTP DFU in SDK15.2.0. He suggested that you tested with SDK15.3.0 instead. He told me that there were several bug fixes, so it would be easier to start with SDK15.3.0 rather than porting the TFTP part only to SDK15.3.0.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;BR,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/178193?ContentTypeID=1</link><pubDate>Mon, 25 Mar 2019 18:00:42 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a01f41d2-f206-4b58-874a-eb030b096d1a</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;Edvin, I actually managed to debug the bootloader right after reset.&lt;br /&gt;&lt;br /&gt;In brief:&lt;/p&gt;
&lt;p&gt;1) Right at bootloader start, the content of the bootloader settings page (0x7f000) looks OK to me:&lt;br /&gt;This is what I see&lt;br /&gt;&lt;br /&gt;crc = 333798234&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;settings_version = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;app_version = 2&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bootloader_version = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_layout = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_current = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_0&amp;nbsp;&amp;nbsp;&amp;nbsp; {...}&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_size = 85720&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_crc = 3998993418&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;bank_code = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_1&amp;nbsp; {...}&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_size = 85720&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_crc = 598733133&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;bank_code = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&lt;br /&gt;2) The page is unfortunately overwritten before being activated, because the function nrf_dfu_settings_init in nrf_bootloader_init detects that settings_forbidden_parts_equal_to_backup returns false.&lt;br /&gt;From what I can see this is comparing the first 32 bytes (offset by 4 bytes) of the bootloader_settings (0x7f000) page and the backup settings page (0x7e000), finding a difference (below what I have in the backup settings at 0x7e000)&lt;br /&gt;&lt;br /&gt;crc&amp;nbsp; =&amp;nbsp; 863167636&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;settings_version = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;app_version = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bootloader_version = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_layout = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_current = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_0&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; {...}&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_size = 85720&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_crc = 3998993418&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;bank_code = 1&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;bank_1&amp;nbsp;&amp;nbsp; &amp;nbsp;nrf_dfu_bank_t&amp;nbsp;&amp;nbsp; &amp;nbsp;{...}&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_size = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;image_crc = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;bank_code = 0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;br /&gt;&lt;br /&gt;which clearly differs from what at 0x7fff, causing the bootloader settings page to be overwritten, and the update ignored. A warning is thrown &amp;quot;Restoring settings from backup since the app has tampered with the off-limit parts of the settings page.&amp;quot;&lt;/p&gt;
&lt;p&gt;Why this happens, is still unclear to me.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/178185?ContentTypeID=1</link><pubDate>Mon, 25 Mar 2019 16:48:39 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4797e0ce-7f89-488c-91cf-e62f531bc4fc</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;Hello Edvin, we need to use the background bootloader as it seems is the only way to update the FW from application code. We are receiving the upgrade among other data from another microcontroller, and still performing some local operations with this data before starting the upgrade with the background bootloader. &lt;/p&gt;
&lt;p&gt;The background bootloader seems the only way to upgrade from application code to me.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/177526?ContentTypeID=1</link><pubDate>Thu, 21 Mar 2019 10:03:31 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e088a58b-da20-4556-b12f-d43f05826812</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Is there any reason why you are using the background bootloader? Have you tested the normal bootloader:&lt;/p&gt;
&lt;p&gt;&lt;a href="https://devzone.nordicsemi.com/blogs/1085/getting-started-with-nordics-secure-dfu-bootloader/"&gt;https://devzone.nordicsemi.com/blogs/1085/getting-started-with-nordics-secure-dfu-bootloader/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;It is easier to use, and a lot more tested. It uses the same bootloader as you refer to. Can you go through the guide, and see whether you get the same error?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Also, how do you generate your DFU image?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;BR,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/177494?ContentTypeID=1</link><pubDate>Thu, 21 Mar 2019 08:18:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7f4c4be9-e461-40f1-97e7-1b291a11a622</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;using the bootloader in components/libraries/bootloader/nrf_bootloader.c&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/177492?ContentTypeID=1</link><pubDate>Thu, 21 Mar 2019 08:15:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ab6370cf-4594-47c4-babf-a1a0ef5da029</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Are you using the bootloader from the IoT SDK, or the BLE bootloader?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/177435?ContentTypeID=1</link><pubDate>Wed, 20 Mar 2019 16:14:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:10fa474d-16b8-4810-85b8-76f4ae86aff6</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;Few further info out of debugging:&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;In fact, even commenting out the lines I provided above, although the DFU process completes with a DFU_STATE_COMPLETED, the bootloader does not actually install the update.&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;This is strange because:&lt;br /&gt;1) If we check the bootloader_settings information (at 0x7f000, reading the memory with the debugger (right after the DFU_STATE_COMPLETED and before the reset of the application to enter bootloader), the settings contain correctly an invalidated bank_0 code, and in bank_1 code a valid app code.&lt;br /&gt;2) At reset, this does not seem to be considered by the bootloader.&lt;/p&gt;
&lt;p&gt;For example, what we got right before reset:&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;Bank 0&lt;br /&gt;image_size&amp;nbsp;&amp;nbsp; &amp;nbsp;uint32_t&amp;nbsp;&amp;nbsp; &amp;nbsp;93144&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;br /&gt;bank_code&amp;nbsp;&amp;nbsp; &amp;nbsp;uint32_t&amp;nbsp;&amp;nbsp; &amp;nbsp;0&amp;nbsp;&amp;nbsp; &amp;nbsp;&lt;/p&gt;
&lt;p&gt;Bank 1&lt;br /&gt;image_size&amp;nbsp;&amp;nbsp; &amp;nbsp;uint32_t&amp;nbsp;&amp;nbsp; &amp;nbsp;93148 &amp;nbsp;&amp;nbsp; &lt;br /&gt;bank_code&amp;nbsp;&amp;nbsp; &amp;nbsp;uint32_t&amp;nbsp;&amp;nbsp;&amp;nbsp; 1 &amp;nbsp;&amp;nbsp; &lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;which looks fine for me, as indicates bank1 contains the new upgrade, however after reset, this is not installed, and actually in 0x7f000 we found only information on Bank0 (the original ones) and nothing in Bank1 info (all 0s)&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/177399?ContentTypeID=1</link><pubDate>Wed, 20 Mar 2019 14:59:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:dde25739-7eb0-4ca4-85ba-34feb216f66e</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Have you tried the non-background bootloader? Can you try it? Just to see whether you get the same issue there.&lt;/p&gt;
&lt;p&gt;Please follow this guide:&lt;/p&gt;
&lt;p&gt;&lt;a href="https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader"&gt;https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;To be honest, I am not sure how the background bootloader works. I haven&amp;#39;t tested it. But if you get a similar issue here, it would be easier to reproduce and pin point the issue.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;If the issue doesn&amp;#39;t happen on the &amp;quot;normal&amp;quot; bootloader. Can you give me some hints on what you have done, so that I can try to reproduce it?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;BR,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/176893?ContentTypeID=1</link><pubDate>Tue, 19 Mar 2019 08:50:18 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:39546bf8-3f19-49a9-8448-d1dfee5ebcec</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;NRF_DFU_SETTINGS_ALLOW_UPDATE_FROM_APP is set to true, therefore the first branch of settings_forbidden_parts_equal_to_backup is executed, leading to a call of settings_region_compare_to_backup() returning &lt;strong&gt;false&lt;/strong&gt;, called with the following values:&lt;br /&gt;start_offset = 4&lt;br /&gt;end_offset = 36&lt;br /&gt;p_compare_addr = 0x2000c5d8 pointing to s_dfu_settings&lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;1) No idea why this fails&lt;br /&gt;2) Yes we use public / private keyset&lt;br /&gt;3) Not sure I understand your question. &lt;br /&gt;To generate the DFU image we do in sequence only the following:&lt;br /&gt;- compile the application and generate an .hex&lt;br /&gt;- Run nrfutil pkg generate on the .hex to generate a .zip file, providing the privatekey file&lt;br /&gt;- Run trigger_creator.py on the .zip file and the config.json file&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/176672?ContentTypeID=1</link><pubDate>Mon, 18 Mar 2019 11:44:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:abc85dfd-ca00-4e00-a065-eff2109b523a</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Ok. Can you see what part of&amp;nbsp;settings_forbidden_parts_equal_to_backup that returns false? Look in nrf_dfu_settings.c from line 197. Try to debug through it to see why it fails.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Do you have any suspicion why this might fail? Are you using a public + private keyset? Are you trying to merge the BL settings page with your application before creating a DFU image with it?&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><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/176424?ContentTypeID=1</link><pubDate>Fri, 15 Mar 2019 13:31:37 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b4905ad8-6726-493d-9d53-716792a6d17f</guid><dc:creator>amaesa</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;&lt;br /&gt;I am referring to the NRF SDK 15.2 (nRF5_SDK_15.2.0_9412b96)&lt;/p&gt;
&lt;p&gt;NRF_DFU_SETTINGS_IN_APP is set to 1 in the sdk_config.h, the &amp;quot;offending&amp;quot; code should be in settings_forbidden_parts_equal_to_backup.&lt;/p&gt;
&lt;p&gt;Thank you for looking into this.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Background DFU update problem on NRF52832</title><link>https://devzone.nordicsemi.com/thread/176420?ContentTypeID=1</link><pubDate>Fri, 15 Mar 2019 13:25:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7293b148-a4d7-4a9e-8590-6a93c84eade9</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;You are talking about the &amp;quot;normal&amp;quot; SDK, right?&lt;/p&gt;
&lt;p&gt;So which one of these are triggering?&lt;/p&gt;
&lt;p&gt;Is NRF_DFU_SETTINGS_IN_APP true, or is settings_forbidden_parts_equal_to_backup(...) returning false (and hence !settings_forbidden... returns true) ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>