Peer manager and use of fds to store app settings in flash

[DimitrisP]

Hello

SDK = ver 17

DK = nRF52

Using Peer manager for writing peer data in flash and FDS to store app settings in flash.

1. They both share the same spcase in flash, defined by FDS_VIRTUAL_PAGES?

2. Must I handle GC for both cases (Peer manager and FDS)? The PM_EVT_STORAGE_FULL event covers only PM?

3. When GC runs covers both PM and FDS

3. Writes in both cases is asychronus. So can I use PM and FDS in the same time or should I wait ?

Dimitris

[Vidar Berg]

Hello,

I would recommend to work directly with the FDS as long as this application data that is not tied to a particular bond/peer in some way. I have put toghether a small demo based on the ble_app_hrs example to demonstrate how you can use FDS outside of the peer manager which included below.

1. Yes, correct. The same flash region is shared between all FDS users

2. GC is performed on the entire filesystem, so it does not matter if it is started by the application or by the peer manager.

3. Yes, as mentioned above, GC covers the whole file system.

Best regards,

Vidar

Example project

nRF5_SDK17.0.2_ble_app_hrs_fds_app.zip

[DimitrisP]

Hello

Thanks for the reply.

1.So GC can start from PM using PM_EVT_STORAGE_FULL and FDS can start CG using fds_stat function as you dercribe in your example. But what if lets say PM has started a GC and FDS using your run_gc request also wants to run a GC? Is it ok to check if there is an ongoing GC running and not start a second one? or I can have 2 ongoing at the same time?

2. Writes in both  cases (PM and FDS) is asychronus. So can I use PM and FDS at the same time or should I wait for an ongoing write or update to finish? I meen is it ok if I run a "pm_peer_data_app_data_store" function and before the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED I also execute a "fds_record_update"?

Dimitris

[Vidar Berg]

Hello,

1. The PM does not start GC until FDS has returned 'FDS_ERR_NO_SPACE_IN_FLASH' on either a write or update request, which should never happen if the application always run GC before FDS gets completely full. I don't think it would be a problem if 2 GC operations was requested simultaneously either.

2. Yes, all flash operations are queued internally in the FDS the module so the application does not have to worry about this. Completion of the requested task will be notified via the FDS callback.

Best regards,

Vidar

[DimitrisP]

'Hello

Ok I got it 

Thanks and one last. Can you please tell me a safe "GC_TRESHOLD" value taking in mind that the max amound of data that I want to write with fds is 10 bytes and that I write peer app data with "pm_peer_data_app_data_store" no more than 8 bytes. I guess  I want to now the size of data that PM use. (I use uart trasparent service, bat service and device information service with bonding)

BR

Dimitris

[Vidar Berg]

Hello Dimitris,

I don't recall the exact size of the different bonding records. You can monitor the FDS 'stats' to find out. However, I don't think it's neccesary to have the GC_TRESHOLD as low as possible. The key is to ensure that GC is always run ahead of time before you start getting the 'FDS_ERR_NO_SPACE_IN_FLASH' error. Otherwise you have to implement handling of this error in your application code.

Best regards,

Vidar