Missing retransmits causing connection drops

Flole

I am having an issue where the TLSR8251 does not retransmit packets in case they are lost. I looked at the issue using Wireshark and I can see that my central is trying to read from the device, but the response gets lost even though it is logged as "[LL][TX] Packet:". I am using a MTU of 131 and I have adjusted the buffer size accordingly:

/* CAL_LL_ACL_RX_BUF_SIZE(maxRxOct): maxRxOct + 22, then 16 byte align */

#define RX_FIFO_SIZE        160

/* must be: 2^n, (power of 2);at least 4; recommended value: 4, 8, 16 */

#define RX_FIFO_NUM                8



/* CAL_LL_ACL_TX_BUF_SIZE(maxTxOct):  maxTxOct + 10, then 4 byte align */

#define TX_FIFO_SIZE        144

/* must be: (2^n), (power of 2); at least 8; recommended value: 8, 16, 32, other value not allowed. */

#define TX_FIFO_NUM                16

AFAIK the link layer should detect the missing/dropped packets and issue a retransmission, and indeed in Wireshark I see the "Next expected sequence number" indicates that a retransmission is necessary, but it is never happening. Is this a bug in the link layer of the chip/SDK and how can this be resolved?

TL_SW

Please commit your Wireshark capture and print log, we will confirm whether this is bug.

Flole

The log of the last 2 reads is as follows:

1. [LL][RX]: 07 00 04 00 10 0f 00 ff ff 00 28
   
2. [ATT][RX] ATT Request: 04 00 10 0f 00 ff ff 00 28 a8
   
3. [ATT][TX] ATT Response: 04 00 11 14 0f 00 16 00 19 02 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 17 00 1a 00 12 19 0d 0c
   
4. [LL][TX] Packet: 02 2e 2a 00 04 00 11 14 0f 00 16 00 19 02 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 17 00 1a 00
   
5. 
   
6. 
   
7. [LL][RX]: 07 00 04 00 10 1b 00 ff ff 00 28
   
8. [ATT][RX] ATT Request: 04 00 10 1b 00 ff ff 00 28 f7
   
9. [ATT][TX] ATT Response: 04 00 01 10 1b 00 0a
   
10. [LL][TX] Packet: 02 09 05 00 04 00 01 10 1b 00 0a
    

复制代码

The first read response is received perfectly fine, the second TX Packet can not be seen on the Central and also not on the sniffer. The pcap file from the sniffer is attached. The response was most likely after the 2 empty PDUs after the "Sent Read Group Type Request", where the Central sent 2 consecutive Empty PDUs and the second one is marked as retransmission. Unfortunately the TLSR8251 doesn't retransmit the "Rcvd Read By Group Type Response" so the connection is eventually teared down after a timeout.

TL_SW

Okay, I will check. If there is any progress, I will reply to you as soon as possible.

TL_SW

I don't reproduce this issue using sample code. Could you please send your code to me that can reproduce this issue? thanks

TL_SW

hi, Flole
Could you help to confirm whether there are other IRQ task or other task that disable IRQ? If have and exceed to 200us, RF IRQ may be delayed and receive packet incorrectly.

Flole

I have disabled most of my custom code and the issue remains. I was using interrupts and disabling IRQ but that has been disabled for testing now. I think I was doing it properly by checking if it can be done at that point in time:

while(bls_ll_requestConnBrxEventDisable() < 50) {

    };

    bls_ll_disableConnBrxEvent();

    unsigned char r = irq_disable();

...



    irq_restore(r);

    bls_ll_restoreConnBrxEvent();

The issue only appears when packets are lost, so if you have no packet loss you will not see it. Have you simulated packet loss and seen the TLSR8251 retransmit packets?

Should the retransmission be also logged by the TLSR8251?

I will try to reproduce it with one of the examples.

Flole

It seems like the examples are doing the exact same thing: If there is RF interference or packets are corrupted there is no retransmission and the connection will be dropped eventually. I tested with the b85m_ble_sample and added code to send an indication every 3 seconds. After some time the calls are failing as the indication never got acknowledged. I can also do it the other way around and send write requests from the central and eventually they will cause a disconnection if a packet gets lost as no response is received because the retransmission is missing.