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

[AndreaF33]

Hi there,

Thanks in advance for your time and attention.

We started to see some cases where our devices boots and gets a NO_PAGES error after having been turned off(or at very low power) for a while. The scenario is a battery discharge.

I was wondering if you had any countermeasure the device could take at runtime to recover from it.

Moreover, if you have any insight in how it could happen that would be much appreciated. 

Some months ago we enlarged the flash size of the fds, from 3 to 4 pages to allow for more space(we were getting NO_SWAP errors).
We have:

PeerManager enabled, which takes 1 page from the data section I believe.
3 files, in which there are a few records.

Device: NRF52832
SDK: 15.3.0
Softdevice: S140

Kind regards,
Andrea

[AndreaF33]

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

[Hung Bui]

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. 

[AndreaF33]

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

[Hung Bui]

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. 

[AndreaF33]

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!