fds_init failure and recovery options

[Jordan Archer]

fds_init fails for several valid reasons, but my issue is how to recover.  This for me was triggered by a firmware upgrade overwriting the fds file area.  This can trigger fds_init to not find any valid or erased fds pages, or not finding an fds swap page.  

Since my devices were sealed, the solution was to code a direct to flash function that erased the fds pages, so the next fds_init would reinstall it's markers. 

And to answer the first question.  Yes, the bootloader should have protected the pages and failed the upgrade.  But I can see cases where the first call to fds_init is interrupted, which creates corrupted fds pages.

My requests are:

1. fds_stat works and return the same error that fds_init would.  

2. fds_stat also return the number of pages in the fds NVM range, that are marked as non-fds.  

3. A new function is added to do an fsck to recover a corrupted fds file system.  Or call it fds_recovery_erase.  This would do what I had to do manually, which is just erase all of the pages in the fds range.

[Kenneth]

I have added your input and suggestions to internal Jira for the SDK team to look at for future improvement of the FDS.

For now you would need to make your own implementation of "cleaning up" storage area reserved for FDS yes, e.g. something like:

#include "fds_internal_defs.h"
#include "fstorage_internal_defs.h"
#include "nrf_nvmc.h"
...
{
  uint32_t const *addr = FS_PAGE_END_ADDR;
  uint32_t pages = FDS_PHY_PAGES;
  uint32_t curr_addr = 0;
 
  sd_softdevice_disable();
 
  for (int i = 1; i < (pages + 1); i++)
  {
    curr_addr = (uint32_t)addr - (FS_PAGE_SIZE*i);
    nrf_nvmc_page_erase(curr_addr);
  }
}

[cbrown_cdi]

Hi Kenneth,

Can you provide an updated implementation of this for the current SDK? Looks like fstorage_internal_defs.h no longer exists.

Thanks!