WRITE_REQ handling: Duplicate packets or wrong error handling?

[Marius Heil]

Hello,

am I right to assume that if sd_ble_gattc_write returns anything other than SUCCESS, then the packet was not queued?

Is this also true for BLE_GATTC_EVT_WRITE_RSP? If anything other than BLE_GATT_STATUS_SUCCESS is returned, then the partner has not successfully acquired the packet? What do errors like BLE_GATT_STATUS_ATTERR_UNLIKELY_ERROR or BLE_GATT_STATUS_UNKNOWN mean in this context?

Because I have just received a duplicate packet and I am not sure if I have sent it twice in my code or if there is any chance that a packet could be sent twice over the air by the softdevice.

Marius

[run_ar]

When calling sd_ble_gattc_write you will get a BLE_EVT_TX_COMPLETE when the packet has been transmitted for write commands. For write requests you will get a BLE_GATTC_EVT_WRITE_RSP when the packet is received by the peer.

sd_ble_gattc_write will return NRF_SUCCESS when it has started the write procedure. When you are doing write request you it will return NRF_ERROR_BUSY if a write request procedure is already ongoing,e.g. you have not received a BLE_GATTC_EVT_WRITE_RSP for your previous write request.

[Marius Heil]

Thanks, I know how error handling in general works. I am just interested if one of the errors could mean that the packet is transmitted and I do not get a success. This is why I was asking for BLE_GATT_STATUS_ATTERR_UNLIKELY_ERROR for example.

[run_ar]

BLE_GATT_STATUS_ATTERR_UNLIKELY_ERROR is implementation dependent, but means there was an internal error on the peer. What actually went wrong depends on the implementation on the device sending this error code. So yes, it means the packet was transmitted, but something went wrong. What device are you testing against? Do you have a sniffer log showing the sequence of packets leading to this error?