Order of responses for GATT read/write requests

[Sharan]

Hi,

Is there a possibility that the order of the responses can be different with respect to the order of the requests?

We check for the success status of the APIs sd_ble_gattc_read() and sd_ble_gattc_write() and expect the response in the same order. But sometimes, quite randomly order is not correct. We don't have logs unfortunately.

Side note:

We have 32 length characteristic value. Peripheral first sends 20 bytes data as an Indication and from the Central we try to read the remaining bytes from offset 20. This read request is called from the event handler. Do you see any problem in this approach? Normally it works just fine.

[Simonr]

Hi Sharan

This was apparently a bit more complicated than we thought initially, so I've gotten a developer to look at it. Here's what he had to say:

"The case is a bit unclear to me, could you clarify the following points:

• Are writes configured as with or without response?
• Can you give a more specific example of a case where responses appear in incorrect order, including function calls, return values, and events?
• When you check for “success status” and expects a “response”, do you mean NRF_SUCCESS return value, or events occurring as a result of the operations being acknowledged by the peer?

In general, note that "Once a client sends a request to a server, that client shall send no other request to the same server until a response PDU has been received." [Bluetooth Core Specification v4.2 Vol 3 Part F Section 3.3.2]. This implies that read requests and write requests cannot be interleaved or issued in multiples without waiting for a response for each request.

Best regards,

Simon

[Sharan]

Hi Simon,

• With response 
• Issue is reported in the field, so we don't have sufficient logs to pin point. However when I started debug our code/design there is assumption that we receive the responses in the synchronous order for sd_ble_gattc_read() or sd_ble_gattc_write(). I know this is not a good idea from our side to process a response without even comparing the handle/type. Blame the previous developer   :(
• We check the return NRF_SUCCESS for sd_ble_gattc_read() and sd_ble_gattc_write() and set a busy flag and reset in the event response.

As per your last paragraph, if I understand it correctly APIs sd_ble_gattc_read()/sd_ble_gattc_write() return busy if the response for the previous command is not received yet. Is that correct?

Thanks,

Sharan