sometimes ble_db_discovery_start never generates the callback

[pablitorun]

I have a client device that normally is able to call ble_db_discovery_start and get the callback just fine and is able to complete the db discovery process.  However sometimes I am never getting the call back generated.  Is there anyway to know that it failed in those cases? Any idea why the callback might never be generated?

[pablitorun]

The code i am running is based off nRF5_SDK_14.2.0_17b948a\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput

it includes a call to sd_ble_gap_phy_update immediately after a call to ble_db_discovery_start.  If I removed the phy update it seems to function 100% of the time.  Are there some timing constraints with how those two calls can be made?

[Håkon Alseth]

Hi,

 

What is likely happening is that you have two LL (link layer) requests pending (PHY update and service discovery), and the bluetooth core spec only allows one of these specific operations to be pending at the same time. The first LL request will then block the second called one, and the application will get a _BUSY err_code back.

If you are getting an error mid-process of reading the services (initial read has retry-functionality, but not sub-sequential reads) and you're likely getting a callback from the ble_db_discovery module with event BLE_DB_DISCOVERY_ERROR, which is not handled in the handler "nrf_ble_amtc_on_db_disc_evt". ideally, you want to retry (ie: continue) the discovery process when this error is reported back.

 

A quick workaround can be to send the PHY update at a later point (via a app_timer instance).

I'll ofcourse report this internally so that the SDK team is aware of this race-condition.

 

Best regards,

Håkon

 

[pablitorun]

Thanks for the reply.  That makes sense.  I worked around it this weekend by doing the inverse of your quick workaround and doing the db discovery after the phy update and all seemed well, same basic idea.