<?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>Flash Read/Write fails after OTA DFU</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/53242/flash-read-write-fails-after-ota-dfu</link><description>Hello, We are using the NRF52840 and softdevice S140, PCA10056 on all examples. SDK version is 15.3. We see a problem following the secure OTA DFU protocol regarding acessing the flash. Follow the steps below to reproduce. 1. Flashed the nRF5_SDK_15.3</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 22 Oct 2019 13:57:11 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/53242/flash-read-write-fails-after-ota-dfu" /><item><title>RE: Flash Read/Write fails after OTA DFU</title><link>https://devzone.nordicsemi.com/thread/216200?ContentTypeID=1</link><pubDate>Tue, 22 Oct 2019 13:57:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3e38615b-4047-4d0f-9386-8e338f53e854</guid><dc:creator>A.P</dc:creator><description>&lt;p&gt;Hi Sigurd!&lt;br /&gt;&lt;br /&gt;Using nrfjprog -e did help with our problem, thanks for that.&lt;br /&gt;Am I understanding correctly when I say that whenever the bootloader size changes- for example when moving from &amp;#39;non secure DFU over USB&amp;nbsp; bootloader&amp;#39;, to &amp;#39;secure DFU OTA bootloader&amp;#39; or vice versa- I will need to erase the flash?&lt;br /&gt;&lt;br /&gt;Thanks&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Flash Read/Write fails after OTA DFU</title><link>https://devzone.nordicsemi.com/thread/215009?ContentTypeID=1</link><pubDate>Tue, 15 Oct 2019 09:25:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:07711418-a5c8-49df-8792-03213c879a4f</guid><dc:creator>Sigurd</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;You should compile the project with preprocessor symbol DEBUG defined, it should then print the error-code instead of &amp;quot;Fatal error&amp;quot;.&lt;/p&gt;
&lt;p&gt;Anyways, a&lt;span&gt;s part of fds_init() -&amp;gt; flash_subsystem_init(), in flash_bounds_set() we check to see if a bootloader_addr is written to flash or not. If bootloader_addr is not found, fds will use the last 3(FDS_VIRTUAL_PAGES) pages at the end of the flash for fds data. If it finds a valid bootloader_addr, it will place the fds data below the bootloader location. In SDK 15.3 the&amp;nbsp;bootloader_addr is stored in the MBR. It could be that&amp;nbsp;bootloader_addr is not found, but you still have the bootloader or bootloader settings page still present in flash, and the fds then fails to initialize.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Try to erase the flash completely, using nrfjprog -e , and then flash the&amp;nbsp;flash_fds example again.&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>