nRF51 persistant storage of characteristics data

[Johan Dahlgren]

What is the best way to store the values of my attribute data? With my current code, from the tutorials, the read, write and notify works fine. But I need to store the data in a more persistant way so the data is availble after a restart.

Have looked at some examples an how to use the PManager and Flash Manager but I don´t understand how to use it with my attribute data.

Kindly regards, Johan Dahlgren

[endnode]

Hi Johan,

There are typically two ways:

1. You will use some prepared library/module/filesystem like pstorage/fstorage/FDS. Then you need to understand how it works (= how it abstracts storage in terms of files or objects which you need to create/store/update/delete) and map your data on top of that. This is usual way but then we are done here, you will need to go deeper into SDK examples which are using these modules, their documentation in nRF5 SDK package on Nordic Infocenter and if you have specific questions to some of them then we can address them (but note that most of questions were already asked and answered on this forum so search first). This way should be relatively easy to implement and maintain/test (you have something done and used by many smart people before you) but maybe harder to understand.
2. You prefer to build and manage your own simple "file system". Then you should be fine with understanding that you need to (typically hardcoded) reserve one or more flash pages and then you can use SD API (if Soft Device is running at that time) to write any data to any memory address and erase any page. "Business" logic on top of it is on you (= which data you store where, how much space you need to allocate, when to erase whole page and where to write next "record"). It is easy to understand but harder to design the solution, implement and test.

In the end whatever way you choose your application need to know when you want to store the values (probably any time they change) and when you load them (probably only at restart). If you have hard requirements on atomicity/tear-safe character then you might need to even maintain two redundant instances of the same storage.

[endnode]

Sorry but now you are mixing two things: BLE link and exchange of data over higher layers like GATT and local persistent data storage inside the FW. They have nothing in common except that you need to somehow store the data while BLE stack is in operation (if it is the case) and that you also inside your FW logic use these persistent data inside GATT protocols.

Now which part you are asking in your last question? If persistent storage then it should be clear from my description. If you ask how the data get transported over BLE GATT then it's completely different story (and explained in many tutorials and Q&S on this forum). If you ask how to use these persistently stored data on GATT Server side to initialize GATT structures (like GATT Characteristic values) then the answer is obvious: the exact same ways as any other (non-persistent) data!;)))