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.

[Ulrich Myhre]

See my comment to the answer/question below. The spec is not 100% clear, but it only lists Write Request/Response as the valid procedure for writing to descriptors. The reason for insisting on the request/response is to make sure that the peer knows about the result of the action. If you just send a write_cmd on a security-protected CCCD, you might assume that notifications are enabled when they are not.

[cp52]

This would remove the choice of the developer as to whether they want an ack back for enabling notifications. If they want to use the write_cmd then it is at their risk that they do not know if notifications have been enabled or not. However in some situations they may want the speed increase of not receiving these acknowledgements.

[Ulrich Myhre]

4.0.4 and 5.0.0 production releases are now out on the web, both containing a reversal of this change. Please note the warning in the release notes related to this.

[Pepe]

thank you very much Ulrich for accepting our proposal, works like a charm in SD132 v4-0-4. Regards,Pavel