FDS init with 2 pages labeled as swap

[Anthony Ambuehl]

I have an found a problem where I find FDS has 2 pages labeled as swap, which results in loss of one of the data pages.

my configuration is 2 data pages and 1 swap page.  at start up, the pages show 1 data page and 2 swap pages.

after init the swap is not completed and only 1 data page is found.  the second entry in m_pages has an p_addr of 0

I presume this occurred when a reset interrupted a page swap.  

Is there any existing fix for this condition?

I'm using SDK 15.0.0 however I have backported/pactched FDS with fixes from 15.3.0

[Edvin]

Hello,

I have not seen this happen before. Do you have a reliable way to replicate this? Are you sure that both pages are defined as swap page, and that you don't have one corrupted page, one swap page and one data page?

Can you send a flash dump of your device? You can use "nrfjprog --readcode my_flash_dump.hex" to generate the flash dump.

As mentioned, I have not seen any issues with 2x swap pages before, but there are some bugfixes that were applied to SDK16.0.0 or SDK17.0.0 (I don't remember which one, but you can check the release notes. I would suggest to port to that version if you have FDS issues. There are very few (if any) API changes between the later SDKs.

BR,

Edvin

[Anthony Ambuehl]

Hello Edvin,   

I stepped through the pages_init function and verified the page_type had 2 pages with FDS_PAGE_SWAP and only 1 page with FDS_PAGE_DATA.  After this occurred only 1 entry in m_pages was initialized.

Unfortunately after getting this far in the debug, I erased the device since I was trying to complete a feature before the end of the day.  I realize now saving off the complete flash would have been a really good idea.   I'll look at backporting the changes to FDS from SDK17, which will be a low risk versus completely upgrading the sdk for our production devices.

a*

[Edvin]

I see.

I think it is a good idea to backport the FDS, as it contains some bug fixes. 

Another thing that is worth mentioning is that you should only call fds_gc() in cases where you receive events indicating that the FDS is full. Don't do so by default on startup of the application. We see a lot of customers doing this, as they think it is a good idea.

The reason this is a bad idea is that if this is a battery powered device, you may experience a lot of resets when the battery is running out, causing many (!) fds_gc() to be called, and many aborted during power cuts. This behavior will provoke any potential bugs in the FDS regarding fds_gc(). 

So please don't call fds_gc() in the startup of your application. Only if the FDS is in fact full.

Best regards,

Edvin