FDS_ERR_NO_PAGES error. DFU issue?

I have gotten the FDS_ERR_NO_PAGES issue multiple times now. In our last pre-production run, it randomly happened to a few units (4 out of 60). For 3 of the units, the error resolved itself after a few reboots but with time it happened more and more often and after a while all the time. The last unit got the error after a DFU (application). Since this happened to the 4 most used units I thought that a part of the flash memory could be exhausted. After changing the firmware to be more flash-conservative I got the units working by changing FDS_VIRTUAL_PAGES (application) and DFU_APP_DATA_RESERVED (bootloader). But not after the first update, it took more like 20 updates until it worked for each unit. After that, they have worked.

Now we are using the same hardware to develop a similar product. The new firmware is based on ble_app_ancs_c and while debugging it works flawlessly but when I try to run in on an actual unit by updating it through DFU I get the FDS_ERR_NO_PAGES error. I tried deleting the first application_data pages if the error occurs and how it works but they are deleted on every reboot.

    if (ret != NRF_SUCCESS)
    { 
        if(ret == FDS_ERR_NO_PAGES){
            for(uint8_t rc = 0; rc < 3; rc++)
            {
                while(sd_flash_page_erase(118 + rc) != NRF_SUCCESS);
            }
        }
        NRF_LOG_ERROR("Could not initialize flash storage. fds_init() returned 0x%x.", ret);
        return NRF_ERROR_STORAGE_FULL;
    }

What is happening and what am I doing wrong?
Could the application_data area be corrupted? How do I clear it? Deleting the pages does not seem to work.
Could the flash memory be exhausted? It should be good for 10k deletes?

Info
Pre-production
SDK 15.0.0
Softdevice 6.0.0
Bootloader secure_bootloader_ble_s132_pca10040
New version
SDK 17.1.0
Softdevice 7.2.0
Bootloader secure_bootloader_ble_s132_pca10040
FDS_VIRTUAL_PAGES 10
FDS_VIRTUAL_PAGE_SIZE 1024
NRF_DFU_APP_DATA_AREA_SIZE 40960

Steps I took for updating:

  1. Device was running pre-production fw and bootloader.
  2. Built a new bootloader: nrfutil pkg generate --hw-version 52 --bootloader secure_bootloader_ble_s132_pca10040.hex --bootloader-version 3 --sd-req 0xA8 --sd-id 0x0101 --softdevice s132_nrf52_7.2.0_softdevice.hex --key-file xtactor_fw_private.key ancs_update_bootloader.zip
  3. Updated the bootloader with DFU.
  4. Built a new firmware: nrfutil pkg generate --hw-version 52 --application-version 200 --application ../pca10040/s132/ses/Output/Release/Exe/ble_app_ancs_c_pca10040_s132.hex --sd-req 0x0101 --key-file xtactor_fw_2_private.pem xtactorfw_2_v200.zip
  5. Updated the fw with DFU.

Again am I doing something wrong?

  • Hi, 

    In order for data to be kept through DFU, you need to configure DFU_APP_DATA_RESERVED in nrf_dfu_types.h. See the Preserving application data section of the DFU bootloader documentation for details.

    Also, see this post

    Regards,
    Amanda

  • Hi, 

    NRF_DFU_APP_DATA_AREA_SIZE is the new DFU_APP_DATA_RESERVED, I think?

    from nrf_dfu_types.h in SDK 17.1.0:

    #define DFU_APP_DATA_RESERVED      NRF_DFU_APP_DATA_AREA_SIZE // For backward compatibility with 15.0.0.

    And that is set to 40960 (FDS_VIRTUAL_PAGES * FDS_VIRTUAL_PAGE_SIZE * 4). But at this point the data is secondary, mainly I want to help with finding why I get the error and how to prevent it. In the new version I do not even use FDS my self it is peer_manager_init(); that is crashing.

  • Hi, 

    Yes, it is DFU_APP_DATA_RESERVED in SDK15.0; NRF_DFU_APP_DATA_AREA_SIZE in SDK17.1.0.

    The error message FDS_ERR_NO_PAGES is from FDS which is used by Peer Manager. See Architecture. This is probably because the FDS pages have been corrupted. As this happens after a DFU operation I suspect this is because the flash area was written to during the DFU update. This can happen if the FDS pages are not properly reserved in the bootloader (i.e. the bootloader does not know it cannot use them for temporary storage).

    Please keep in mind that number of FDS_VIRTUAL_PAGES (in your application) reserved for FDS storage match with NRF_DFU_APP_DATA_AREA_SIZE (DFU_APP_DATA_RESERVED in SDK15.0.0) inside the bootloader. By default, they are 3 pages. (12kB).  

    -Amanda

  • Please keep in mind that number of FDS_VIRTUAL_PAGES (in your application) reserved for FDS storage match with NRF_DFU_APP_DATA_AREA_SIZE (DFU_APP_DATA_RESERVED in SDK15.0.0) inside the bootloader. By default, they are 3 pages. (12kB).  

    I understand that but it is matching, right? Because FDS_VIRTUAL_PAGES * FDS_VIRTUAL_PAGE_SIZE * 4 = NRF_DFU_APP_DATA_AREA_SIZE. 10 * 1024 * 4 = 40960.

    As this happens after a DFU operation I suspect this is because the flash area was written to during the DFU update.

    Sure, the FDS_ERR_NO_PAGES happens if the application_data area is full or corrupted. Corrupted in this means that is can not find the "magic word 0xDEADC0DE followed by either 0xF11E01FF for swap page or 0xF11E01FE for data page." as stated here. But on the assembled units I can not plug in a debugger to "erase all". How can I clear the corrupted pages? Can I erase them with sd_flash_page_erase()? Which pages should I clear in that case? The bootloader starts at FLASH_START=0x78000 and application_data is below that so if I have 10 virtual pages that means that application_data starts at 0x68000? Can I just clear page 104 - 119?

  • The bootloader starts at FLASH_START=0x78000 and application_data is below that so if I have 10 virtual pages that means that application_data starts at 0x68000? Can I just clear page 104 - 119?

    Bad math I mean 0x6E000 - 0x77000. Page: 110 - 119.

Related