where to save NON-volatile device parameters?

[StefXinet]

Dear Nordic,

we need to save few bites (product serial number, few settings). we use BLE with bonding on a FreeRTOS based FW. PM is already using FDS, at it is not clear how to use the FDS without conflict while BLE is running.

What is the best method to store these data?

Thanks!

[Marjeris Romero]

Hi,

For only a few bites you can write directly to the UICR of the chip.

Best regards,

Marjeris

[StefXinet]

Thanks,

I supposed to do something like that. Is it possible to read and write UICR while the SD is running?

I can't find the SD API to read and write the CUSTOMER[x] UICR.

Thanks.

[Marjeris Romero]

Hi again,

Usually you will write data that will not need to be updated in runtime e.g. product serial number just needs to be written once.

[StefXinet]

This is clear, but what if I need to write something on CUSTOMER[x] UICR at runtime?

If it is not suggested to use FDS while BLE is running, and UICR at runtime, where should I save my few data?

[mrono]

StefXinet said:

If it is not suggested to use FDS while BLE is running, and UICR at runtime, where should I save my few data?

You can use FDS while BLE is on, that is not a problem. The BLE peer manager uses FDS to save some data, but you can also use the same FDS to save your data. The FDS library handles that easily.

So for things that are written during production and never change, use UICR. For anything else nonvolatile, use FDS.

[StefXinet]

mrono said:

You can use FDS while BLE is on, that is not a problem.

Thanks. we already tried to use FDS while using BLE, but unfortunatly its not working.

We opened few threads months ago (this is a public one), but there were no way to read and write data with FDS + BLE + SD + FreeRTOS without hardfault handler.

[mrono]

I think trying to get FDS to work would be your best option. Otherwise you'd need to implement something entirely custom, and that sounds like more work than troubleshooting the FDS part of your application.

For the specific issue you linked to: Your FDS handler will be called for all FDS events, even those coming from the peer manager. That is simply how the observer implementation is designed. In your handler you need to check if this event is from your own code or from the peer manager. The peer manager uses a specific range of file id:s and record keys. Those can be used to check if the event is from the peer manager.

[StefXinet]

mrono said:

Your FDS handler will be called for all FDS events, even those coming from the peer manager.

yes, I understood

mrono said:

In your handler you need to check if this event is from your own code or from the peer manager.

Please could you give me some hint? the documentation is not so clear and I cannot understand how to make this check

mrono said:

The peer manager uses a specific range of file id:s and record keys. Those can be used to check if the event is from the peer manager.

I walked over the library and I can see that this check is made inte the pm routines, but I cant figure out how to register a new FDS user, and how to filter the events in my own FDS code.

Thanks!

[mrono]

StefXinet said:

Please could you give me some hint? the documentation is not so clear and I cannot understand how to make this check

Here is a link to the FDS usage documentation. (FDS usage) Notice that the event handler gets a pointer to an fds_evt_t as an argument. That FDS event structure tells you which file id was written. So use that to tell if the file id is one you defined yourself, or if it is within the range used by the peer manager.

StefXinet said:

I cant figure out how to register a new FDS user

If you have a callback that is getting called when FDS events occur then you must have registered it. Anyhow, it is simply fds_register(name_of_callback).