Missing retransmits causing connection drops

Flole

It looks like you have SMP enabled in your case? In my case SMP is disabled (BLE_APP_SECURITY_ENABLE 0), maybe that is what causes this? You have caused a drop of an "empty packet" in your capture I think? In my case there is a loss of the "read response" which is then not retransmitted. It would be great if you could simulate a loss of that read response packet and see if that one is also retransmitted in your tests. If there is a bug that removes the read response packet from the TX FIFO after sending and before confirmation this bug can not be seen for empty packets as they are not part of the FIFO.

TL_SW

It's not an empty packet that's lost — as you can see from the diagram, the lost packet is an ATT response packet.

Flole

Then I don't understand your capture screenshots yet. I only see a single ATT response packet and the red marked packets which are retransmitted are empty packets? If you simulated a loss of that ATT response packet on the central using the method I described then it should show up on the sniffer (as it was actually transmitted) but not on the central (as it was "lost", or dropped in this case with the test setup). So the centrals next expected sequence numbers should indicate, that the packet needs to be retransmitted. Then the peripheral should retransmit the ATT response packet (using the same sequence number as before), and it should show up again on the sniffer (which I can not see on your screenshot, there is only a single ATT response packet). This time the central should receive it and it should be fine then.

TL_SW

This diagram matches what you described: the loss of the ATT response packet was simulated on the central, and this packet does show up in the sniffer.
In the next interval, the central retransmits an empty packet with the same SN (Sequence Number) and NESN (Next Expected Sequence Number) — this indicates that the aforementioned packet needs to be retransmitted.
After that, the peripheral retransmits the ATT response packet (using the same sequence number as before), and this retransmitted packet does appear again in the sniffer. We have already verified this.

In an Ellisys packet capture, if the color in the middle of an empty packet is red (rather than gray), it indicates the packet is not received. This is parsed based on the SN (Sequence Number) and NESN (Next Expected Sequence Number).

Flole

I think I found out what is happening. If the TLSR8251 enters deepsleep retention after doing the transmit/before doing the retransmit then instead of retransmitting the actual packet only an empty packet is retransmitted. If the TLSR8251 stays awake then the retransmission is done properly (I have also seen the retransmission now in that case on my capture). I found out that for the ble_sample it does not enter deepsleep retention usually if I keep sending read requests, only if I add

1.         unsigned int app_wakeup_tick = clock_time() + (320000 * sys_tick_per_us);
   
2.         bls_pm_setAppWakeupLowPower(app_wakeup_tick, 1);

复制代码

it will enter deepsleep retention for some reason. I am checking if it enters deepsleep retention by turning on an LED at the beginning of the main loop, while the LED is on the TLSR8251 is awake, if the CPU goes into deepsleep the LED turns off.

I have uploaded the changed ble_sample, I am reading in an endless loop with a 2500ms interval, latency is 0. If I uncomment the line

1. bls_pm_setAppWakeupLowPower(app_wakeup_tick, 1);

复制代码

then only empty packets are retransmitted, if it stays commented the LED stays on while I am reading so the device never enters deepsleep, and in that case the retransmissions work. Also in my opinion it should enter deepsleep mode even if I am continously reading and not using the bls_pm_setAppWakeupLowPower function? Not sure why that is not working properly.

TL_SW

Okay, we will conduct testing and analysis in accordance with the method you provided.