This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NO_SWAP returned from pages_init() causes fatal error

Hello, 

My device is failing to initialize because of an error with fds_init(). I am using SDK 14.2 with NRF52840.

It seems like the same problem as here, except no answer was ultimately provided. Basically, I have a device that returns FDS_PAGE_DATA for all pages inside pages_init(). This turns into NO_SWAP in fds_init(), which turns into NRF_STORAGE_FULL in pds_init(), and ultimately causes the initialization to fail. 

This problem is similar, but I am not trying to do DFU at the moment, so I don't think the solution is the same. I am afraid of erasing the data because I don't know if I need it. My understanding is that the FDS holds the application and its data... so if I erase it, won't I be erasing my application and render my device useless? Please correct me if I misunderstand. 

I have been solving the problem temporarily by incrementing FDS pages, but I cannot keep increasing the number of pages forever, and this problem only happens with a couple of my devices, the others are fine. Most devices are fine with just 3 pages. The broken one needs 6. 

1. How can I find out what is causing my data pages to fill up, and how can I prevent this? 

2. What is the limit on the number of virtual pages you can have, and what is the point of allocating a smaller number than the maximum possible number of pages? 

Thanks!

Parents
  • This issue caused a lot of pain for us using SDK 15.3, because our users devices would practically just become unusable as they would enter a crashloop on startup when the fds section is corrupt. I was finally able to implement a workaround:

    1. on startup, execute fds_init() and see if it returns FDS_ERR_NO_PAGES
    2. if it does, initialize a new fstorage instance (to calculate start/end addr, see fds.c -> flash_bounds_set())
    3. also register a new fstorage_evt_handler
    4. execute nrf_fstorage_erase to clear the entire FDS flash area that is utilized by the peer manager
    5. on successful NRF_FSTORAGE_EVT_ERASE_RESULT event, execute a reboot

    This successfully revived devices with this issue, from unusable state. This comes at the small cost of losing bonding keys and having to pair again.

Reply
  • This issue caused a lot of pain for us using SDK 15.3, because our users devices would practically just become unusable as they would enter a crashloop on startup when the fds section is corrupt. I was finally able to implement a workaround:

    1. on startup, execute fds_init() and see if it returns FDS_ERR_NO_PAGES
    2. if it does, initialize a new fstorage instance (to calculate start/end addr, see fds.c -> flash_bounds_set())
    3. also register a new fstorage_evt_handler
    4. execute nrf_fstorage_erase to clear the entire FDS flash area that is utilized by the peer manager
    5. on successful NRF_FSTORAGE_EVT_ERASE_RESULT event, execute a reboot

    This successfully revived devices with this issue, from unusable state. This comes at the small cost of losing bonding keys and having to pair again.

Children
No Data
Related