What would happen if bonded peer data is corrupted?

[John_Doe]

Hi Nordic,

I am using SDK 12.3.0, S130 2.0.1 and PCA10028 nrf51 DK.

I would like to know what would happen in the following situation.

During central and peripheral pairing & bonding process by peer manager (especially during writing peer data into FDS), the power is cut.

I assume the bonded peer data would be corrupted. When the device is power up again, how do I know the data is corrupted and what should I do if the data is corrupted?

Thank you.

[Simon]

The Experimental: Flash Data Storage will prevent the application from accessing corrupted data, by executing validation on the data. If you click at the link provided, you will see the following comment:

"Minimizing the risk of accessing corrupted data by constant validation: In case of power loss, data might be written incompletely. Validation ensures that FDS recognizes invalid data and never returns corrupted data to the user."

Best regards,

Simon

[John_Doe]

Is there a way to identify corrupted data (for example the corrupted bonded data) and then erase these data?

[Simon]

The Flash Data Storage will write the data as records, and the written data will not be validated until it is completed. If a power loss happens in the middle of a write, you can simply run a Garbage collection, which will free the space used by invalidated records.

[John_Doe]

I am using ble_app_hrs_c as example for peer manager. From what I see in the code, fds_gc() is only called once when PM_EVT_STORAGE_FULL event is triggered. And I know calling pm_peers_delete() does not free the space.

Should I call fds_gc() every time I delete a bonding or following the example only called in PM_EVT_STORAGE_FULL event? Or put fds_gc() in main and perform garbage collection every start up?

[Simon]

In the documentation it says the  following about garbage collection:  "You should run garbage collection when BLE activity is low otherwise the operation might timeout." 

Therefore, I think a good solution would be to run garbage collection right before scanning starts, and fds_stat can be run right before to check if there are any "dirty" records in flash.