How could locate properly user records in flash for use with fstorage?

[samsam]

I’m interesting particularly nRF52832 and nRF52840  (with and without bootloader)

So looking at flash layout with bootloader:  

1. is the section ‘Application data’ available for user data and how can find what is occupied and what and where not?
2. How could find where exactly starts the ‘Free’ zone above ‘Appilcation’
3. Unless could go with simple extrapolation from what is given as examples to what i not given - How could find memory addresses for combinations Chip/Sofdevices not listed in this Memory layout table  ( I’m particularly interested nRF52832 with S112 and S113 and nRF52840 with S113 )
4. If there is no bootloader in use – how looks the Memory layout – is there ‘Application Data’ or the ‘Free’ zone goes up to the top?

Thanks

[Hung Bui]

Hi Samsam, 

1. The section "Application data" is available for user data. There is no format on how it should be used, it's just tell the bootloader the number of pages (in bytes) that the bootloader should not touch when doing DFU. This is defined by NRF_DFU_APP_DATA_AREA_SIZE. So in short, the bootloader look at NRF_DFU_APP_DATA_AREA_SIZE and will not erase that area right under the bootloader and this area is retained after the DFU update. 

2. What exactly you want to with the "Free" zone ? This is the zone that the bootloader will use to store the image when it receives the new image. This area will be erased on each  DFU. If you want to store your data, please use the Application data space. 

3. It's quite simple, the softdevice always starts at 0x1000 (when combine with the MBR it starts at 0x0000). The bootloader is always located at the top of the flash, which means when combine with the bootloader setting and MBR storage, it will end at the top of the flash. You just need to check the size of the chip you can calculate the start address of the bootloader.  For example if you use S112 on nRF52832 512kB flash size. The softdevice will range from 0x1000 to 0x19000. And the bootloader will start at 0x78000 and end at 0x7E000.

4. If there is no bootloader, there will be no "Application Data" because it's the define for the bootloader  not to touch the area. So you can put your application data anywhere from the last page of the application (app_size in the memory map, it's actually the address of app_start+app_size) 

However, if you use fds flash module like in most of our ble examples, you can find that the "application data" area where the fds data located is calculated by flash_end_addr(). The top end of the area will be located at either start address of the bootloader, or the end of the device flash size (code_sz * page_sz) . Unless there is a reserved pages for other module (FDS_VIRTUAL_PAGES_RESERVED by default =0). And the start address is FDS_VIRTUAL_PAGES page behind the end address. 

So, in short the fds data (bond information , user data etc) is stored right under the bootloader  with the size of FDS_VIRTUAL_PAGES. This usually match with the NRF_DFU_APP_DATA_AREA_SIZE. This way after a DFU update, the fds data is reserved.  
When there is no bootloader, no FDS_VIRTUAL_PAGES_RESERVED , the fds data is FDS_VIRTUAL_PAGES at the top end of the flash. 

[samsam]

Hi Hung Bui,

I’m trying to find easiest and fastest way to read couple bytes stored my data at boot time (or earliest after), so fstorage was seemed to me best option, just have doubts how to properly locate the storage location address so not to have conflict with the other modules that could use same location.
Else I already   use FDS (indirectly through Peer Manager), but initially was thinking it is too much extra burden to use it and for my simple data as well my guess was that it will taka far more time to read the data.

So what could you suggest – between using fstorage to save my couple bytes just beneath what is occupied from FDS virtual pages and later when implement and DFU will have to increase the NRF_DFU_APP_DATA_AREA_SIZE with the number of bytes I’ll use; OR to use direct some of the FDS functions to store my bytes somewhere in the virtual pages already allocated?

If  use fstorage – when is the earliest moment I could read my data – after  ble_stack_init() ?

In your previous post you mention app_size, but I can’t find such function – what is the way if I want to find the actual app size (or the top address app code occupies)?

And one more last question – What I’m missing (or is a bug ) from the attached picture: in sdk_config.h NRF_DFU_APP_DATA_AREA_SIZE shows 12288 which looks correct for me, while CMSIS show it as 3000 while still claims that units are bytes?

Thanks

[Hung Bui]

If you do have FDS module initialized, it's the best to use FDS. If you only store a few bytes no change in the FDS configuration needed. Usually it's 2 (+1 swap) pages reserved for FDS. 
You don't need to initialize the softdevice before you can use the fstorage (even if it use sd backend) as long as the application booted via the softdevice (except when you are in bootloader). 
Please follow what described here to store your data. 

12288 = 0x3000 i hexadecimal , the configuration app should be clearer on the format. 

[samsam]

Hi Hung Bui,

Actually, right now I don’t initialize FDS myself, but this is done from peer_manager_init and the peer manager in my code currently is initialized too late in the sequence of other initializations.

I don’t see in the documentation any prerequisites regarding peer manager initialization, so do you see any problems and could I move the peer_manager_init up(earlier in main) without damage?

The other my option is to add my fds events handler and fds_init(); immediately after ble_stack_init();  as this is the only claimed prerequisite  in the documentation?  

BTW both online documentation and fds.h are not updated and falsely  claim ‘changing the value of FDS_MAX_USERS in fds_config.h’ – there is no fds_config.h file in SDK16 and FDS_MAX_USERS is configured through sdk_config.h

Thanks

    // Activate deep sleep mode.
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
    // Configure and initialize the BLE stack.
    ble_stack_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    gap_params_init();
    gatt_init();
    advertising_init(); //TODO ->in callback after flash data read
    services_init();  	//TODO ->in callback after flash data read
    sensor_simulator_init();
    conn_params_init();
    peer_manager_init();  
	....

[Hung Bui]

Hi Sam, 
You can register your handler and call fds_init() right after ble_stack_init() . There is no problem if fds_init() called again inside peer manager. I will report the update of the documentation to point to sdk_config.h instead.