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.

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