FDS_ERR_NO_PAGES problem

[alireza sadeghpour]

Hi,

i have PCA10059 dongle board. when i want run my program on it, fds_init return FDS_ERR_NO_PAGES. and also in nrf connect i can see range of different application parts as below:

MBR -> 0x0, 0x1000

Soft Device -> 0x1000, 0x26000

Application -> 0x26000,  0x7611c

Bootloader -> 0xE0000, 0xFE000

and also my FDS setting is as below:

#ifndef FDS_VIRTUAL_PAGES
#define FDS_VIRTUAL_PAGES 3
#endif

#ifndef FDS_VIRTUAL_PAGE_SIZE
#define FDS_VIRTUAL_PAGE_SIZE 1024
#endif

so i think that have enough flash for 3 page. and also i ran below code when FDS_ERR_NO_PAGES  error returned.

rc = fds_init();
    #ifdef BOARD_PCA10059
    //if we did not find any free page, we will reset some pages
    if(rc == FDS_ERR_NO_PAGES)
    {
            bsp_board_led_on(3);
            for(rc = 0; rc< 100;rc++)
            {
                    while(sd_flash_page_erase(119 + rc) != NRF_SUCCESS);
            }
            bsp_board_led_off(3);
            while(1);
    }
    #endif
    APP_ERROR_CHECK(rc);

in above code i try to remove some flash pages when problem occur but even with above code FDS_ERR_NO_PAGES problem did not solved and in the next reset i again receive FDS_ERR_NO_PAGES error.

there is any way to solve problem?

[tesc]

Hi,

If the bootloader is at 0xE0000, three FDS pages of size 1024 (1024 words, which is 4096 bytes, or 0x1000 bytes in hexadecimal) would start at 0xDD000, 0xDE000 and 0xDF000.

Your code erasing flash pages erases the flash pages starting at 0x77000 to starting at 0xDA000.

What why you need to erase, are the flash pages used by FDS. In this case that should be pages 221, 222 and 223.

The reason you need to erase them, is that FDS needs those pages not to be used in order to initialize properly. If the pages contain erroneous data, FDS may either not use the page at all (FDS assumes the page contains other data that it should not tamper with) or the page header looks correct to FDS and FDS tries to parse the page (but the contents are corrupt.)

While the Dongle has some use cases also for development work, it is not a full development platform and so debugging and figuring out what is going on might be a bit difficult at times. In general I would recommend to either develop on a DK, or to connect to the Dongle from a J-Link debugger (such as the one onboard the DK, either through use of a Tag Connect cable, soldering, or otherwise.)

Regards,
Terje

[alireza sadeghpour]

Thanks for your response. i have some questions:

Q1: While FDS see pages at  0xDD000, 0xDE000 and 0xDF000 are corrupted, why it did not use other pages that i erased?

Q2: How FDS find that bootloader start at 0xE0000? there is any configuration in app (i use IAR compiler), or there is any detail stored in chip(like MBR) that indicate bootloader start point?

Thanks

[tesc]

Hi,

When there is a bootloader on the device, the BOOTLOADER_START_ADDR is put in a UICR register which is reserved for Nordic Semiconductor software (It is the UICR.NRFFW[0] register, to be exact.) See also the Memory layout section of the DFU bootloader library documentation on Infocenter. This marks where the bootloader starts, and then the space for FDS pages is put directly below that.

FDS will not touch flash outside of the region mentioned above. That is the reason why it does not allocate new pages outside of that region.

FDS will not touch flash inside of the region where the first part of the flash page does not equal the FDS page header (the magic word 0xDEADC0DE followed by either 0xF11E01FF for swap page or 0xF11E01FE for data page.) See the Storage Format section of the FDS documentation on Infocenter.

In order to figure out what has happened to the FDS pages, do you have a debugger that you can connect to the Dongle, or can you otherwise program it to write out the FDS page contents for us to have a look?

Regards,
Terje