NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

Hung Bui — Wed, 06 Jul 2022 09:11:52 GMT

Hi Andrea,

1. Yes the modification will enter in effect after the DFU update. However, if you decrease the number of pages , fds may run into a problem that it couldn't find the swap page. For increasing it might be OK. The best way of doing it when you change the configuration of fds is to reinitialize the pages as you did in the workaround.

2. The fds will use all pages to store the 3 files. It doesn't matter if you have 3 files or 1 file, or if you have 3 page or 10 pages. All the flash area will be utilized to store data. It can start first with one single page, but other pages will be used when you update the data a long the road.

The reason for that is to avoid flash wear out, all pages configured for fds will be used. Every time you update the file, a new record of the file will be stored in the blank area. And this process continues when you update your files. So after a while all pages will be used. When there isn't any blank area left, garbage collection will be executed and the previous records (marked as old) will be erased.

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

AndreaF33 — Tue, 05 Jul 2022 11:26:13 GMT

Hi Hung,

Thanks for the response.

Just a few follow-up questions, to check if I am understanding correctly:

Regarding the Data Section, the area dedicated to the fds pages. If I modify the size of the section and I upload the application with the updated boundaries by DFU, the modification will enter in effect after the update. Right?
So if I have 3 files of 40 bytes, how many pages will be used? 3? or just 120 bytes of 1 page?

For the moment we can live with losing data, as the records saved in the fds were getting corrupted so we implemented a restoring system.

Thanks again!

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

Hung Bui — Tue, 05 Jul 2022 11:13:49 GMT

Hi Andrea,

When you modify the size of data section (I assume you are talking about the number of page for fds) the configuration is hardcoded in the application image.

Have you managed to reproduce the issue with a not locked chip ? It's very useful to be able to read the flash pages that got the issue.

Regarding your workaround, as far as I can see it would most of the time help the device to overcome the issue. However there is a risk that the issue will happen again. If the odd of the issue is low enough I think it can be consider as a solution. But if it happens very often then your device will just keep losing data all the time.

Each file in the fds file system occupy only the flash page needed for it plus some header bytes. They are allocated in the 3 flash pages that you dedicated for fds. Every time you update a file, a new record of it is written to flash and the original record will be marked as garbage.

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

AndreaF33 — Tue, 05 Jul 2022 08:30:36 GMT

Hi Hung,

Thanks for the message.

I would follow up both targets: understanding why and a runtime workaround, if you don't mind.

Problem RC:

After a few hours of investigation we ended up having just two scenarios possible:

1st scenario: The device has very low current, but it's being supplied a little bit from another source, so a continuous reset scenario is indeed possible. Every time we boot we run a quick check to verify the integrity of our records, but I suspect we rarely end up deleting anything.

2nd scenario: The device is flashed with production flags which make debugging very difficult. By reflashing the image, we end up in such scenario. Could it be caused by the reflashing process?
When I modify the size of the data section in flash, such information is stored in the settings or in the application image?

Problem workaround:

We currently have an assert around the fds_init() call.
What I did, and the board was happy with it, was:

    if (fds_init() != NRF_SUCCESS)
    {
        for(int i = 0; i< FLASH_CONTENT_COUNT; i++)
        {
            //delete record if we find it
        }
        APP_ERROR_CHECK(fds_init());
    }

What do you think?

Bonus question: does each file reserve a full page or is managed dynamically by the SoftDevice and the fds?

Thanks and kind regards,
Andrea

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

Hung Bui — Mon, 04 Jul 2022 13:51:11 GMT

Hi Andrea,

We need to study why the fds throwing NO_SWAP or NO_PAGES.

In normal operation NO_SWAP should not happens. I don't think increase the number of pages would completely fix the problem.

NO_PAGES happens when the pages reserved for fds is corrupted or overwritten and the tags are missing on the pages.

To be able to detect what went wrong here we need to read the flash pages out (You can do a hex dump using nrfjprog --readcode)

I would suggest to step into the code and have a look at pages_init() to see what exactly happens when fds initialize.

Do you do any flash activity when booting ? I suspect that the battery on discharging can get to the point that it make the chip rebooting repeatedly for many times.

Could you please have a look at this case and check if it's the same issue that you are facing ? FDS - missing swap page

Of course if you are fine with reinitialize the fds and scrap the data then the solution can be just to erase the pages and call fds_init() again, but I think it's better to find the root cause.

RE: NO_PAGES error at fds pages_init() after boot: how to avoid it and how to recover from it?

AndreaF33 — Mon, 04 Jul 2022 09:27:29 GMT

PS: The fixes for the fds.c to protect from power failure, present in the SDKs 16 and higher, were applied.