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

Storing configuration info in flash over reboots. Canonical examples?

This is for a current project on SDK 15 and nRF52832.

My project has several configuration parameters, which exist as BLE attributes.

I'd like to make them persist across reboots.

I understand the way to do that is:

  • to store them in flash,
  • using fds on top of fstorage
  • update them when they change, and
  • sanity check (for presence and correctness) and load them on (re)boot.

But rather than just rolling my own code from scratch and documentaton ...

Is there sample code that does this?  (In the SDK, elsewhere, or could you post it?)

Parents
  • Hi,

    Yes, there is an example in the SDK that shows how to use the FDS module. You can find the example at <SDKFOLDER>\examples\peripheral\flash_fds

    The documentation on the example is found here, and documentation on the module can be found here.

    Best regards

    Jared 

  • Hi, Jared.

    That example is a "hello filesystem world".

    What I'm looking for would be something like this:

    A sample application which, on boot:

    • Checks whether there is a filesystem already in flash, uncorrupted, and containing the desired info
    •  * if not:  Creates it
    •  * Loads the initial values of selected BLE attributes from the filesystem, setting default values and writing them to the filesystem if they are not already there.

    and which, on BLE writes (or internal updates) to the relevant attributes' values (e.g. on_rw_auth_req() calls on_[attribute_name]_write(), both:

    • updates the attribute and,
    • if it changed, updates the entry on the filesystem.

    All with multiple simultaneous requests - some from BLE, some from other parts of the app such as timer callbacks or device callbacks, handled correctly.  All with no surprises, such as:

    • timing glitches and races,
    • lost updates if thing changes happen in bursts,
    • dropped connections,
    • bricked devices if the flash was too slow or things on different priority levels got confused,
    • everything keeps going if there filesystem has to be garbage collected.
    • other clients of the flash also work and "play well together"
    • etc.

    Is there something like that available as an example?  Or do we have to roll our own?

Reply
  • Hi, Jared.

    That example is a "hello filesystem world".

    What I'm looking for would be something like this:

    A sample application which, on boot:

    • Checks whether there is a filesystem already in flash, uncorrupted, and containing the desired info
    •  * if not:  Creates it
    •  * Loads the initial values of selected BLE attributes from the filesystem, setting default values and writing them to the filesystem if they are not already there.

    and which, on BLE writes (or internal updates) to the relevant attributes' values (e.g. on_rw_auth_req() calls on_[attribute_name]_write(), both:

    • updates the attribute and,
    • if it changed, updates the entry on the filesystem.

    All with multiple simultaneous requests - some from BLE, some from other parts of the app such as timer callbacks or device callbacks, handled correctly.  All with no surprises, such as:

    • timing glitches and races,
    • lost updates if thing changes happen in bursts,
    • dropped connections,
    • bricked devices if the flash was too slow or things on different priority levels got confused,
    • everything keeps going if there filesystem has to be garbage collected.
    • other clients of the flash also work and "play well together"
    • etc.

    Is there something like that available as an example?  Or do we have to roll our own?

Children
Related