Graceful recovery from Bluetooth errors

[Daniel Reisfeld]

Hi,

After long use of BLE communication I sometimes get return code 8 from sd_ble_gatts_hvx.

My questions: 

1. This return code is cryptic. Is it associated with defined BLE communication scenarios?

2. What is the graceful way to handle critical error? How can the softdevice be rebooted without rebooting the whole processor?

Thanks,

Daniel

[Einar Thorsrud]

Hi,

1. This return code is cryptic. Is it associated with defined BLE communication scenarios?

Error code 8 is NRF_ERROR_INVALID_STATE. This is returned by sd_ble_gatts_hvx() in these situations (from API doc):

 * @retval ::NRF_ERROR_INVALID_STATE One or more of the following is true:
 *                                   - Invalid Connection State
 *                                   - Notifications and/or indications not enabled in the CCCD
 *                                   - An ATT_MTU exchange is ongoing

2. What is the graceful way to handle critical error?

This error likely occurred because of an invalid state in your application (see API doc snippet above), so the first thing you should do is try to avoid this from happening in the first place. Secondly, you can opt to handle the NRF_ERROR_INVALID_STATE by some specific code, instead of using the default error handler which is called when an APP_ERROR_CHECK is called with a value other than NRF_SUCCESS. It could be something like this:

    err_code = sd_ble_gatts_hvx(...);

    if (err_code == NRF_ERROR_INVALID_STATE)
    {
        // Application specific handling of NRF_ERROR_INVALID_STATE
    }
    else
    {
        // Default error check
        APP_ERROR_CHECK(err_code);
    }

How can the softdevice be rebooted without rebooting the whole processor?

It is possible to uninitialize the SoftDevice by first stopping all BLE activity, and then call sd_softdevice_disable(), and then call sd_softdevice_enable() to re-enable it. I do not see any good reason for doing so in this case though.

[awneil]

Einar Thorsrud said:

This is returned by sd_ble_gatts_hvx() in these situations

It is really bad and unhelpful - though all too common - to have a single error code with multiple meanings!

A particularly bad example of this is NRF_ERROR_INVALID_PARAM - which neither identifies which parameter is invalid, nor how it is invalid.

EDIT

From only the other week, see:

devzone.nordicsemi.com/.../192273

[Einar Thorsrud]

Hi,

Thank you for the feedback!

I agree that some of the return values from the SoftDevice cover too much, and NRF_ERROR_INVALID_PARAM  particularly so. I have reported this internally so that adding more error codes can be considered for future releases.

[awneil]

Another example today:

https://devzone.nordicsemi.com/f/nordic-q-a/48711/sd_ble_gap_scan_start-returns-0x6/193489#193489

[awneil]

Another today:

https://devzone.nordicsemi.com/f/nordic-q-a/51808/non-connectable-advertising-while-connected-on-sdk15-3/208629#208629

[awneil]

another today:

https://devzone.nordicsemi.com/f/nordic-q-a/52193/ble_db_discovery_start-returns-nrf_error_invalid_param-0x7/209895#209895

[awneil]

another today:

devzone.nordicsemi.com/.../213360