Disconnect BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED

[KonstantinK]

Subject: Assistance Required: Troubleshooting nRF52840 and nRF52832 Connection Issues

Hi,

I am currently working on a project involving a nRF52840 (S140) serving as the central device, attempting to connect to a nRF52832 (S113), which functions as a peripheral. We occasionally encounter an issue where the connection fails with the error: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. Although the connection is initially successful, it abruptly stops working after a few successful attempts.

In my troubleshooting efforts, I have monitored the communication between the two devices and observed that the peripheral does not respond to the CONNECT_REQ from the client.

Given this situation, I have several questions:
1. Do the scan parameters of the central device influence this issue? I believe they shouldn't, but I would like to confirm.
2. Could the advertising parameters of the peripheral be impacting the connection stability?
3. Are the connection parameters set on both devices contributing to this problem?
4. Could you provide some insight into what might be causing this issue, and suggest where we should focus our troubleshooting efforts in our application? Which SoftDevice calls could potentially be impacting this situation?

For a clearer understanding, I am attaching a Wireshark trace. At second 163, there is a successful connection establishment, and at second 176, the connection attempt fails.

Thank you for your help.

[Hakon]

Hello,

most of the staff is away for vacation, so there will be some delays in response time. Thank you for your patience.

[KonstantinK]

Any feedback on this?

[Sigurd]

Hi!

BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED means that the connection request packet is not received by the peer side. From  RE: BLE_GAP_EVT_CONNECTED when not connected. too early?  , we have this explanation: 

When central device is in Initializing state it is waiting for the advertisement packet to time correctly to send a connect request. After the central has sent this connect packet, it will immediately switch to connected state irrespective of what has happened to that packet (that is if peripheral received that packet or not). This event is propagated up to the application, but in the case the connect request packet got corrupted or lost, then there will be no connected packets arriving from peripheral to central and eventually the central would have connection timeout and disconnect (and hence your subsequent disconnect on central).

If this is not consistently happening and if it is happening with other devices too, then I would suspect that you probably are working in a lot of noise with respect to bandwidth in which BLE operates.

[KonstantinK]

Hi,

thanks for your answer. The strange thing is, connecting to the peripheral with my phone works everytime as well as connecting from my central to other peripherals.

So the issue may be the combination of those two devices. This is the reason for my questions 1,2,3. Do you have any advice on question 1,2,3? Is windowOffset and windowSize changeable on S140?

[KonstantinK]

Hi,

I did some more testing an research and found out that I might block the radio through advertsing/scanning/connecting.

My requirements are:

• Peripheral connections: 2
• Central connections: 5
• Total connections 7
• Advertising
• Connecting to peripheral

Do you have any recommendation which values I should use for advertisment intervall, scan interval/window and connection parameters?

[Sigurd]

Hi!

Could you check what version of S113 and S140 you are using ?