NRF_FSTORAGE fails to write/erase during update in Bootloader with two update options. BLE and GSM.

[Serg22]

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.

The problem occurs when DFU tries to erase and write old settings. However, when one type of update works, the other does not, also it looks like to be dependent on sdk_config.h settings, particularly:

Having choose FSTORAGE_NVMC to 1 and define BLE_STACK_SUPPORT_REQD updates successfully over BLE, but fails with GSM update.

// <i> NRF_FSTORAGE_SD uses the nrf_fstorage_sd backend implementation using the SoftDevice API. Use this if you have a SoftDevice present.
// <i> NRF_FSTORAGE_NVMC uses the nrf_fstorage_nvmc implementation. Use this setting if you don't use the SoftDevice.
// <1=> NRF_FSTORAGE_NVMC
// <2=> NRF_FSTORAGE_SD

#ifndef FDS_BACKEND
#define FDS_BACKEND 1
#endif

Changing FDS_BACKEND to 2 and removing BLE_STACK_SUPPORT_REQD, enables successful update over GSM, but BLE fails.

Failure pattern, when GSM fails

Failure pattern, when BLE fails

[Vidar Berg]

Hello,

The fault id from your DFU log corresponds to NRF_FAULT_ID_APP_MEMACC, and according to the "info" parameter, it's raised because of an access violation to the NVMC peripheral, which seems to  match the behavior you're experiencing.  But I'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?

[Serg22]

If I call nrf_dfu_settings_init() with sd_irq_initialized=true, an error occurs already during regular bootup(same for both FDS_BACKENDs). See screenshot.

[Vidar Berg]

Ok, sd_irq_initialized must be set to false if nrf_dfu_settings_init() 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.

[Serg22]

Ok, looks like Softdevice was not enabled in my custom implementation, that explains why NVMC backend worked. Now flash erase/write works.
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.
How can I track  nrf_dfu_flash results by polling or with some feedback? See picture.

[Vidar Berg]

You don'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)

[Serg22]

Ok, modified nrf_dfu_req_handler_init(), to initialize nrf_dfu_flash_init(), based on whether SD is enabled or not, and now it works. Thanks for support.

[Vidar Berg]

I'm glad to hear that. Thank you for the update.