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 should not be possible, as the GATT requests should be a FIFO, and the SoftDevice should take care of them. This means it won't be possible to change the order of these requests.

Best regards,

Simon

[Sharan]

Hi Simon,

Thanks for confirming.

What's the max command buffer size for sd_ble_gattc_read() and sd_ble_gattc_write()? 1 or more?

Basically I want to know how many read and write commands I can queue before receiving NRF_ERROR_BUSY.

[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

[Simonr]

Hi Sharan

What SoftDevice version are you using? It seems from the API, that only writes without response may be queued.

Here's a new update from the developers as well:

"Is the below example a correct understanding of the problem?

Customer is investigating an issue reported in field, and is concerned about their code expecting that SoftDevice events caused by GATT server responses from peer are in the same order as GATT client requests have been issued. Customer wants to confirm whether the SoftDevice allows more than one request to be issued without waiting for a response. As an example, is the order of events below possible?

 

1. sd_ble_gattc_read is called, returns NRF_SUCCESS
2. sd_ble_gattc_write is called, returns NRF_SUCCESS
3. Event is generated, read response is expected since the read was issued first, but write response is the actual event
4. Event is generated, write response is expected, but read response is the actual event"

Best regards,

Simon