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

Want to use NVM for saving user settings , how many bytes can be used, any limitations , and what is the minimum/maximum size, that can be reserved for such usage

Hi Nordics,

we would like to evaluate the possibility of using NVM to store user settings. Based on the following searches, we still have some queries.

infocenter.nordicsemi.com/index.jsp
infocenter.nordicsemi.com/index.jsp
infocenter.nordicsemi.com/index.jsp


devzone.nordicsemi.com/.../using-flash-nvm-to-simulate-eeprom
devzone.nordicsemi.com/.../nrf52-flash-memory-vs-eeprom
devzone.nordicsemi.com/.../does-the-nrf52832-chip-has-internal-eeprom-if-it-has-how-much-is-the-size-of-eeprom
devzone.nordicsemi.com/.../any-librabry-support-for-eeprom-emulation-on-nrf51-flash-memory
devzone.nordicsemi.com/.../how-to-protect-the-data-written-into-flash-from-being-erased-when-flashing-nrf52832
devzone.nordicsemi.com/.../flash-storage-start-and-end-address
https://devzone.nordicsemi.com/f/nordic-q-a/59056/how-to-avoid-erasing-the-special-page-of-flash-which-stored-some-user-datas-when-reprogramming-nrf52832-through-bootloader

1) How many bytes can be used for our purpose, and is it limited to the application area only? 

2) Are there any limitations or constraints (minimum/maximum size that can be reserved for such usage) ? E.g if we want to reserve 2k bytes , would 4k bytes need to be reserved minimum , or is it based off 1k byte multiples so only 2k bytes would be reserved ?

3) If we are constantly updating this user setting, would it clash with the BLE stack and cause slowdown or even render un-usable applications?

thx

Pete

Parents
  • Hi Pete, 

    1) How many bytes can be used for our purpose, and is it limited to the application area only? 

    You need to get an overview of your memory layout. If you use a bootloader, then the application data is placed above the application but below the bootloader. If you don't have a bootloader, then everything above the application can be used for application data.

    When you know your memory layout, you also know how many pages (of 4096 byte each) you have available for user data. Please remember that if you use the peer manager for bonding this use the flash data storage (FDS) library, and so a minimum of two pages must be reserved for FDS. If you choose to also use FDS for your other application data, you should probably increase the number of FDS pages, depending on how much data you need to store. You can also reseve flash pages specifically for your user data and access them directly, and then you need to pick pages that are above the application but below the FDS pages.

    2) Are there any limitations or constraints (minimum/maximum size that can be reserved for such usage) ? E.g if we want to reserve 2k bytes , would 4k bytes need to be reserved minimum , or is it based off 1k byte multiples so only 2k bytes would be reserved ?

    The flash page size is 4096 byte (1024 words), so you need to reserve a multiple of 4 k blocks.

    3) If we are constantly updating this user setting, would it clash with the BLE stack and cause slowdown or even render un-usable applications?

    Flash operations take a long time, and therefore it is only legal to write and erase flash via SoftDevice API's when the SoftDevice is enabled. This allows the SoftDevice to schedule flash operations in between BLE activity. It is possible to come to a situation where flash writes are not possible, but the SoftDevice will attempt to schedule flash writes as long as it does not cause BLE disconnects. This is usually not a problem.

    Einar

Reply
  • Hi Pete, 

    1) How many bytes can be used for our purpose, and is it limited to the application area only? 

    You need to get an overview of your memory layout. If you use a bootloader, then the application data is placed above the application but below the bootloader. If you don't have a bootloader, then everything above the application can be used for application data.

    When you know your memory layout, you also know how many pages (of 4096 byte each) you have available for user data. Please remember that if you use the peer manager for bonding this use the flash data storage (FDS) library, and so a minimum of two pages must be reserved for FDS. If you choose to also use FDS for your other application data, you should probably increase the number of FDS pages, depending on how much data you need to store. You can also reseve flash pages specifically for your user data and access them directly, and then you need to pick pages that are above the application but below the FDS pages.

    2) Are there any limitations or constraints (minimum/maximum size that can be reserved for such usage) ? E.g if we want to reserve 2k bytes , would 4k bytes need to be reserved minimum , or is it based off 1k byte multiples so only 2k bytes would be reserved ?

    The flash page size is 4096 byte (1024 words), so you need to reserve a multiple of 4 k blocks.

    3) If we are constantly updating this user setting, would it clash with the BLE stack and cause slowdown or even render un-usable applications?

    Flash operations take a long time, and therefore it is only legal to write and erase flash via SoftDevice API's when the SoftDevice is enabled. This allows the SoftDevice to schedule flash operations in between BLE activity. It is possible to come to a situation where flash writes are not possible, but the SoftDevice will attempt to schedule flash writes as long as it does not cause BLE disconnects. This is usually not a problem.

    Einar

Children
No Data
Related