Data saved in flash (FDS) that were previously retained are erased during DFU on some devices

[clockis]

Hi All,

In our product we have noticed that, on a few occasions, some important information that is saved using FDS (in a file with ID: 0x02) are being erased when an OTA update is performed. On most occasions these data are retained after an OTA update but on some occasions they are not retained. 

This has happened when updating with the same application versions on different occasions(seeing different results, in one occasion the data are preserved after the DFU in others they are not after the DFU) and the bootloader was never changed in years.

What could be causing this?

Thank you very much for your time. Any feedback is appreciated.

Best regards

[Hung Bui]

Hi Stavros, 

We would need to look into how you configured the bootloader to preserve data of the application when doing DFU (NRF_DFU_APP_DATA_AREA_SIZE). 

By default this space should match with the number of pages used by FDS/fstorage (include the gabage collection page) 

Please be note that even though the file ID is not change, the location of the file is not fixed to one single page. There is a chance that the issue happens when the file is located at the last page and it might be erased if the configuration for reserved page is not correct. 

[clockis]

Hi Hung,

Thank you very much for your immediate response.

We are currently using SDK 13.0.0.

I was unable to locate the NRF_DFU_APP_DATA_AREA_SIZE symbol in the bootloader or the application FW.

I have however looked into the issue you are describing as it was the first thing that came to mind, given that we are using the FDS.

I found the bootloader symbol shown below which other posts indicate as the parameter that affects which data are preserved after a DFU.

#define DFU_APP_DATA_RESERVED               CODE_PAGE_SIZE * 3

where,

#define CODE_PAGE_SIZE            (MBR_PAGE_SIZE_IN_WORDS * sizeof(uint32_t))

In the application FW:

#define FDS_VIRTUAL_PAGES 50 

and,

#define FDS_VIRTUAL_PAGE_SIZE 1024

Does this provide the information you requested?

Would this configuration between application FW and bootloader exhibit the behavior you mention in your previous response?

Thank you very much for your time and I look forward to hearing from you.

Best regards,

Stavros

[Hung Bui]

Hi Stavros, 

On older SDK NRF_DFU_APP_DATA_AREA_SIZE  was called DFU_APP_DATA_RESERVED.

So what I can see here is that the bootloader was configured to reserve only 3 pages for application data (fds). 

When in your application you configured 50 pages for fds. 

The way fds works is that the data can be stored in any of the 50 pages depends on the amount of records, and the number of updates. So in the case that the fds already use pages that's outside of the 3 pages reserved by the bootloader, there is a chance that the data be erased by the bootloader when it's receiving a new image. 

My suspicion for the reason why there weren't any issue for many years is that the fds hasn't touch the pages at the bottom of the 50 pages you reserved. But when it does and then a DFU update happens , some pages at the bottom of the 50 pages was erased to make space for the new image and hence the issue only appeared now. 

The solution for this is to either change the application to use only 3 pages (if you don't have that much of data) or to update the bootloader to reserver 50 pages. Note that doing that will cause less space for receiving the new image. You would need to do some calculation here. 

When you change the application fds setting to use less space, there is a chance that fds may crash due to new configuration, you may need to modify the fds/application code to handle that and reinitialize the flash area (delete all flash pages and lose data).

[clockis]

Hi Hung,

Excuse me for getting back to you with such a big delay but after deciding to apply the proposed fix by modifying the bootloader to reserve 50 pages (the application could not be changed to use only 3 pages as we need the 50 pages). This was indeed fixed using this method. The final solution was applied by performing an OTA update of the Application + Bootloader + SoftDevice so the issue is resolved for the product's new FW release.

However on some devices (not every device and not every time) after performing the DFU the application FW at startup tries to read important information (in a file with ID: 0x02) from the FDS but fails because the FDS handler is never called and the FDS appears to be always busy. This causes unexpected behavior and the device ultimately becomes unresponsive (and needs to be erased and flashed again which is not possible for devices that are already sent to clients).

The only modification in the bootloader was to increase the DFU_APP_DATA_RESERVED define to reserve all of the 50 pages of Flash(FDS) our application uses. 

When erasing the device and re-flashing the FW this behavior is not reproducible so it has not been possible for us to debug and probe this behavior further.

What could be the possible reason for this behavior?

[Hung Bui]

Hi Stavros, 

I think what need to be checked is that if you use exact 50 pages or it's 51 pages. There is one extra page for the swap page. 

Please try to match the address where it's reserved with the address returned from flash_end_addr() function in flash_bounds_set() in fds.c 

Other than that I couldn't think of any reason why fds didn't work as it should. If you can reproduce the issue you can try to read a hex dump after the board updated and compare with before it's updated to see if there is any corruption in the 50 reserved pages.