Other Parts Discussed in Thread: CC2640
Hi,
I am investigating an issue that seems to occur if too much time is spent inside the pfnGATTWriteAttrCB_t. We are in the middle of a connection event where many (6+) packets are being sent in the same interval from the central, and if too much processing takes place inside the attribute write callback, some of the packets get missed. The strange part is these packets seem to be missed completely, i.e. the central does not retransmit them (as if the BLE LL on the CC2640 has acked the packets, despite not calling our callback). In order to maximize throughput, we are using Write W/O Response, however my understanding is the central should retransmit these packets if the peripheral does not have enough buffers to process the data, because the BLE stack should not be issuing an LL-ack for those packets.
Is there a way to either control the LL-ack behavior of the stack in case there are not enough buffers or if something occurs that causes the write callback to take longer than usual? There is a structure in the HCI API called hciPER_t that contains useful info like number of rx packets/connection events, but no functions appear to make use of this structure.
Also, it looks like the pfnGATTWriteAttrCB_t can return blePending in case it needs additional time to process a write request, however the documentation does not state what effect this has on the connection. Will the BLE LL still ack packets that are received if it is out of HCI buffers? Is there a way we can inspect how many RX buffers are available? There's an API to limit the number of RX buffers per interval called HCI_EXT_OnePktPerEvtCmd(), but this would severely limit throughput.
Regards,
Michael
