NRF_ERROR_STORAGE_FULL after an OTA DFU

[Vankata]

Hi

I am writing the firmware of a wearable device, based on nRF52832, which must support OTA DFU. I am using the peer_manager to manage paring and bonding, and the FDS library to access a relatively large amount of the free program flash (~120KB) as a non-volatile user storage space. Four parts – Bootloader, SoftDevice, Application, and the Settings table for the Booloader are merged into a single, combined HEX file for programing the device. During the development, I am testing on a nRF52DK Development Kit.

I see that the pm_manager uses the FDS and at least two pages are needed by the system. Also, having in mind the needed user flash data space I have specified FDS_VIRTUAL_PAGES to be equal to 33.

When the nRF52832 chip is programmed either from the IDE or by just drag-and-dropping the .HEX file to the virtual storage device of the nRF52DK board, the firmware runs fine. If I initiate OTA DFU and I reprogram the device with the same App-part of the firmware, the pm_init() in the initialisation phase returns an error – NRF_ERROR_STORAGE_FULL and the device restarts due to the subsequent APP_ERROR_CHECK line in the code.

I am aware of this post https://devzone.nordicsemi.com/f/nordic-q-a/61409/nrf_error_storage_full-after-dfu-update but it does not help me. In my case NRF_DFU_APP_DATA_AREA_SIZE is set to 12288, which should be sufficient for the FDS module to get initialised, shouldn't it? Erasing the flash pages, allocated to FDS followed by a NVIC_SystemReset() would be an option, but how can this be performed if the FDS is not initialised? 

Am I missing something? Why is that error generated? How can I get over this issue?

Regards,

Vankata

[Vankata]

Hi Torbjørn,

Thank you for the advice! Unfortunately, after I changed that value to 135168 bytes (1024*4*33), the nRFConnect reported "Error 4: Insufficient resources", which also sounds logical. I tried to protect 20480 bytes (5 pages), which should be more than enough but I get again the NRF_ERROR_STORAGE_FULL with consecutive device restarts. I guess the swap page is not at the end of the free memory and therefore it cannot be guaranteed that it will stay protected during the OTA DFU (unless I protect all 33 pages, but then the problem is different).

Is there a way the app to erase the free flash after the upgrade, obviously without using the FDS module, as it cannot be initialized? This could be an option in our case but is it possible?

Best regards,

Vankata

[ovrebekk]

Hi Vankata

Can you confirm which SoftDevice type and version you are using, and how much flash the application requires?

Best regards
Torbjørn

[Vankata]

Hi Torbjørn,

SoftDevice is S132 from SDK 17.0.2, it occupies about 150KB. The compiled app is about 115KB, which is less that the additional flash we allocate - 33 pages, i.e. 132KB. We use 30 pages of those 33 as user NVM.

We would like to implement dual bank OTA DFU. Since we always initialise the NVM after reprogramming, we thought that its space can be considered as free and can be used by the OTA DFU. The new question is: is that possible in our case, and if yes - how? 

Regards,

Vankata

[ovrebekk]

Hi Vankata

In that case you are over the limit when it comes to doing dual bank update, since the size of the SoftDevice + app data + bootloader + application * 2 is more than 512kB. 

The bootloader architecture assumes that the app data needs to be retained after you have done an update, and won't allow you to overwrite this region. 

Is there any particular reason why you can't use single bank update?

The only practical difference is that in case of a interruption during the DFU procedure you will need to retry until it succeeds, since you don't have the option of falling back to the previous image. 

Best regards
Torbjørn

[Vankata]

Hi Torbjørn,

Thank you for clarifying that! 

In our device, to save battery life, we can afford only one attempt for an OTA DFU. If the upgrade fails for some reason, instead of trying again, we would like to have the option to continue with the old app version. Obviously, we need to reconsider our approach.

Regards,

Vankata

[ovrebekk]

Hi Vankata

Normally the chance of having a failure during a DFU update is extremely rare, and should only happen in rare cases where people remove power during the update, or if you are trying to do an update when the battery is almost empty. 

So while it is important to have some backup plan in case this happens, you also have to take into consideration how often you expect to do DFU updates, and how likely it is to have a failure in this case. 

Best regards
Torbjørn