mesh_srv_char_val_set() generating an NRF_ERROR_INTERNAL

[ccarlotti]

I am porting th mesh protocol, on my existing service but when the smartdevice is start to connect to the NRF51822, the call to mesh_srv_char_val_set() generating an NRF_ERROR_INTERNAL. I don't know why ?

[trond-snekvik]

Hi, The error is likely generated by the call to sd_ble_gatts_hvx() at L428 in mesh_srv.c. Are you able to extract the error code from the call? Instead of reporting return NRF_ERROR_INTERNAL; at L441, you could do return error_code;, which is the error code that comes from the Softdevice. Come back to me with the error code, and we can continue to work this out. I'm afraid I can't be of much help without it, or a copy of your code.

[ccarlotti]

Hi, the returned error is "NRF_ERROR_INVALID_STATE". Thank you Charles

[trond-snekvik]

I think this could be related to this issue, where the smartphone doesn't register for notifications, leading to invalid state. We haven't had this problem during testing, but according to documentation, this should be a problem.

To confirm that this is what you're experiencing, you could try to enable notifications for the particular characteristic from your smartphone before you write to the characteristic, and see if the issue persists. While the invalid state will come up whenever the smartphone is not ready to receive notifications, the characteristic update will be safely stored in your local GATT server (as per the NOTE in the documentation), and the error can actually be safely ignored:

            else if (error_code != NRF_ERROR_INVALID_STATE)
            {
                return NRF_ERROR_INTERNAL;
            }

You could try to read the characteristic again (with rbc_mesh_value_get()) after the occurence to confirm that the value is updated.

[ccarlotti]

Hi, thank you for your help, now the connexion is OK, but when the disconnection is done an 0x3004 error occurs from sd_ble_gatts_hvx() when mesh_srv_char_val_set() i called.

Charles

[ccarlotti]

0x3004 is a NRF_ERROR_NO_MEM from the NRF_ERROR_STK_BASE_NUM 0x3000

[trond-snekvik]

Hi, sorry for the delay.

I didn't consider that one. The 0x3004 error on sd_ble_gatts_hvx() indicates that the Softdevice ran out of TX buffers, i.e. the application has queued up unsent notifications to the point where it can't keep all of them. I'm afraid I'm unable to reproduce it on my setup (SD8, SDK8, Android Nexus 5 w/Lollipop), but the following piece of code should be able to tackle the issue before it appears:

    ble_gatts_value_t cccd_val_struct;
    uint8_t cccd_val[2];
    cccd_val[0] = 0;
    cccd_val_struct.p_value = cccd_val;
    cccd_val_struct.len = 2;
    if (g_active_conn_handle != CONN_HANDLE_INVALID)
    {
        error_code = sd_ble_gatts_value_get(g_active_conn_handle, ch_md->char_value_handle + MESH_CCCD_HANDLE_OFFSET, &cccd_val_struct);
        if (error_code != NRF_SUCCESS)
        {
            if (error_code == BLE_ERROR_INVALID_CONN_HANDLE)
            {
                g_active_conn_handle = CONN_HANDLE_INVALID;
            }
            else if (error_code == BLE_ERROR_GATTS_SYS_ATTR_MISSING)
            {
                /* cccd hasn't been initiated yet, can assume it's not active */
                cccd_val[0] = 0;
            }
            else
            {
                return NRF_ERROR_INTERNAL;
            }
        }
    }

Try doing this before the if at line 422, then change that if-condition to:

    if (g_active_conn_handle != CONN_HANDLE_INVALID && cccd_val[0] != 0)

I've defined MESH_CCCD_HANDLE_OFFSET as (1).

This way, you'll read the cccd value to check whether notifications have been enabled or not before you attempt to queue up the notification.

[daviddedwin]

Closing due to inactivity. The change in the GATT interface in 0.7.1 should also be helpful in reducing the impact of this issue.