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.

TL_HWJ

Hi, I tested the code you provided, but I was unable to reproduce the issue you mentioned. I found during testing that the data packets can still be retransmitted.

I conducted the test with the following function uncommented:

1. ​bls_pm_setAppWakeupLowPower(app_wakeup_tick, 1);

复制代码

Additionally, what you added here is essentially creating a ​timed timer-based wake-up task.

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

复制代码

Flole

Are you seeing the same behavior that the TLSR8251 doesn't enter deep sleep while data is transmissions are pending, unless the bls_pm_setAppWakeupLowPower function is used? That's what the gpio write at the beginning of the main loop is used for (indicate if the device is active or sleeping). This becomes clear when using a long connection interval as the GPIO will stay on for a very long time (multiple seconds).

It's very unexpected that you are seeing data retransmissions even with that function uncommented. I only see empty packets being retransmitted, no data packets. Have you set the connection interval to 3 seconds like I am doing it so the device enters deep sleep mode?

TL_HWJ

I haven't been able to reproduce it myself, but I'll check the code logic to see if there's any possibility of this happening.

Flole

Maybe in your tests you used a shorter connection interval/latency? This seems to be only happening when the controller goes to sleep between the original transmission and the retransmission. I don't understand why that happens as the FIFO is in the retention area.

Have you found anything while reviewing the code?