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

the inquiry for the usage of fds function & fstorage....

Hello,

I have 2 issues, please help to let me know and clarify them...thankful for your support in advance....

I need to know the confirmation about the usage of fds function, and to clarify the usage of fstorage in dfu(air not serial) environment... (overall necessary things to use correctly them..)

I need to use the fds function or fstorage function to save user data in dfu environment,

it means that the user data should be kept after doing dfu...

and I know that I should set DFU_APP_DATA_RESERVED in components\libraries\bootloader\dfu\nrf_dfu_types.h in order to confirm the size that should be matched with the size of user data that I would like to use/save... if being over... the error will be happened in fds and fstorage function... is it right ?

firstly, as to the usage of fds function, I enabled the related config in sdk_config.h like FDS_ENABLED, FDS_VIRTUAL_PAGES (I set it as 8) so on...

and I add fallback function to prevent data loss in the process of writing or updating in yps_storage_fds_evt_handler by using garbage collection function. 

please refer the code of the following link.. and help to let me know whether the code is no problem to use for mass-production...

when doing test for many times, if can confirm that the size of fds memory (saving region) is not over the size of user data. 

it no made any error.... it means that the key id of the same file id should be made by the size of user data that I would like to save... is it right ?

https://devzone.nordicsemi.com/f/nordic-q-a/29876/fds_err_not_found-issue-of-yps_storage_find-in-sdk-14-0-1?ReplySortBy=CreatedDate&ReplySortOrder=Ascending

if the code is no problem, I will use it to save user data for mass-production...

secondly, as to the usage of fstorage function, 

currently I don't know which address I should set for start/end address....

I know that if using dfu, the memory map is the same as the following link....

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.2.0%2Flib_bootloader_dfu_banks.html&cp=4_0_0_3_5_1_2_2&anchor=lib_bootloader_dfu_appdata

and I know that I should use the region of app data to save user data.. is it right ?

so I check the DFU_APP_DATA_RESERVED setting to confirm the size ....

currently I set it as 8, so 8 * 1024 => 8k => 0x2000 so... I can set start address as 0x7D000 - 0x2000 =7b000. and end address is 0x7d000 is it right ?

if right, when experimenting by updating dfu image and firstly writing data and after updating package file (only app), only trying to read the same address, the result is failed, why ?

please help to let me know what is wrong or missing in the overall process....I need earnestly your help... I update the code. please refer the following link...

and if possible, Could you please kindly provide the example code with the detailed guide(instruction) ?

devzone.nordicsemi.com/.../nrf_fstorage_def-address-defined-issue-with-14-1-0

thanks.

  • it means that the key id of the same file id should be made by the size of user data that I would like to save... is it right ?

    FDS will automatically manage its own data and ensure that it stays within the number of FDS_VIRTUAL_PAGES which should never be defined to be larger than the bootloaders DFU_APP_DATA_RESERVED. Most of the time these are just set to the same number and FDS will be allowed to use the entire flash area. You may if you like set FDS_VIRTUAL_PAGES to 3 and DFU_APP_DATA_RESERVED to 5 which will leave the two first flash pages in the data region untouched by both FDS and the bootloader, so that you may perform your own custom defined actions here.

    fstorage writes exactly where you tell it to write, so you need to check that the destination address of write and erase operations is set to an allowed value. Fstorage is intended as a simpler and more direct way to interface with the flash, while still working as an abstraction layer removing some of the complexity of writing directly to flash though NVMC and the SoftDevice.

    it means that the key id of the same file id should be made by the size of user data that I would like to save...

    Fstorage and fds are both quite well tested, so I wouldn't be too worried about using them in production. Code found around DevZone from regular users and Nordic support team members is not tested, and you will have to review and test the code yourself. The examples in the nRF5 SDK is probably better to use when you are trying to understand how to correctly use the libraries.

    it means that the key id of the same file id should be made by the size of user data that I would like to save.

    Sorry, I don't quite understand the question. If you are still wondering about this, please try to clarify what you are wondering about.

    currently I don't know which address I should set for start/end address....

    If using fstorage though FDS, let FDS decide this. If you use fstorage directly make sure to stay within the region reserved in the bootloader and do not write inside pages used by the FDS.

    currently I set it as 8, so 8 * 1024 => 8k => 0x2000 so... I can set start address as 0x7D000 - 0x2000 =7b000. and end address is 0x7d000 is it right ?

    A flash page is 1024 32-bit words which is 4096 byte. 8 flash pages are 32k => 0x8000. The start address is END_ADDRESS - 0x8000. Not sure where you got 0x7D000 from, the current bootloader has start address 0x78000, so you should not write anything at 0x7D000.

    when experimenting by updating dfu image and firstly writing data and after updating package file (only app), only trying to read the same address, the result is failed, why ?

    Sorry again, but I am not quite sure what you are saying failed. If you tried writing at addresses in the range 0x7B000 - 0x7D000 you have corrupted the bootloader, so that may be what is causing problems.

    Could you please kindly provide the example code with the detailed guide(instruction) ?

    The nRF5 SDK has example showing the correct usage of fds and fstorage. You can find these example in the following SDK folders:

    examples/peripheral/flash_fds

    examples/peripheral/flash_fstorage

    I hope this clarified the FDS and fstorage a bit. I have not gone too deep into the code in your other case, as I see my colleague is already assisting you in that case.

    Best regards,
    Rune Holmgren

  •  Hi, Holmgren,

    thankful for good information, I found the problem, before, I set like that FDS_VIRTUAL_PAGES is bigger tha

    n DFU_APP_DATA_RESERVED.. so maybe the diverse issues were happened. 

    I follow the following information and then I can read/write user data with fstorage or FDS (ALL)....

    FDS will automatically manage its own data and ensure that it stays within the number of FDS_VIRTUAL_PAGES which should never be defined to be larger than the bootloaders DFU_APP_DATA_RESERVED. 

    and ....

    it means that the key id of the same file id should be made by the size of user data that I would like to save... is it right ?

    ==> it is wrong expression, sorry....what I mean is that the size of user data that I would like to save should be matched (not over) to the size of FDS (by the setting value of FDS_VIRTUAL_PAGES)...

    thankful for your support...

    thanks.

  • I set as to DFU_APP_DATA_RESERVED, FDS_VIRTUAL_PAGES like below,

    #ifndef DFU_APP_DATA_RESERVED
    #define DFU_APP_DATA_RESERVED CODE_PAGE_SIZE * 16 //#define CODE_PAGE_SIZE                  0x1000
    #endif

    #ifndef FDS_VIRTUAL_PAGES
    #define FDS_VIRTUAL_PAGES 8
    #endif

    thanks.

  • edmond.yun said:
    the size of user data that I would like to save should be matched (not over) to the size of FDS (by the setting value of FDS_VIRTUAL_PAGES)

    Yes, this is correct. Give it a little bit of extra space as well for the overhead of the FDS's metadata. FDS is very lightweight, but there will be a little bit of extra data stored.

    Best regards,
    Rune Holmgren

Related