strange error code 13313 (0x3401) returned by sd_ble_gatts_hvx()

[Martin]

Hi, I'm trying to update attribute value and notify it to client using sd_ble_gatts_hvx() function:

  memset(ms, 0, sizeof(params));
  params.type=BLE_GATT_HVX_NOTIFICATION;
  params.handle=p_lbs->button_char_handles.value_handle;
  params.p_data=&button_state;
  params.p_len=&len;
  err_code=sd_ble_gatts_hvx(p_lbs->conn_handle, ms);
  
  DPRINTF("BLE button update: state=%u, len=%u, conn_h=%u, svc_h=%u, val_h=%u, err=%u\n", *params.p_data, *params.p_len, p_lbs->conn_handle, p_lbs->service_handle, params.handle, err_code);
  return(err_code);

When connection is not established and connection handle is invalid (65535) I got error code 8 - NRF_ERROR_INVALID_STATE, shats OK. BLE button update: state=0, len=1, conn_h=65535, svc_h=12, val_h=14, err=8 When I connect via android tablet and try to read the value and change it I got strange error code 13313 (0x3401) that doesn't match any known NRF_ERROR_xx code. BLE button update: state=1, len=1, conn_h=0, svc_h=12, val_h=14, err=13313 But the updated value is readed OK. I tried more times update and tap read button on tablet and got same error but with good value. When I turn on the notify on tablet it works too (value is updated automatically) and returning error 0 like expected. BLE button update: state=0, len=1, conn_h=0, svc_h=12, val_h=14, err=0 Interesting that when I stop notify on tablet it keeps returning error 0 and not 13313. The updated value can still be read manually tapping read button...

[Martin]

Aha, OK, BLE stack use higher error numbers. I cannot find them by search because of there are composed by addind 0x3000 + 0x400 + 1 that is BLE_ERROR_GATTS_SYS_ATTR_MISSING but still don't have idea what this means. I have attribute set by button_char_add() from original BLE LBS demo.

[Ole Morten]

As the error suggests, it means that the softdevice doesn't yet have a set of system attributes. :-)

I'd recommend you to read this document to better understand the concept of bonding with regard to our softdevice, since it also applies to the system attributes.

As you can see, bonding data is split between encryption keys and the system attributes. System attributes includes for example values for CCCDs, and the softdevice therefore needs to get those before sending any notification. Hence, when you try to send a notification, if the peer device have not yet written to the CCCDs, the softdevice will ask the application whether it has any previous bonding data to be used, by giving a BLE_GATTS_EVT_SYS_ATTR_MISSING. If the device does use bonding, the bond manager will normally handle this event, and pass back whatever data has previously been written.

However, the system attributes are requested with the same event no matter if the device use bonding or not (the softdevice doesn't really know that). If a device does not use bonding, but in this case, you can just reply like this:

case BLE_GATTS_EVT_SYS_ATTR_MISSING:
    err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0);
    APP_ERROR_CHECK(err_code);
    break;

No matter which of these happens, a call to sd_ble_gatts_hvx() may get this error back if it's done at the exact right time, but if the call is retried just a short time later, this error should disappear, once either the application or the bond manager have set system attributes.

[Martin]

I already have this case block in on_ble_evt() function except without error checking. I added APP_ERROR_CHECK(err_code); line and no error appeared.

[Martin]

In current project I dont need bonding, it's based on ble-lbs where no bondmgr is used (no ble_bondmngr_cfg.h). CCCD setting I leaved same

memset(&cccd_md, 0, sizeof(cccd_md)) BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm); BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm); cccd_md.vloc=BLE_GATTS_VLOC_STACK; cccd_md.vlen=0;

[Ole Morten]

If you already have this case, I'd expect this error to be returned only for a very short time, and then disappear as soon as the application has replied to the event.

If you know that you'll never have any system attributes stored (i.e. you don't use bonding), it should be fine to move the setting of system attributes to the connected event, if you for some reason need to avoid seeing this error at all.