<?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>Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/32788/dual-bank-dfu-crc-computation-failed-after-copy-to-bank-0</link><description>I&amp;#39;m building a custom system based on the NRF52832 and S132 SoftDevice with SDK 14.2.0. 
 Our secure bootloader (bonded) is based on examples/dfu/bootloader_secure_dfu. It&amp;#39;s button handling is removed (no buttons) and more debug is added. 
 During a DFU</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 04 May 2021 11:54:48 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/32788/dual-bank-dfu-crc-computation-failed-after-copy-to-bank-0" /><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/308158?ContentTypeID=1</link><pubDate>Tue, 04 May 2021 11:54:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:70e5f4b6-40fb-49d1-b442-45991823e7c7</guid><dc:creator>tyana</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;have you found a solution to this problem in the end?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/128120?ContentTypeID=1</link><pubDate>Thu, 12 Apr 2018 16:14:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f522ff02-33e2-4e94-baab-9a1708ad49b7</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;It is hard to change bootloader size during DFU, mainly because the bootloader start address is written to a UICR register. Also because bank size and location calculations (for where to download and move firmware images to and from) depend on where the bootloader begins, so that extra care must be taken if changing bootloader size during DFU. &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;While possible&lt;/a&gt;, it does require a lot of effort.&lt;/p&gt;
&lt;p&gt;It is much easier to stick to the same bootloader size. That size may be larger than the one we provide with the SDK, as long as you set the project settings flash start and flash size values correctly. In addition, the BOOTLOADER_START_ADDR define should also get this value, and it should be written to UICR. This should happen automatically for the various toolchains, as the value is fetched from the project settings for flash, but double checking never hurts.&lt;/p&gt;
&lt;p&gt;I suspect that you get two separate errors. One when adding debug (related to changed bootloader size), and one when not adding debug (hard to tell what happens there). I found your private thread and will look into the files that you provided there.&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><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/127885?ContentTypeID=1</link><pubDate>Wed, 11 Apr 2018 16:31:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:34ad07df-8c79-4204-9f72-70260ed446a4</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;Is it possible the CRC calculation while receiving the DFU data and the one after the copy from bank1 to bank0 is using different sizes? It&amp;#39;s difficult to trace with bootloader_settings. Could the 2nd CRC be using a value it got from the DFU init packet?&lt;/p&gt;
&lt;p&gt;I believe this is generated by nrfutil, but perhaps there is something wrong there.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/127743?ContentTypeID=1</link><pubDate>Wed, 11 Apr 2018 07:49:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1cc8a7d9-51da-479a-a973-0115e68cef03</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;I just reduced our bootloader size to 24k using the value from the secure_dfu_ble_gcc_nrf52.ld&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;In fact, our ld is exactly the same.&lt;/p&gt;
&lt;p&gt;Now that debugging is disabled it&amp;#39;s difficult to know for sure but it reboots in DFU mode, so I&amp;#39;ll assume the CRC check failed again.&lt;/p&gt;
&lt;p&gt;I will try with my J-Link plus in monitor mode later, but have not gotten that to work yet, hence the need for print debugging.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/127732?ContentTypeID=1</link><pubDate>Wed, 11 Apr 2018 07:09:17 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b5304f3f-cb27-4a3e-9346-2a6a7c31b279</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;I indeed had to increase the bootloader size. I included NRF_LOG_BACKEND_RTT and a bit more debugging. The dfu_request_handling() is copied directly from the 14.2.0&amp;nbsp;&lt;span&gt;examples/dfu/dfu_req_handling with some debugging and a change of hardware version.&lt;br /&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Could you explain why changing the bootloader location and size can cause the CRC issue I&amp;#39;m seeing?&lt;br /&gt;I&amp;#39;ve found this ancient document explaining relocating the bootloader:&lt;br /&gt;&lt;a href="https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_memory_relocating.html"&gt;https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_memory_relocating.html&lt;br /&gt;I&lt;/a&gt;s any of this info still valid? Is relocating bootloader&amp;nbsp;still possible with non-modified libraries?&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/126909?ContentTypeID=1</link><pubDate>Wed, 04 Apr 2018 16:09:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7d4332cf-dbe3-4c39-8bec-27ffc5a17440</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I am sorry for the delay. We have been out-of-office due to Easter holidays.&lt;/p&gt;
&lt;p&gt;Note that you may experience some trouble if you increase the size of the bootloader itself past the flash page boundary, so check that you have not done so.&lt;/p&gt;
&lt;p&gt;The crc field of the nrf_dfu_settings_t structure is the crc of the rest of that structure itself. The crc of the bank image is in the nrf_dfu_bank_t structures, e.g. bank_0.image_crc and bank_1.image_crc.&lt;/p&gt;
&lt;p&gt;In nrf_dfu_app_continue(), after copying the application is done, the crc of the copied data is checked and then written to bank_0.image_crc. That way, when the data has been copied over (from bank 1 to bank 0) the crc should be the correct one.&lt;/p&gt;
&lt;p&gt;Perhaps you can do a diff between the original bootloader from the SDK and your version, to see if anything stands out?&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><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/126386?ContentTypeID=1</link><pubDate>Thu, 29 Mar 2018 09:17:03 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:47e76961-312c-46fa-9d56-243f2aa1c431</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;When flashing the application with a JLink I&amp;#39;m generating the bootloader settings with CRC = 0 and flashing it along with my application. The --debug-mode bootloader&amp;nbsp;boots this as expected.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/126385?ContentTypeID=1</link><pubDate>Thu, 29 Mar 2018 09:15:02 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:30e18da4-4ee9-452a-ac45-645bcd14ad2c</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;I was mistaken about the device being bricked.&amp;nbsp;I was under the assumption the peer data would be removed if this error happened. Since it&amp;#39;s still there the bootloader will indeed go into DFU&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/126384?ContentTypeID=1</link><pubDate>Thu, 29 Mar 2018 09:13:38 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:89d2d493-7034-48ce-9812-7bb2a65d8bc0</guid><dc:creator>Bart Cerneels</dc:creator><description>&lt;p&gt;I&amp;#39;ve shared those files in a private thread.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual Bank DFU CRC computation failed *after* copy to bank 0</title><link>https://devzone.nordicsemi.com/thread/126157?ContentTypeID=1</link><pubDate>Tue, 27 Mar 2018 16:56:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f487a81a-24c9-47eb-9f31-239fc64a0553</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I do not quite understand what you are seeing here. The bootloader either&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;reads in the bootloader settings page that there is an applicaiton, reads the alleged application from flash and calculates the CRC, and if it matches the application CRC stored in the bootloader settings file it starts the application&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;or, if the above fails,&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;enters DFU mode.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;If you can not get the device into bootloader mode again then that suggests that you have actually jumped to the application, but that the application fails. Have you tested the application by programming it directly with a programmer? In order to test it together with the bootloader you must also &lt;a href="http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.tools%2Fdita%2Ftools%2Fnrfutil%2Fnrfutil_settings_generate_display.html"&gt;generate the bootloader settings file&lt;/a&gt; using nrfutil. Then you should also be able to run a debug session for the application.&lt;/p&gt;
&lt;p&gt;I see from the make target that you use --debug-mode and that there is no application version (only application version string). Are you using the debug version of the bootloader?&lt;/p&gt;
&lt;p&gt;I would like to get the bootloader hex file and the DFU zip file in order to reproduce, or flash dumps from before and after the upgrade (&amp;quot;nrfutil --readcode filename.hex&amp;quot; for dumping the nRF flash contents to a hex file.) If you do not want to share that here on the open forum then we can make the thread private first or you can create a private ticket and refer to this thread.&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>