Saving Variables to Non-Volatile Memory

Hello,

I am trying to figure out how to save a small number of counters to local non-volatile memory on the nRF9160. I have a few questions.

1) How do I determine whether a section of memory is safe to use as storage? Can I just use any location from my storage or scratchpad partitions that I defined in my device tree files? Will that location be stable through a power-on-reset? Do I have to worry about the partitions moving address locations over time as my program changes? Do I need to worry about my application code overwriting that location?

2) How do I actually read and write that location? Are there limitations on reading and writing those locations? Is the Zephyr Flash Interface the best way to do this, or are there others? the Nordic NVMC seems to only allow writing and erasing. 

I have looked at https://devzone.nordicsemi.com/f/nordic-q-a/61931/nrf9160-flash-access. It seems to support that I can use the Flash Interface, but it does not answer a number of my above questions.

I am using an nRF9160 on a custom board. SDK version 1.6.1.

Parents
  • Hello Jeremy,

    1) How do I determine whether a section of memory is safe to use as storage? Can I just use any location from my storage or scratchpad partitions that I defined in my device tree files? Will that location be stable through a power-on-reset? Do I have to worry about the partitions moving address locations over time as my program changes? Do I need to worry about my application code overwriting that location?

    You can check the resulting partitions in the generated pm.yml file, which gives you a dynamic partition allocation. This will remain on restart, but won't be safe if you decide to to add something to your application and re-build. However, you can then create a new pm_static.yml file in which you can modify and create your own partitions. The partitions defined in a pm_static.yml file won't change on start-up etc. There you could create your own partitions for storage. For more info see here.

    2) How do I actually read and write that location? Are there limitations on reading and writing those locations? Is the Zephyr Flash Interface the best way to do this, or are there others? the Nordic NVMC seems to only allow writing and erasing. 

    Well there is the Zephyr Flash Interface, which you mentioned. There is an example available here. I believe the NVMC is used to deal with secure partitions from an non-secure one - not exactly what you are looking for. Though let me get back to you on both that, and what flash interface is preferred.

    Regards,

    Elfving

Reply
  • Hello Jeremy,

    1) How do I determine whether a section of memory is safe to use as storage? Can I just use any location from my storage or scratchpad partitions that I defined in my device tree files? Will that location be stable through a power-on-reset? Do I have to worry about the partitions moving address locations over time as my program changes? Do I need to worry about my application code overwriting that location?

    You can check the resulting partitions in the generated pm.yml file, which gives you a dynamic partition allocation. This will remain on restart, but won't be safe if you decide to to add something to your application and re-build. However, you can then create a new pm_static.yml file in which you can modify and create your own partitions. The partitions defined in a pm_static.yml file won't change on start-up etc. There you could create your own partitions for storage. For more info see here.

    2) How do I actually read and write that location? Are there limitations on reading and writing those locations? Is the Zephyr Flash Interface the best way to do this, or are there others? the Nordic NVMC seems to only allow writing and erasing. 

    Well there is the Zephyr Flash Interface, which you mentioned. There is an example available here. I believe the NVMC is used to deal with secure partitions from an non-secure one - not exactly what you are looking for. Though let me get back to you on both that, and what flash interface is preferred.

    Regards,

    Elfving

Children
  • I have tried to get the NVS to work, but the samples (both the 1.9 one and the 1.6 one) will not compile for me. I believe they are for a nrf5 series chip, not the nrf9160 that I am using.

    My issues is that I cannot figure out how to get them to give me the device binding for the flash partition I want to write to. I can get the node ID, and I verified the label exists, but cannot figure out where to go from there.

    I did get my system to work using the NVMC, but I have already seen the data integrity issue be present. 2 of my 6 pages (the two highest in address) in the storage partition are being changed by other processes in the code without my intention.

    I will take a look at the example you linked to.

  • Hello Jeremy, sorry about the wait.

    jdorn said:

    I have tried to get the NVS to work, but the samples (both the 1.9 one and the 1.6 one) will not compile for me. I believe they are for a nrf5 series chip, not the nrf9160 that I am using.

    That is odd, I just tried nRF9160_ns and nRF52832 and both seem to compile for me. But in either case I believe trying what is presented in the example I provided below is a better starting point than this sample from Zephyr. 

    jdorn said:
    My issues is that I cannot figure out how to get them to give me the device binding for the flash partition I want to write to. I can get the node ID, and I verified the label exists, but cannot figure out where to go from there.

    Did you try the lines about this in the example I linked to?  flash_dev = device_get_binding(DT_CHOSEN_ZEPHYR_FLASH_CONTROLLER_LABEL); ? This should work on nRF9160, and I believe this snippet is a good resource on how to work with the flash.

    jdorn said:

    I did get my system to work using the NVMC, but I have already seen the data integrity issue be present. 2 of my 6 pages (the two highest in address) in the storage partition are being changed by other processes in the code without my intention.

    Could you expand on this and how you are discovering this being an issue? 

    Elfving said:
    Though let me get back to you on both that, and what flash interface is preferred.

    There are several opinions on this, though the OS flash write API is recommended if you want to stay as portable as possible. Though using eg. NVS or the settings subsystem are also popular options. 

    Regards,

    Elfving

Related