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

[Pepe]

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

[Ulrich Myhre]

This was a bug in some earlier SoftDevices. The Bluetooth spec does not allow you to send write commands to CCCDs/SCCDs, so they are now properly ignored.

The event is not firing because the write command is rejected.

[cp52]

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."

[endnode]

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?

[Pepe]

I agree with Emil. Off course, it is nice to have reliable write as the BT SIG states on writing to descriptors, it is nice to be as close to standard as possible, but on other hand we should also consider cell phone (in)compatibility. Imagine what will happen when blocking the event - and enabling notifications is one of the most used features - it will at the end cause even more incompatible mess, making all product based on Nordic chipsets more incompatible with devices on the market, I'd rather say even incompatible at all making legacy applications unusable. In our case, instead of blocking the event, I would rather to keep it and have the case recorded in errata for softdevices. "Road to hell is paved with good intentions", that's what in my opinion has exactly happened in this case.

[Ulrich Myhre]

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.