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

BLE_GATTS_EVT_WRITE not fired when writing to CCCD as BLE_GATT_OP_WRITE_CMD (S132)

Hi, I've been suffering with detection of writing to cccd to enable notifications. The S132 (nRF5_SDK_13.0.0_04a0bfd + s132_nrf52_4.0.2_softdevice) never fires BLE_GATTS_EVT_WRITE event to indicate that the peer wrote to cccd.

From whatever reason the softdevice does not fire event when writing to cccd using BLE_GATT_OP_WRITE_CMD. Workaround was writing to cccd using BLE_GATT_OP_WRITE_REQ, the event was fired (but the _REQ case is not what I want as additional round trip occurs)

here the code snippet on service and char adding with permissions

err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,     &ble_uuid, &m_service_handle);

memset(&char_md, 0, sizeof(char_md));
char_md.char_props.notify   = 1;
char_md.char_props.write_wo_resp = 1;

memset(&attr_md, 0, sizeof(attr_md));
BLE_GAP_CONN_SEC_MODE_SET_NO_ACCESS(&attr_md.read_perm);
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
attr_md.vloc       = BLE_GATTS_VLOC_STACK;
attr_md.rd_auth    = 0;
attr_md.wr_auth    = 1;
attr_md.vlen       = 1;

memset(&attr_char_value, 0, sizeof(attr_char_value));
attr_char_value.p_uuid       = &ble_uuid;
attr_char_value.p_attr_md    = &attr_md;
attr_char_value.max_len      = BLE_GATT_ATT_MTU_DEFAULT-3;

err_code = sd_ble_gatts_characteristic_add(m_service_handle,
                                       &char_md,
                                       &attr_char_value,
                                       &m_message_handles);

Interesting is that my code was ported from S132 (SDK V11.0.0-S132-V2-0-1) where it works.As I do not see any obvious issue, can someone help? Any ideas on what might be wrong, what are the trigger conditions for BLE_GATTS_EVT_WRITE (cccd), any suggestions what I might overlook while porting, anyone having the same issue? Many thanks

Parents
  • How does the client enable notifications if it can not write to the CCCD?

    The BT SIG Core V4.2 suggests that you can write to the the CCCD.

    Have I missed some thing?

    "3.3.3.3 Client Characteristic Configuration The Client Characteristic Configuration declaration is an optional characteristic descriptor that defines how the characteristic may be configured by a specific client. The Client Characteristic Configuration descriptor value shall be persistent across connections for bonded devices. The Client Characteristic Configuration descriptor value shall be set to the default value at each connection with non-bonded devices.The characteristic descriptor value is a bit field. When a bit is set, that action shall be enabled, otherwise it will not be used. The Client Characteristic Configuration descriptor may occur in any position within the characteristic definition after the Characteristic Value. Only one Client Characteristic Configuration declaration shall exist in a characteristic definition. A client may write this configuration descriptor to control the configuration of this characteristic on the server for the client. Each client has its own instantiation of the Client Characteristic Configuration. Reads of the Client Characteristic Configuration only shows the configuration for that client and writes only affect the configuration of that client. Authentication and authorization may be required by the server to write the configuration descriptor. The Client Characteristic Configuration declaration shall be readable and writable."

Reply
  • How does the client enable notifications if it can not write to the CCCD?

    The BT SIG Core V4.2 suggests that you can write to the the CCCD.

    Have I missed some thing?

    "3.3.3.3 Client Characteristic Configuration The Client Characteristic Configuration declaration is an optional characteristic descriptor that defines how the characteristic may be configured by a specific client. The Client Characteristic Configuration descriptor value shall be persistent across connections for bonded devices. The Client Characteristic Configuration descriptor value shall be set to the default value at each connection with non-bonded devices.The characteristic descriptor value is a bit field. When a bit is set, that action shall be enabled, otherwise it will not be used. The Client Characteristic Configuration descriptor may occur in any position within the characteristic definition after the Characteristic Value. Only one Client Characteristic Configuration declaration shall exist in a characteristic definition. A client may write this configuration descriptor to control the configuration of this characteristic on the server for the client. Each client has its own instantiation of the Client Characteristic Configuration. Reads of the Client Characteristic Configuration only shows the configuration for that client and writes only affect the configuration of that client. Authentication and authorization may be required by the server to write the configuration descriptor. The Client Characteristic Configuration declaration shall be readable and writable."

Children
  • I believe Ulrich is saying that GATT Client must use WRITE_REQ ATT method not WRITE_CMD. But there are several questions left like: why some Android devices use WRITE_CMD (that was the moment where previous Soft Devices work well) and how they will behave with changed implementation in latest Nordic Soft Devices?

  • See Core Spec 5.0 | Vol. 3, Part G chapter 4.12.3:

    **4.12.3 Write Characteristic Descriptors**
    This sub-procedure is used to write a characteristic descriptor value to a server when the client knows the characteristic descriptor handle.
    The Attribute Protocol Write Request is used for this sub-procedure. The Attribute Handle parameter shall be set to the characteristic descriptor handle.
    The Attribute Value parameter shall be set to the new characteristic descriptor value.
    A Write Response shall be sent by the server if the write of the characteristic descriptor value succeeded.
    

    Of course, if this leads to IOP issues with existing products, that is something we need to discuss further.

  • After thinking for a while the correct implementation to be

    • on correct CCCD packet (WRITE_REQ) you shall fire the event and submit correct reply (compliancy with BT SIG)
    • on obsolete CCCD packet (WRITE_CMD) you shall, to maintain compatibility and continuity with older softdevices, accept it, write to CCCD and fire the event (doesn't violate BT SIG) otherwise you'll create lots of field issues Ulrich, could you please forward this comment to your softdevice engineering managers? Many thanks, Pavel
  • I have raised this issue internally, but have no updates to share yet.

  • @Ulrich Myhre Hello, I know this maybe a bit late but can you please bring the old "error" back? I'm catching hell with my android program as I can't find the right way to write CCCD. It used to work so well, not it just crashes...

Related