fatal error in the BLE observers

RE: fatal error in the BLE observers

Karl Ylvisaker — Mon, 25 Oct 2021 13:12:23 GMT

Hello null handle,

I am glad to hear that you were able to resolve the issue yourself so quickly. Thank you for sharing your solution here with us along with the discussion you found useful, so that other forum goers may see it in the future! :)

For the record, it is very helpful to make sure that you have DEBUG defined in your preprocessor defines, like shown in the included image, in order to have the logger output a detailed error message whenever a non-NRF_SUCCESS error is passed to an APP_ERROR_CHECK. This makes the debugging of failed sd_ and nrfx_ function calls much easier.

Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl

RE: fatal error in the BLE observers

null handle — Mon, 25 Oct 2021 00:58:21 GMT

I am implementing BLE bonding on my nRF52840 DK, which uses the S140 Softdevice. The DK is a peripheral and I'm using version 17.1 of the SDK. I adapted most of the peer_manager/whitelist code from the ble_peripheral hci keyboard sample. However, I'd like to implement some special logic to allow only the first device to be bonded with my nRF52840 to talk to it, and to reject pairing/bonding attempts from other devices.

So I made this waaaaay more complicated than it needed to be. I would up implementing this feature by:

In my advertising_init, setting init.config.ble_adv_whitelist_enabled to true
In my peer_manager event handler, I handled the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event to add the new peer to my whitelist.
In my advertising event handler, handled the BLE_ADV_EVT_WHITELIST_REQUEST event to send a ble_advertising_whitelist_reply().

This works because the advertising module disregards the whitelist when the whitelist is empty. This allows the first central device to make the connection, pair/bond, and get added to the peer list. This trips PM_EVT_PEER_DATA_UPDATE_SUCCEEDED and gets the new peer added to the whitelist. Now that the whitelist is nonempty, when advertising resumes it will get used, preventing other central devices from connecting. Using my reset button will clear my bond and whitelist data and put advertising back into its initial state.

I found this discussion useful: devzone.nordicsemi.com/.../whitelist-set-but-not-automatically-restarted

RE: fatal error in the BLE observers

null handle — Sat, 23 Oct 2021 19:58:33 GMT

I seem to have gotten rid of my APP_ERROR. But I am still having problems detecting when I've already entered a central device to the whitelist at the BLE connected event message level.

I take the address in p_ble_evt->evt.gap_evt.params.connected.peer_addr and check it against the contents of the whitelist_addrs returned by pm_whitelist_get(). My central device sends the same peer_addr every time, but that's not what I see in the whitelist.

I set the whitelist with the results of a call to pm_peer_id_list() in the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event. The peer_id is a unsigned 16-bit number.

How can I take a ble_gap_add_t and map it to whatever is in the whitelist?