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,

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

[Vankata]

Thanks Torbjørn,

This is my understanding, as well.

Your phrase "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" fully answers my question.

Best regards,

Vankata

[ovrebekk]

Hi Vankata

Sounds good. Then I will consider the case resolved, unless you have any more questions?

Best regards
Torbjørn

[Vankata]

Yes, we can consider the case resolved. Thanks!