Does "__start_fs_data" in flash_placement.xml know "Flash storage starting address" we wrote in the code?

[cpeng]

Hi Devzone:

I have been testing flash storage project.

in my code I have declared a one page flash at 0x40000 for my own use:

#define FLASH_START_ADDR  0x40000

NRF_FSTORAGE_DEF(nrf_fstorage_t cd_settings_fstorage) =
{
    .evt_handler = cd_setting_fstorage_evt_handler,


    .start_addr = FLASH_START_ADDR,
    .end_addr   = FLASH_START_ADDR + 0x1000, //0x41000
};

And in flash_placement.xml I have inserted the following two lines:

<ProgramSection alignment="4" keep="Yes" load="Yes" name=".fs_data"  inputsections="*(.fs_data*)" runin=".fs_data_run"/>
<ProgramSection alignment="4" keep="Yes" load="No" name=".fs_data_run" address_symbol="__start_fs_data" end_symbol="__stop_fs_data" />

I am a little uncertain whether the "__start_fs_data" here in flash_placement.xml knows about the "FLASH_START_ADDR 0x40000" I wrote in my code above (first code block in my post). 

1. How does segger make that connection between these two? Or do I have to explicitly make that connection myself? If so how?

2. What happens if you declare two or more flash storage sections in your code? Do you need to add more lines in flash_placement.xml? How do the code and the lines in flash_placement.xml connect respectively?

This is a question I have after reading this post:

https://devzone.nordicsemi.com/f/nordic-q-a/58908/using-symbols-to-set-fstorage-start-and-end-address

Thanks.

[Edvin]

The flash placement macros are there so that the application doesn't overwrite it. But to be honest, I have never looked into this when using fstorage. I believe that the best approach is to store fstorage data close to the end of the flash. Depending on whether you store any other application data such as FDS, Peer manager to store bonding data, or a bootloader, you should place your application data at the end of your flash, or right next to these (FDS/bootloader).

I don't know exactly where fs_data is fetched from. 

Look at the SDK\example\peripheral\flash_fstorage's SES project how it is done there.

I don't think you need to edit the flash_placement.xml if you want several sections. 

If you intend to save a lot of data, I suggest you at least check out FDS, which handles addressing and updating of flash records.

BR,

Edvin

[cpeng]

"Look at the SDK\example\peripheral\flash_fstorage's SES project how it is done there.

I don't think you need to edit the flash_placement.xml if you want several sections. "

The example project "flash_fstorage" doesn't seem to link between the starting address in their main code(0x3e000) with their lines in flash_placement.xml (__start_fs_data).

Am I safe to assume these two places regarding flash start address are not correlated?

If they are not correlated, how come this post indicate otherwise?

Please read the post by David Meiklehohn and get back to me.

As this is for development for a commercial product, I would need you as Nordic representative to give me a solid answer.

Thanks.

[Edvin]

What the person in the ticket you link to is trying to do is to fetch the addresses that are set in the flash placement file to use it in the application. One reason for this can be that they want to reserve these addresses from being part of the application. This doesn't mean that the application can't touch these addresses, but it should give you a compiler error if the application grows so big that it covers this region of the flash with the application image (the hex file that you generate when you compile).

That being said, I don't think that that specific feature works in SES. I believe there is a bug that doesn't give you this compiler error. 

What you should do, if you want to use fstorage directly, is to place it all the way at the top of flash. If you intend to use a bootloader, then use the flash right below the bootloader.

Then, when you compile, look at the flash footprint of the application, and make sure that it doesn't overlap with the flash address that you use for your for fstorage.

[cpeng]

Thanks for your advice!