Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Susheel Nuguru — Mon, 04 Mar 2024 08:17:04 GMT

No,, I do not think bool can be guaranteed to be atomic in multi context access and Yes, you should use one of the many atomic features provided by Zephyr or nRF.

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Thu, 29 Feb 2024 12:15:35 GMT

Hi Susheel,

Thanks for the advice. Reading and writing a bool flag isn't atomic? Should I use an nrf_atomic_flag or something like that?

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Susheel Nuguru — Thu, 29 Feb 2024 11:36:56 GMT

That is a nice workaround to call pm_peer_delete inside pm_peers_delete and delete the peer one by one. Just be careful on how you are waiting for the PM_EVT_PEER_DELETE_SUCCEEDED event. If you are using a wait for a flag condition then you might introduce a race condition since this flag is accessed in two different interrupt contexts (mostly main and SWI interrupt context where you process SD events).

[quote user="Federico"]If the issue happens again I'll try to port to SDK17 and report the results.[/quote]

Got it.

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Tue, 27 Feb 2024 13:04:27 GMT

Hi susheel,

This is an older project, that's why we are on an old SDK version. We could port it to SDK17 but porting it to Connect SDK would be a massive change and we don't have the resources to do that now.

I tried a different approach: I reimplemented pm_peers_delete myself, calling pm_peer_delete one at a time, waiting for PM_EVT_PEER_DELETE_SUCCEEDED before calling it again. This got rid of the re-entry and seems to work just fine.

If the issue happens again I'll try to port to SDK17 and report the results.

Thanks

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Susheel Nuguru — Tue, 27 Feb 2024 08:03:42 GMT

Hi Federico,

nRF5SDK is deprecated and there is a lot of hesitation by developers when asking for help debugging for potential issues. I am testing on nRF5SDK v17.1 and will not spend time on older versions(v15.x) of already deprecated sdk..I took some time to modify and setup a multilink peripheral and I can the repeated log but I did not manage to reproduce the bonds not being erased. After I get PM_EVT_PEERS_DELETE_SUCCEEDED I start a timer and soft reset the chip after 1 second. I do not see any connections or bonds after. I have to admit that I have only tested this with 4 peers.

Is it possible for you to test your application with nRF5SDKv17 libraries (some porting will be needed)

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Mon, 26 Feb 2024 20:26:38 GMT

Hi again, I'm struggling here to find the cause. I did a new test with lot's of prints and got this:

[00:02:13.601,745] <info> app: Total of 4 devices bonded
    conn_handle=65535, connected=0, rank=00001, peer_id=00000, mac=6E:12:A4:23:BC:10
    conn_handle=65535, connected=0, rank=00002, peer_id=00001, mac=FC:16:7D:1A:5C:71
    conn_handle=00001, connected=1, rank=00003, peer_id=00002, mac=E8:0D:A1:A1:E4:B6
>>> conn_handle=00002, connected=1, rank=65535, peer_id=00003, mac=48:51:C5:35:87:4C

[00:02:28.329,711] <info> app: Restarted advertising.
[00:00:00.000,000] <info> app_timer: RTC: initialized.
[00:00:00.311,340] <info> app: BLEP nRF v1.7 started.
[00:00:00.311,340] <info> app: Starting auto DFU timeout.
[00:00:00.311,401] <info> app: Erase bonds!
[00:00:00.311,431] <info> peer_manager: current_peer_id = 0
[00:00:00.311,492] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.312,164] <info> peer_manager_pds: Deleting file 49152 for peer 0
[00:00:00.312,194] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.312,194] <info> peer_manager: current_peer_id = 1
[00:00:00.312,225] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.312,774] <info> peer_manager_pds: Deleting file 49152 for peer 0
[00:00:00.312,774] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.312,805] <info> peer_manager: current_peer_id = 2
[00:00:00.313,018] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.313,568] <info> peer_manager_pds: Deleting file 49152 for peer 0
[00:00:00.313,568] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.313,598] <info> peer_manager: current_peer_id = 3
[00:00:00.313,629] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.313,873] <info> peer_manager_pds: File deleted: 49152
[00:00:00.314,117] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.314,147] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.314,483] <info> peer_manager_pds: Deleting file 49153 for peer 1
[00:00:00.314,483] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.314,880] <info> peer_manager_pds: File deleted: 49152
[00:00:00.315,124] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.315,155] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.315,490] <info> peer_manager_pds: Deleting file 49153 for peer 1
[00:00:00.315,521] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.315,887] <info> peer_manager_pds: File deleted: 49152
[00:00:00.316,131] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.316,162] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.316,497] <info> peer_manager_pds: Deleting file 49153 for peer 1
[00:00:00.316,528] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.317,443] <info> peer_manager_pds: old peer id = 0, new peer id = 1
[00:00:00.317,474] <info> peer_manager_pds: old peer id = 1, new peer id = 2
[00:00:00.317,504] <info> peer_manager_pds: old peer id = 2, new peer id = 3
[00:00:00.317,901] <info> peer_manager_pds: old peer id = 3, new peer id = 65535
[00:00:00.317,932] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.318,572] <info> peer_manager_pds: File deleted: 49153
[00:00:00.319,000] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.319,030] <info> peer_manager_handler: All peers deleted.
[00:00:00.319,213] <info> app: Total of 0 devices bonded
[00:00:00.319,427] <info> app: Peers deleted complete result=1
[00:00:00.319,671] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.319,702] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.320,068] <info> peer_manager_pds: File deleted: 49153
[00:00:00.320,098] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.320,312] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.320,343] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.320,709] <info> peer_manager_pds: File deleted: 49153
[00:00:00.320,739] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.320,983] <info> peer_manager_pds: Enter peer_data_delete_process
[00:00:00.320,983] <info> peer_manager_pds: Exit peer_data_delete_process
[00:00:00.321,380] <info> app: Total of 0 devices bonded
[00:00:00.000,000] <info> app_timer: RTC: initialized.
[00:00:00.312,255] <info> app: BLEP nRF v1.7 started.
[00:00:00.312,255] <info> app: Starting auto DFU timeout.
[00:00:00.312,500] <info> app: Total of 2 devices bonded
    conn_handle=65535, connected=0, rank=00003, peer_id=00002, mac=E8:0D:A1:A1:E4:B6
    conn_handle=65535, connected=0, rank=00004, peer_id=00003, mac=48:51:C5:35:87:4C
[00:00:00.320,159] <info> app: Stop Peripheral Role order
[00:00:00.000,000] <info> app_timer: RTC: initialized.
[00:00:00.311,706] <info> app: BLEP nRF v1.7 started.
[00:00:00.311,737] <info> app: Starting auto DFU timeout.
[00:00:00.311,981] <info> app: Total of 2 devices bonded
    conn_handle=65535, connected=0, rank=00003, peer_id=00002, mac=E8:0D:A1:A1:E4:B6
    conn_handle=65535, connected=0, rank=00004, peer_id=00003, mac=48:51:C5:35:87:4C
[00:00:00.758,148] <info> app: Init Peripheral Role order
[00:00:00.758,819] <info> app: Fast advertising.
[00:00:00.758,850] <info> app: Stopping auto DFU timeout.

My focus is on the peer_data_delete_process function. So I added prints like "Enter peer_data_delete_process" and "Exit peer_data_delete_process". From that I was able to learn that peer_data_delete_process is being called concurrently, from peer_data_storage.c::fds_evt_handler, in FDS_EVT_DEL_FILE. I'm guessing this reentry is part of the design because I can't see any way intention to prevent it.

I also added prints like "Deleting file 49152 for peer 0" when peer_data_delete_process() calls fds_file_delete() and "File deleted: 49152" on the FDS_EVT_DEL_FILE event. When peer_data_delete_process() iterates over peer ids by calling "peer_id = peer_id_get_next_deleted(peer_id);" I added a print like this: "NRF_LOG_INFO( "old peer id = %u, new peer id = %u", bk_peer_id, peer_id );"

From what I can see, the loop in pm_peers_delete that calls pm_peer_delete on each peer doesn't wait for the previous one to finish deletion, so when this eventually calls peer_data_delete_process, it searches for the first id to delete and calls for deletion on the same id several times. This explains the repeated events that I get later.

However, I don't understand why sometimes peer_data_delete_process will call fds_file_delete for every file and sometimes it will stop early. The call after an FDS_EVT_DEL_FILE should keep the state machine going, but for some reason I guess that peer_id_get_next_deleted is returning PM_PEER_ID_INVALID.

Any suggestions on how to fix this or debug it?

Thank you!

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Mon, 26 Feb 2024 14:51:30 GMT

Is it possible that you have been adding and deleting single peers before deleting all peers and before any garbage collection is done in between?

We don't delete peers individually, we only call pm_peers_delete(). Right before calling pm_peers_delete, the nRF has been reset, as I explained in the original post. I can guarantee that no new pairings are created in the time between the reset and call to pm_peers_delete, but it is possible a new one is created a few seconds before the reset. Can this be an issue? Is there any way to call the the garbage collector manually?

From what you say, I understand that the ordering of the numbers and the known issue are unrelated to my problem. What I'm seeing is that in peer_data_delete_process(), at some point peer_id_get_next_deleted returns an incorrect value. It either skips a peer or returns 0xFFFF and the deletion stops early, both cases leaving undeleted peers. What can cause this?

One last extra question:

But we cannot do this in our official release as nRF5SDK are frozen/deprecated and no patches or features will be done for nRf5SDK based solutions

I thought this SDK was in maintenance mode, doesn't that mean that you make bugfixes?

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Susheel Nuguru — Mon, 26 Feb 2024 06:38:19 GMT

As mentioned here the event is called when pm_peers_delete or internal cleanup. is done.

By internal cleanup it means that peer manager need to call fds_gc for garbage collection. Garbage collection is a complex process and it depends on what has happened before doing delete all peers. Is it possible that you have been adding and deleting single peers before deleting all peers and before any garbage collection is done in between?

Regarding the ordering of the numbers, I think it might have to do with the rank of the bond in the peer manager.. If all the bonds are deleted at the end, then I think it should be ok to have a different order of execution of deleting peers.

There is a wrong order in the above logs

[00:00:00.322,052] <info> peer_manager_handler: All peers deleted.
[00:00:00.322,265] <info> app: Total of 0 devices bonded
[00:00:00.322,479] <info> app: Peers deleted complete result=1
[00:00:00.322,998] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.323,028] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.323,547] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.323,547] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1

This we know as a known issue in how we handle the last peer delete. The last two events needs swapping so that the _PEERS_DELETE_ event marks the end of the procedure.

To do this we need to patch peermanager.c::pm_pdb_evt_handler by adding

+ evt_send(&pm_evt);

+ send_evt = false;

before the evt_send(&pm_delete_all_evt) call in the PDB_EVT_PEER_FREED and PDB_EVT_PEER_FREE_FAILED cases.

But we cannot do this in our official release as nRF5SDK are frozen/deprecated and no patches or features will be done for nRf5SDK based solutions. So if you want to use this sdk, you need to maintain this patch internally in your repos.

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Fri, 23 Feb 2024 14:09:40 GMT

Some more info: from inside pm_peers_delete, it seems that the loop actually calls pm_peer_delete on every id, but then I don't get events for all of them, some IDs are ignored and some produce multiple events

[00:00:00.311,218] <info> app: Total of 8 devices bonded
    conn_handle=65535, connected=0, rank=00001, peer_id=00000, mac=F9:16:2F:06:FE:19
    conn_handle=65535, connected=0, rank=00002, peer_id=00001, mac=35:5E:65:84:99:1D
    conn_handle=65535, connected=0, rank=00003, peer_id=00002, mac=93:E3:E3:71:9C:A3
    conn_handle=65535, connected=0, rank=00004, peer_id=00003, mac=9B:5C:83:08:E4:21
    conn_handle=65535, connected=0, rank=00005, peer_id=00004, mac=74:EA:EC:DE:CF:11
    conn_handle=65535, connected=0, rank=00006, peer_id=00005, mac=1A:13:B9:69:C1:B2
    conn_handle=65535, connected=0, rank=00007, peer_id=00006, mac=3C:FB:4A:AD:DF:40
    conn_handle=65535, connected=0, rank=00008, peer_id=00007, mac=48:51:C5:35:87:4C
[00:00:00.315,155] <info> app: Erase bonds!
[00:00:00.315,155] <info> peer_manager: current_peer_id = 0
[00:00:00.315,460] <info> peer_manager: current_peer_id = 1
[00:00:00.315,582] <info> peer_manager: current_peer_id = 2
[00:00:00.315,917] <info> peer_manager: current_peer_id = 3
[00:00:00.316,040] <info> peer_manager: current_peer_id = 4
[00:00:00.316,375] <info> peer_manager: current_peer_id = 5
[00:00:00.316,711] <info> peer_manager: current_peer_id = 6
[00:00:00.316,864] <info> peer_manager: current_peer_id = 7
[00:00:00.317,504] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.317,504] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.318,145] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.318,176] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.318,817] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.318,847] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.319,488] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.319,488] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.322,021] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.322,021] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.322,052] <debug> peer_manager_handler: Event PM_EVT_PEERS_DELETE_SUCCEEDED
[00:00:00.322,052] <info> peer_manager_handler: All peers deleted.
[00:00:00.322,265] <info> app: Total of 0 devices bonded
[00:00:00.322,479] <info> app: Peers deleted complete result=1
[00:00:00.322,998] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.323,028] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.323,547] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.323,547] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.000,000] <info> app_timer: RTC: initialized.
[00:00:00.273,284] <debug> nrf_ble_lesc: Initialized nrf_crypto.
[00:00:00.273,315] <debug> nrf_ble_lesc: Initialized nrf_ble_lesc.
[00:00:00.273,315] <debug> nrf_ble_lesc: Generating ECC key pair
[00:00:00.311,401] <info> app: BLEP nRF v1.7 started.
[00:00:00.311,401] <info> app: Starting auto DFU timeout.
[00:00:00.311,645] <info> app: Total of 6 devices bonded
    conn_handle=65535, connected=0, rank=00003, peer_id=00002, mac=93:E3:E3:71:9C:A3
    conn_handle=65535, connected=0, rank=00004, peer_id=00003, mac=9B:5C:83:08:E4:21
    conn_handle=65535, connected=0, rank=00005, peer_id=00004, mac=74:EA:EC:DE:CF:11
    conn_handle=65535, connected=0, rank=00006, peer_id=00005, mac=1A:13:B9:69:C1:B2
    conn_handle=65535, connected=0, rank=00007, peer_id=00006, mac=3C:FB:4A:AD:DF:40
    conn_handle=65535, connected=0, rank=00008, peer_id=00007, mac=48:51:C5:35:87:4C

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Federico — Fri, 23 Feb 2024 12:57:23 GMT

Hi, thanks for the quick answer.

I can't share the full project, but maybe I can share some small relevant pieces. For example, I know that we call this function once, which registers the callback:

static void peer_manager_init( void )
{
	ble_gap_sec_params_t sec_params;
	ret_code_t err_code;

	err_code = pm_init();
	APP_ERROR_CHECK( err_code );

	/** Security configuration shall be set in each role implementation.*/

	err_code = pm_register( pm_evt_handler );
	APP_ERROR_CHECK( err_code );
}

This is the callback implementation:

static void pm_evt_handler( pm_evt_t const * p_evt )
{
	pm_handler_on_pm_evt( p_evt );
	pm_handler_disconnect_on_sec_failure( p_evt );
	pm_handler_flash_clean( p_evt );


	switch ( p_evt->evt_id ) {
	case PM_EVT_CONN_SEC_START:
		break;
		
	case PM_EVT_CONN_SEC_PARAMS_REQ:
	    // under some conditions might call
	    // pm_peer_id_get( conn_handle, &m_peer_to_be_deleted );
	    // sd_ble_gap_disconnect( conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION );
	    break;
	    
	case PM_EVT_CONN_SEC_CONFIG_REQ:
	    pm_conn_sec_config_t config = { .allow_repairing = true };
		pm_conn_sec_config_reply( p_evt->conn_handle, &config );
		break;
		
	case PM_EVT_CONN_SEC_FAILED: 
	    // Under some conditions might call
		// pm_conn_secure( p_evt->conn_handle, true );
		break;

	case PM_EVT_CONN_SEC_SUCCEEDED:
        //....
		break;

	case PM_EVT_PEER_DATA_UPDATE_SUCCEEDED:
		if ( new_bonding_data_storage_pending && p_evt->params.peer_data_update_succeeded.data_id == PM_PEER_DATA_ID_BONDING ) {
			print_bonded_devices( p_evt->peer_id );
		}
		break;

	case PM_EVT_PEERS_DELETE_SUCCEEDED:
	case PM_EVT_PEERS_DELETE_FAILED:
		print_bonded_devices( PM_PEER_ID_INVALID );
		NRF_LOG_INFO( "Peers deleted complete result=%u", p_evt->evt_id == PM_EVT_PEERS_DELETE_SUCCEEDED );
		// send spi msg
		break;

	case PM_EVT_STORAGE_FULL:
	case PM_EVT_ERROR_UNEXPECTED:
	case PM_EVT_PEER_DATA_UPDATE_FAILED:
	case PM_EVT_BONDED_PEER_CONNECTED:
	case PM_EVT_PEER_DELETE_SUCCEEDED:
	case PM_EVT_PEER_DELETE_FAILED:
	case PM_EVT_LOCAL_DB_CACHE_APPLIED:
	case PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED:
	case PM_EVT_SERVICE_CHANGED_IND_SENT:
	case PM_EVT_SERVICE_CHANGED_IND_CONFIRMED:
	case PM_EVT_SLAVE_SECURITY_REQ:
	case PM_EVT_FLASH_GARBAGE_COLLECTED:
	case PM_EVT_FLASH_GARBAGE_COLLECTION_FAILED:
	default:
		break;
	}

}

I don't see any other repeated log messages from the Peer Manager. The repeated events also seem to be a few milliseconds apart, so perhaps it's not that the callback is being called twice on the same event and rather it's that the event is being generated twice?

If you have an idea of anything you want to try let me know and I can do it

Thanks!

EDIT: I added a print in fds_evt_handler, in the FDS_EVT_DEL_FILE event. I was able to confirm that the event is being generated many times, as you can see here:

[00:00:00.321,472] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.321,502] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.322,296] <info> peer_manager_pds: FDS DELETED PEER: 0
[00:00:00.322,357] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.322,387] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.323,181] <info> peer_manager_pds: FDS DELETED PEER: 0
[00:00:00.323,242] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.323,242] <error> peer_manager_handler: Peer deleted successfully: peer_id: 0
[00:00:00.325,744] <info> peer_manager_pds: FDS DELETED PEER: 1
[00:00:00.325,775] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.325,805] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.326,538] <info> peer_manager_pds: FDS DELETED PEER: 1
[00:00:00.326,568] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.326,599] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.327,331] <info> peer_manager_pds: FDS DELETED PEER: 1
[00:00:00.327,392] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.327,392] <error> peer_manager_handler: Peer deleted successfully: peer_id: 1
[00:00:00.329,833] <info> peer_manager_pds: FDS DELETED PEER: 4
[00:00:00.330,078] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.330,108] <error> peer_manager_handler: Peer deleted successfully: peer_id: 4
[00:00:00.330,902] <info> peer_manager_pds: FDS DELETED PEER: 4
[00:00:00.331,146] <debug> peer_manager_handler: Event PM_EVT_PEER_DELETE_SUCCEEDED
[00:00:00.331,146] <error> peer_manager_handler: Peer deleted successfully: peer_id: 4
[00:00:00.331,939] <info> peer_manager_pds: FDS DELETED PEER: 4

RE: Can't erase peers: PM_EVT_PEERS_DELETE_SUCCEEDED event is raised but bondings remain.

Susheel Nuguru — Fri, 23 Feb 2024 12:23:58 GMT

I have not seen this before, seems like there are multiple calls to pm_evt_handler for a single erase of bond information.

Can you share your application code that I can test on the nRF52840 DK?