NV RAM Persistant Storage Question

[Kevin Kachikian]

Hi.

- Is it the case that before every write to persistent storage via nrf_fstorage_write, the page written to has to be erased first (via nrf_fstorage_erase) since only 0 bits can be written?

- Are there a limited number of nrf_fstorage_erase's that are allowed per page before that part of NVRAM becomes non-writable. IOW, is some kind of level wearing needed?

- Aren't there going to be BLE connection issues or BLE dropping when doing NV writes or erases because the data sheet says that the CPU is halted for up to 89.7ms worst case (page 30 of "nRF52832 - Product Specification v1.0")? 43ms is required worst case when writing a whole page worth of data in one shot (338us * 128).

- Is there some good library that can be used which handles these issues and simplifies persistent storage usage?

Thanks,

Kevin

[Susheel Nuguru]

Are there a limited number of nrf_fstorage_erase's that are allowed per page before that part of NVRAM becomes non-writable. IOW, is some kind of level wearing needed?

 On the nRF52, flash endurance is 10,000 cycles.

Is it the case that before every write to persistent storage via nrf_fstorage_write, the page written to has to be erased first (via nrf_fstorage_erase) since only 0 bits can be written?

You need to erase the page only if there is already if the contents of the memory you are trying to write is not empty. (that is if the memory contains 0 bits instead of all '1's at the address you are writing to). If the contents of the memory are all 1's (oxFFFF FFFF) then you can write to that location without erasing the page. 

- Aren't there going to be BLE connection issues or BLE dropping when doing NV writes or erases because the data sheet says that the CPU is halted for up to 89.7ms worst case (page 30 of "nRF52832 - Product Specification v1.0")? 43ms is required worst case when writing a whole page worth of data in one shot (338us * 128).

Most of the libraries/drivers use sd_flash_write/sd_erase_write when they are accessing flash in the combination of BLE activity. And the BLE stack (softdevice) makes sure that these two operations (flash access) and the radio activity  blends well together. So the application do not need to be worried about the exact scenario you mentioned when using sd_flash_XXX API

- Is there some good library that can be used which handles these issues and simplifies persistent storage usage?

FDS and FStorage are libraries that you can use on high level abstraction. These libraries will take care of checking the memory to see if it  has already some data and uses a SWAP page to first transfer all the contents of the page you are writing to to the swap page and then erase the page, and copy back from swap page to the page in your interest  EXCEPT the memory location you want to update.

[Kevin Kachikian]

Thanks Susheel. Do you know why the 10,000 flash endurance is not documented in the data sheet (that I can find!)? That's kind of important information I think, no?

These libraries look great but they are marked "experimental". Do you know why? 

Thanks again for the help!

[Susheel Nuguru]

Kevin Kachikian said:

Thanks Susheel. Do you know why the 10,000 flash endurance is not documented in the data sheet (that I can find!)? That's kind of important information I think, no?

 I thought it was documented in the spec, but cannot find them now. Might have missed to update it when we were moving our documentation servers. I will try to make a note of it. Yes, this is important information and should be easily visible. 

Kevin Kachikian said:

These libraries look great but they are marked "experimental". Do you know why? 

 That is a good question, these libraries are out there for quite sometime now and in many many products. They should not be marked experimental, as they are very mature in my opinion. Please ignore the experimental tag and use them as one of the other production quality libraries. It must be a mistake to still keep them marked as experimental. I can clearly see that they are NOT marked experimental in the sdk files, so it must be a documentation bug.