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.

[Johan Dahlgren]

Thank you for your answer! Yes, the storage part itself seems pretty straight forward using pstorage or fds.

But what I struggle the most with and having a hard time to find any exampels on is where/howto get the data that is written to the attribute. Should I listen on some BLE event or something like that? Having a really hard time to wrap my head around this :)

[Philip Hart]

This is a very timely question, because I have a similar requirement. Would be great to see some example code.

[endnode]

Well there is no event which will tell you "the data were read for you":) All storage systems work the same way as your hard drive on your PC: they are able to store "named" objects (blobs of data) which have either very abstracted names or just addresses. But you are responsible to store them and read them whenever you want and you are responsible to know what name means what;) So during your boot you need to init storage system and ask it to read certain "objects" which you then put as GATT handle values through normal SD BLE GATT API calls. I will try to look up which of SDK examples shows the closest sequence to your use case, which file/storage system you decided to use?:)

[Johan Dahlgren]

What I´m looking for is where I can catch the incomming data (from the BLE client). As far as I can understand it should be in some BLE Event, so I from there can get the attribute and it´s value and then store it in my persistent storage. So the storage part is my least concern, other then choosing the right one :)

[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!;)))