Best approach to store nonvolatile data?

[riceman0]

Hello, we are creating a nordic peripheral using an nrf52832 and SoftdDevice S112 and SDK 16.0.  We need to store quite a bit of data non-volatilely, at a fairly fast rate.

A loong time ago, in an SDK version far far away, we created some configuration storage into one of our peripheral devices using a "pstorage"API which contained function calls like sd_flash_page_erase and sd_flash_write.

I assume there are new APIs, and looking at the documentation 

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Findex.html

I see "experimental: flash data" and "experimental: flash storage"

I have to admit I'm a little nervous because of that word "experimental".  Is there no ready-for-prime-time nonvolatile storage API that is part of the softdevice?  What is the recommended approach for Nordic developers?

Thanks for any insight.

[Edvin]

Hello,

For flash storage, FDS or fstorage is indeed the way to go. As you say, it is listed under experimental, but it is used in e.g. the peer_manager, which stores bonding data for the softdevice.

I don't know whether fstorage or fds would be the best approach for you. FDS has a bit more overhead, but it keeps track of the physical addresses, and an even flash tear, but fstorage may be faster, but it may be a bit more work, because you need to keep track of what addresses you stored different data on. In addition, you may know that you need to erase a flash address before you can write to it again, but you can't delete only certain bytes. You must erase one flash page at the time. Therefore, for continuous updates in your flash records, I would recommend FDS. This will also handle cases like power loss during a "garbage collection" (fds_gc()), which ensures that no data should be lost even if it is in the process of deleting an old page.

That being said, there are some fall pits you should avoid using FDS. Do not run fds_gc() on every startup. It is recommended to only call this whenever an fds_write() or fds_update() returns an err_code saying that the flash is full. This is both to not beat up the flash, but increase the lifetime of the flash (spread out the flash write/erase cycles), to save power, and reduce the chance of something going wrong.

You mention that you were going to use SDK16.0.0. That is good,  because this SDK version comes with an important FDS bugfix (that was triggered by fds_gc() on startup). As far as we know, there are no more, but better to be safe than sorry. FYI, the bug was related to loosing power during the GC, and when you are low on battery, the chip may start and be turned off many times, due to an unstable power supply.

Best regards,

Edvin

[riceman0]

Thanks very much, very helpful!  So... if you feel it is reliable, why is it still marked "experimental"?

Also, another question, to settle an internal discussion; one of our developers started looking at the nRF52832 datasheet register-level commands to save data to FLASH.  This would be circumventing the Nordic SDK and Softdevice altogether, I suppose.  My position currently is to use fstorage, but would it be even possible/safe/supported for us to access the hardware directly?

Thanks.

[Edvin]

Hello,

I don't know when/if the experimental mark will be removed. Usually this mark is added on new libraries, but I guess they are not satisfied with the test firmware to remove it. We can't guarantee that anything in the SDK is bug free, except from the softdevice. Many customer use the FDS and fstorage today.

 

riceman0 said:

but would it be even possible/safe/supported for us to access the hardware directly?

 What do you mean, exactly by "access hardware directly"? To skip the drivers and use the registers directly? 

I guess it is possible. It is very typical for "old school" engineers, because they believe it is much more efficient. Typically the same guys who insist on programming using assembly directly. The drivers and libraries are there for a reason. Compilers today are much better than they used to be, and they will optimize the compiled binary quite well.

You are free to use the registers directly. You can probably see that the drivers do this (it is open source, except for the softdevice). But please note that what you write would probably be marked as experimental as well. At least the libraries that we deliver are well tested by many customers running on our HW.