Inconsistency in peer_manager

Question

Hello, 
 I have a small test BLE peripheral application with a few functions I can invoke over a UART dialog. With one function, I can print the first peer in the peer manager, by calling pm_next_peer_id_get() and then retrieve the details of the bond using pm_peer_data_bonding_load(). With an other function, I can invoke pm_peers_delete(). With a third function, I can set previously stored bonding data, using pm_peer_new(). 
 My test procedure goes like this: 
 - Bond the device to a GATT client 
 - store that bonding information to somewhere 
 - Delete the bond information 
 - Reset the device 
 - add previously stored bonding information, using pm_peer_new() 
 - Print existing bonding information (pm_next_peer_id_get() / pm_peer_data_bonding_load()) 
 In the last step, pm_next_peer_id_get() returns a peer ID, with is not PM_PEER_ID_INVALID. However, pm_peer_data_bonding_load() returns NRF_ERROR_NOT_FOUND. I know, that the bonding data is not available shortly after it was inserted into the database. But I can wait for minutes between the call to pm_peer_new() and pm_peer_data_bonding_load() and this delay does not solve the inconsistency. 
 What could be the reason for the inconsistency? 
 best regards, 
 Torsten 
 I haven't found any examples of the usage of pm_peer_new() in the SDK examples. SDK version is 16.0.0, SD is S113. All return values to SDK function calls are systematically checked.

Edvin · Accepted Answer

Torsten Robitzki said: yes, I’ve checked that I’m not waiting busy anywhere. The test application receives commands asynchronously though an UART. So „waiting" mean, I sit in front of the terminal and wait until I send the command to execute a next test step. 
 I am not sure you read the text I quoted now. 
 "If you are not waiting within an interrupt, then perhaps you are not able to store the peer information because you are in a connected state with a too short connection interval. If so, then the softdevice will not be able to schedule the FDS writes. To check if this is the issue, you can try to store the peer data, then disconnect and wait a few ms before you try to read it back out." 
 What is the connection interval you are using? If you are connected to a phone, then you can't really control this, since it is always the central that decides the connection interval. If you are connected with a very short connection interval, you can wait as long as you like, but the softdevice doesn't have time to perform any flash operations. Perhaps you can try to disconnect the phones BLE. 
 
 Torsten Robitzki said: Directly after the attempt to store bonding information (using pm_peer_new()), the test application starts advertising. A comment in peer_manager_handler.c regarding PM_EVT_PEER_DATA_UPDATE_FAILED says: "This can happen if the SoftDevice is too busy with BLE operations.“. Could this be a problem? 
 Yes, this is exactly what I meant by the quoted test. In fact, a quite common thing to do is to store the bonding information in the disconnect event, because at this point, you will not be busy using the softdevice. Perhaps you can try to call pm_peer_new() from the disconnected event before you start advertising again? 
 
 Torsten Robitzki said: I did a quick test and it seems that this internal error does not occur, when I wait after adding the bonding data before starting advertising???!!! This looks very weird. Is this expected behavior? 
 Yes. 
 
 Best regards, 
 Edvin

Inconsistency in peer_manager

Top Replies