What is the right way to deal with NRF_ERROR_BUSY in a complex multirole application under FreeRTOS?

[peter_100P]

I'm developing a central that may have to service more than one peripheral concurrently while (occasionally) advertising its own peripheral service. Things seem to work OK under FreeRTOS, but on occasion I still run into the dreaded NRF_ERROR_BUSY when I try to initiate certain actions in response to events.

What is the preferred architecture to deal with this? Is there some kind of built-in asynchronous "queue with retry"? Or do I have to roll my own?

[Einar Thorsrud]

Hi,

Generally many functions can return NRF_ERROR_BUSY if for instance the requested operation is not possible before an existing operation has completed. In most cases it makes sense to try again at a later point, for instance when the current operation has completed. To be more specific I need to know which function returned NRF_ERROR_BUSY.

[peter_100P]

Example: sd_ble_gattc_primary_services_discover returns NRF_ERROR_BUSY with some peripherals, unless I call it after I receive BLE_GATTC_EVT_EXCHANGE_MTU_RSP.

[Einar Thorsrud]

Yes. If you look at the API documentation for sd_ble_gattc_primary_services_discover() it states that NRF_ERROR_BUSY is returned when a "Client procedure already in progress."

Please note that there is no generic way to handle this or most other return values other than RNF_SUCCESS. You need to understand the API of the functions you call and handle the possible return values. Any unhandled values will typically be caught by an APP_ERROR_CHECK and lead to a reset, as a last resort way of recovering from unhandled errors.

[peter_100P]

Does the Soft Device have an API that returns "busy" or "operation in progress"? Seems like a shot in the dark without something like this.

[Einar Thorsrud]

Yes, many API functions can return NRF_ERROR_BUSY. In many cases this would normally never happen, and in that case using APP_ERROR_CHECK is sensible, to recover from something that should not happen. In others, it is expected form time to time. You can typically see this from the API documentation of the SoftDevice, where most of the return values are documented.

[peter_100P]

That wasn't my question. Let me rephrase: Can I interrogate the SD somehow to know if it has pending operations and thus expected to return NRF_ERROR_BUSY if I try something next?

[Einar Thorsrud]

Aha, I see. No, that is not possible.