• State Verified Answer
  • Replies 4 replies
  • Subscribers 73 subscribers
  • Views 853 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 245838
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

PEER saved event

hossein_m

Hello,

I am using NRF52840 with SDK 16. In my project I need to restart the chip after a successful pairing but I can't find any event that can make me sure about pairing being done and its data saved. I checked PM_EVT_CONN_SEC_SUCCEEDED and PM_EVT_PEER_DATA_UPDATE_SUCCEEDED however PM_EVT_CONN_SEC_SUCCEEDED happens before pairing data being saved and PM_EVT_PEER_DATA_UPDATE_SUCCEEDED happens many times during the procedure and I don't know if it's OK to restart the chip with this event.

So can you please tell me when can I be sure that the peer is saved successfully? is there another event in Peer manager that I can use or is there a way that I can know which PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event indicates that the peer saving procedure is completed correctly ?

thank you

Parents
  • 0

    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?  

  • 0 in reply to Vidar Berg

    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?

  • +1 in reply to hossein_m

    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?

Reply
  • +1 in reply to hossein_m

    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?

Children
Related
Terms of service