PEER saved event

RE: PEER saved event

hossein_m — Tue, 10 Mar 2020 08:44:24 GMT

I guess setting a timer is my only option since we don't know what event comes last.

Thank you for your help

RE: PEER saved event

Vidar Berg — Tue, 10 Mar 2020 08:26:05 GMT

Hi,

You can see from the debug log which update events you get during a bonding procedure if you set the NRF_LOG_DEFAULT_LEVEL config option to '4' (Debug). Here's from the ble_app_hrs example:

<info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0 bond=0x1 lv4: 0 kdist_own:0x3 kdist_peer:0x2
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update

However, I'm not sure if the central address resolution is always going to come last. It may depend on the peer device. Would it be an option to use a timer,etc to delay the reset until a few seconds after the last PM update event?

RE: PEER saved event

hossein_m — Tue, 10 Mar 2020 07:16:22 GMT

Hi,
Thank you for you reply

Yes that is the plan.

Are you saying I can restart the chip when fstorage is not busy after receiving PM_EVT_PEER_DATA_UPDATE_SUCCEEDED with right pm_peer_data_id_t?
Which pm_peer_data_id_t value should I look for?

RE: PEER saved event

Vidar Berg — Mon, 09 Mar 2020 14:18:34 GMT

Hello,

The event information for the 'PM_EVT_PEER_DATA_UPDATE_SUCCEEDED' event reported to your registered peer manager callback includes the data id (from pm_peer_data_id_t enum) that you can use to determine what was updated by the PM. You can also use nrf_fstorage_is_busy() to check if there are pending flash operations. Is the plan to intentionally restart the device after completed bonding procedures?