sd_ble_gattc_read() consecutive calls returns NRF_ERROR_BUSY

RE: sd_ble_gattc_read() consecutive calls returns NRF_ERROR_BUSY

Amanda Hsieh — Tue, 01 Feb 2022 12:09:37 GMT

Hi,

I got some input from the team.

NRF_ERROR_BUSY returned by sd_ble_gattc_read means Client procedure is already in progress. In your case, it should mean that sd_ble_gattc_read is called before event for the previous procedure is fetched from SD. Our guesses:

something messed up with locking/unlocking in ble_c_device_read
app initiate some other procedure in parallel

Delay is not required, sd_ble_gattc_read can be called immediately after sd_ble_evt_get returns NRF_SUCCESS and event that finishes the previous procedure.

-Amanda

RE: sd_ble_gattc_read() consecutive calls returns NRF_ERROR_BUSY

Davide Ghisalberti — Mon, 31 Jan 2022 09:15:18 GMT

I see, but in the sequence chart there is no indication about delays or the value of them.

For clearing, each call of my "ble_c_device_read" accounts for the call of "sd_ble_gattc_read" and waits for BLE_GATTC_EVT_READ_RSP before performing another call to sd_ble_gattc_read.

Are there some suggested delay or it's an empyrical value to be found for our application? There are some better documented indication about that? Thanks

RE: sd_ble_gattc_read() consecutive calls returns NRF_ERROR_BUSY

Amanda Hsieh — Mon, 31 Jan 2022 08:42:35 GMT

Hi,

You should follow the flow in this message sequence chart with delay. See this post.

Regards,
Amanda