What happens with pstorage if order of pstorage_register changes?

[Anthony Ambuehl]

I'm wondering when my firmware changes over time what will happen with information stored with pstorage? For example if I my new firmware release adds an additional pstorage_register that occurs in between several existing pstorage_register calls what will occur? Also where does the pstorage flash reside? Is it contained within the hex firmware image or is it placed in another fixed location?

BTW, Is there any persistent storage mechanism that would use a application managed ID to store data? I'm looking for something similar to TI's osal_snv_* system...

[Hung Bui]

Hi Anthony,

Each time you call pstorage_register, the library will register the next consecutive page(s) for that application.
So if you already have data stored for application 1 next to application 2, you should not register application 3 between the registers of application 1 and application 2. If you do, application 2 data will be overwrited by application 3 blocks.

The pstorage data stored in flash start from PSTORAGE_DATA_START_ADDR. Each application's blocks will be reside inside a page or several pages if their total size are bigger than 1 page. However no block from 2 application shares the same page. Data between applications are separated by pages.

I am not familiar with TI architecture/API, could you explain a little bit more about what it does ?

[Anthony Ambuehl]

I am definitely concerned about using pstorage then. During future development if I change the order of initialization or add an additional item in the middle then the storage will be corrupted.

The other systems I have used were more like a file system. The application provides an unique id along with each piece of data to store. Later it can retrieve that data using the id in any order. Also the data size can grow or shrink without impacting the other data stored.

I suppose a layer on top of pstorage could provide some similar capabilties, it would be helpful if it already existed...

a*

[Krishna Shingala]

Hi Anthony,

Where the persistent data resides, how many applications are registered and and how many pags are reserved are configured based on your application and use case needs in pstorage_pl.h in SDK 5.0.0 renamed to pstorage_platform.h in SDK 5.1.0 onward. Therefore, it is you who will control where and how the persistent data resides.

Further, in case size of data changes, for example, bonding information you used to store has changed from 64 bytes to 90 bytes, I am not sure how having knowledge of actual physical addresses could have helped. And if it does help, the block id, in the pstorage_handle_t provided at time of registration contains the actual flash address of where data for the application can be stored.

Coming to changing the order of registry, I am assuming this applies only to use cases where firmware is upgraded. On upgrade, if your persistent data requirements have changed in terms of number of modules storing data persistently or a module storing less or more data than it earlier did, immaterial of what pstorage module provided, you would have to back up the old data and be able to map it to the new table. And this would be true even otherwise. You have all needed mechanism of backing the data, and setting up the storage for the new firmware from pstorage module. This, however, is not provided in the DFU provided by the application yet.

To summarize, pstorage is an abstraction layer so that SDK modules needing to store data can remain agnostic of actual limitations or complexities required to access persistent memory providing a developer with flexibility to enhance data storage itself, without having to touch the user modules. Therefore, all attempt is made to not provide the user modules with details of where the data is stored is an actual physical address or an identifier of some sort that can be mapped to a virtual address.