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?

[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.