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.
