<?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>NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/67468/nrf_fstorage-fails-to-write-erase-during-update-in-bootloader-with-two-update-options-ble-and-gsm</link><description>SDK 15.3 
 SD S340 
 Bootloader implemented to update over GSM and BLE. BLE update code is taken from example secure_bootloader_dfu*. GSM update code is custom made. SDK is modified to choose which method to use by writing magic numbers to GPREGRET register</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 23 Oct 2020 15:27:53 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/67468/nrf_fstorage-fails-to-write-erase-during-update-in-bootloader-with-two-update-options-ble-and-gsm" /><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276690?ContentTypeID=1</link><pubDate>Fri, 23 Oct 2020 15:27:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:12d29aca-05c5-4110-80e5-821e41493ca6</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;I&amp;#39;m glad to hear that. Thank you for the update.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276681?ContentTypeID=1</link><pubDate>Fri, 23 Oct 2020 14:46:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:92b70ca3-4661-42f7-9e80-8f0f3274fc39</guid><dc:creator>Serg22</dc:creator><description>&lt;p&gt;Ok, modified&amp;nbsp;nrf_dfu_req_handler_init(), to initialize&amp;nbsp;nrf_dfu_flash_init(), based on whether SD is enabled or not, and now it works. Thanks for support.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276649?ContentTypeID=1</link><pubDate>Fri, 23 Oct 2020 13:38:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5a8738d8-1525-4c10-b78c-2afd815420fc</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;You don&amp;#39;t have to enable the Softdevice, but you do need to make sure you are using the correct fstorage backend at all times. So, you should use the SD backend during BLE DFU and the nvmc backend for everything else (i.e. during GSM DFU and image activation)&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276468?ContentTypeID=1</link><pubDate>Thu, 22 Oct 2020 14:05:16 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:96846324-c26d-488b-8750-c31b583b0fd5</guid><dc:creator>Serg22</dc:creator><description>&lt;p&gt;Ok, looks like Softdevice was not enabled in my custom implementation, that explains why NVMC backend worked. Now flash erase/write works. &lt;br /&gt;But the custom update implementation that used NVMC before seems to be blocking, and now when flash operations go through SD it seems to be asynchronous, and my bootloader goes to inactivity, because it does not get an event.&lt;br /&gt;How can I track&amp;nbsp;&amp;nbsp;nrf_dfu_flash results by polling or with some feedback? See picture.&lt;br /&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/communityserver-discussions-components-files/4/pastedimage1603375474762v1.png" alt=" " /&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276400?ContentTypeID=1</link><pubDate>Thu, 22 Oct 2020 10:04:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8ed497d0-1ed3-493a-934a-bce1863e24de</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Ok, &lt;span&gt;sd_irq_initialized must be set to false if &lt;/span&gt;&lt;span&gt;nrf_dfu_settings_init&lt;/span&gt;() is called before the Softdevice has been invoked through the BLE transport initialization. Anyway, I think the problem has to be that the bootloader is selecting the NVMC backend when the Softdevice is enabled.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276224?ContentTypeID=1</link><pubDate>Wed, 21 Oct 2020 13:30:34 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:bcea6dd0-c5eb-45f3-be0a-1c0bd14dc468</guid><dc:creator>Serg22</dc:creator><description>&lt;p&gt;If I&amp;nbsp;&lt;span&gt;call nrf_dfu_settings_init() with sd_irq_initialized=true, a&lt;/span&gt;n error occurs already during regular bootup(same for both FDS_BACKENDs). See screenshot.&lt;br /&gt;&lt;img src="https://devzone.nordicsemi.com/resized-image/__size/320x240/__key/communityserver-discussions-components-files/4/pastedimage1603286889908v1.png" alt=" " /&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.</title><link>https://devzone.nordicsemi.com/thread/276180?ContentTypeID=1</link><pubDate>Wed, 21 Oct 2020 12:19:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:99287b7c-203e-4da6-b904-81aabc50a6a2</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;The fault id from your DFU log corresponds to &lt;span&gt;&lt;span&gt;&lt;a title="NRF_FAULT_ID_APP_MEMACC" href="https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v6.1.1/group___n_r_f___f_a_u_l_t___i_d_s.html?cp=4_7_4_3_2_8_0_2_0#ga234338bb9d7e0f116a6e7112819cce6d"&gt;NRF_FAULT_ID_APP_MEMACC, &lt;/a&gt;&lt;/span&gt;&lt;/span&gt;&lt;span&gt;&lt;span&gt;and according to the &amp;quot;info&amp;quot; parameter, it&amp;#39;s raised because of an access violation to the NVMC peripheral, which seems to&amp;nbsp; match the behavior you&amp;#39;re experiencing.&amp;nbsp; But I&amp;#39;m not sure why the wrong fstorage backend gets selected. Does it work if you call nrf_dfu_settings_init() with sd_irq_initialized=true?&lt;/span&gt;&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>