This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

What happens with pstorage if order of pstorage_register changes?

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...

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related