pc-ble-driver 1.0 - bonding

RE: pc-ble-driver 1.0 - bonding

Rick S. — Tue, 29 Aug 2017 22:54:24 GMT

P.S. This is the pc-ble-driver from July, don't know the version number

RE: pc-ble-driver 1.0 - bonding

Rick S. — Tue, 29 Aug 2017 21:41:31 GMT

Hi Mike, I know it's been a while since you asked this... :)

I got tripped up at the same point, sd_ble_gap_sec_params_reply was causing an assertion failure due to a recursive mutex lock.

I got around this by calling sd_ble_gap_sec_params_reply from the main thread instead of the event handler. (Main function calls Win32 WaitForSingleObject, handler calls SetEvent)

This seems like a bug to me, I haven't had a chance to make an official report.

Best of luck, Rick

RE: pc-ble-driver 1.0 - bonding

Jørgen Holmefjord — Wed, 11 Jan 2017 08:34:09 GMT

Could you upload your central code? If you don't want to share it in public, you can also create a case in MyPage and link to this case.

RE: pc-ble-driver 1.0 - bonding

Mike — Tue, 10 Jan 2017 08:19:00 GMT

@Jørgen Holmefjord This code is from my central device. I did not sniff on-air packets but I tracked what kind of events my peripheral receive during bonding attempt (the peripheral device is also my custom device nrf51-based, so I can debug it).

I found that the peripheral gets only BLE_GAP_EVT_SEC_PARAMS_REQUEST event, nothing more. So. it seems that the sd_ble_gap_sec_params_reply call on the central has no effect.

I just add, that the peripheral device bonds fine with nRF Connect app on the phone.

RE: pc-ble-driver 1.0 - bonding

Jørgen Holmefjord — Mon, 09 Jan 2017 14:35:15 GMT

This is on your peripheral? Have you tried performing a sniffer trace to see what is happening on-air?