This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Graceful recovery from Bluetooth errors

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

Parents
  • 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.

Reply
  • 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.

Children
Related