I am using a CY8C6347BZI-BLD53 and ble connections are working well with iOS and Android clients. However, establishing a BLE connection with windows is unreliable; sometimes it works, some times it doesn't. I've used a protocol analyzer to capture the BLE traffic while establishing a connection with windows and have found that when a connection doesn't work, the PSoC6 doesn't acknowledge the LL_FEATURE_REQ sent by the windows radio and the windows radio retransmits that packet until the connection times out. What could cause this behavior?
I've attached a couple of screenshots of the packet trace showing the issue. Frame 8,308 is the connection indication and it is immediately followed by the LL feature request on frame 8,309. Frame 8310 doesn't acknowledge frame 8,309 and then it gets retransmitted a lot of times, never being acknowledged by the PSoC6. I'm happy to upload the full packet trace to a non-public forum, it contains both successful and unsuccessful connections.
Solved! Go to Solution.
The issue seems to be on windows side. From your logs, it has shown the follow:
1. Frame 3866: Windows sends LL_FEATURE_REQ in a PDU with SN 0, NESN 0 on channel 32.
2. Frame 3867: PSoC 6 Acknowledges the packet from Windows with an empty PDU with SN 0 and NESN 1 on channel 32.
3. Windows seems to ignore this empty PDU and re-sends same LL PDU in frame 3686 on channel 32.
4. Then in the next connection event, windows radio again sends the same packet, we acknowledge the packet again, but windows ignores our acknowledgement.
PSoC 6 will continue to acknowledge the LL PDU using the empty PDU and will not send a new packet untill windows radio acknowledges PSoC's empty PDU.
Similarly, from the images which you attached, in frame 8310, PSoC 6 is acknowledging the LL PDU, so frame 8310 acknowledge frame 8,309. In fact, Frame 8311 doesn't acknowledge frame 8,310.