pm_peer_data_bonding_load not finding the data (error code 5)

[Alex Crombie]

We have a device (in central mode) initiating a secure connection to a peripheral (slave) via the usage of `pm_conn_secure(conn_handle, false)`. This results in a `PM_EVT_CONN_SEC_SUCCEEDED` event being generated by the peer manager.

Checking the status of the bond in `p_evt->params.conn_sec_succeeded.data_stored` and `p_evt->params.conn_sec_succeeded.procedure` results in a true value and `PM_CONN_SEC_PROCEDURE_BONDING` respectively.

Furthermore when checking the status of the connection via `pm_conn_sec_status_get` the values returned are connected:true, encrypted:true, mitm_protection:false, bonded:true

At this point we try to retrieve the bonding information from the peer manager via `pm_peer_data_bonding_load` using `p_evt->peer_id` (which has a value 0, i.e. not invalid) however the `pm_peer_data_bonding_t` structure is filled with 0s and the return from the function is 5 (which I believe is NRF_ERROR_NOT_FOUND).

All of the calls are performed from within the callback from the peer_manager event handler associated with `PM_EVT_CONN_SEC_SUCCEEDED`.

What is the correct way to retrieve the stored bonding information?

I could not add tags for the following so mentioning the crucial versions here. We are using the following:

SDK 15.0.0

SoftDevice S132 V6.0.0

[Hung Bui]

Hi Alex, 

When you received PM_EVT_CONN_SEC_SUCCEEDED event, what the peer_id was ? 

I'm not sure why you receive NOT_FOUND return, but could you try to do a read after some delay ? There could be a chance that the flash store command is not executed by the softdevice (even though data_stored = 1). You can try doing the bond read after the DISCONNECTED event, it should return the correct bond information. 

[Alex Crombie]

I have tested adding a delay before retrieving the bonding information and this does indeed eventually result in the bonding information being present.

As per my previous comment is there a fix in a subsequent SDK/SoftDevice?

Is there a reason the bonding information cannot be returned sooner?

[Hung Bui]

Thanks for the update. The way the fds works is that fds has a queue and data_stored=1 in PM_EVT_CONN_SEC_SUCCEEDED only tell the the flash store command is queued, not executed. 

Could you try catching PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event and read the bond information at that event instead ? I think it's the proper way of doing it. The event is valid for both updating peer data, and storing on the first time. 

[Alex Crombie]

Does the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event get generated on the `pm_peer_new()` and `pm_peer_data_bonding_store()` calls?

[Hung Bui]

From the code, it does get generated from that. (it's generated on FDS_EVT_WRITE, FDS_EVT_UPDATE, FDS_EVT_DEL_RECORD success events) 

[Alex Crombie]

That is very helpful, thank you.