Peripheral connection terminated with 0x08 (Connection Timeout) after ~163 ms although the initial supervision timeout is 720 ms

[strongman]

Environment

• nRF Connect SDK v3.3.1

• SoC: nRF54LM20A

• BLE peripheral using connectable legacy advertising

• Central: smartphone

Problem

We occasionally see very short-lived BLE connections that are disconnected with reason 0x08 (BT_HCI_ERR_CONN_TIMEOUT), even though the supervision timeout has not elapsed.

For example:

[00:31:36.387,160] Connected to conn 0x20009cd8, 68:A7:29:XX:XX:XX (public),
initial conn params: interval 30000us, latency 0, supervision timeout 720ms

[00:31:36.549,851] Disconnected from conn 0x20009cd8, 68:A7:29:XX:XX:XX (public),
(reason 0x8)

The timestamps shown above are captured when the connected and disconnected callbacks are invoked, respectively. They are not the timestamps of when the log messages are actually processed or printed.

The timestamps are obtained using k_cycle_get_32() with CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=1000000, giving 1 µs resolution. Therefore, the elapsed time between the two callback invocations is about 162.7 ms.

The initial connection parameters obtained with bt_conn_get_info() are:

• Connection interval: 30 ms

• Slave latency: 0

• Supervision timeout: 720 ms

We have also confirmed that:

• CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

• Our application does not call bt_conn_le_param_update() before the disconnect.

• No security_changed, le_param_req, or le_param_updated callbacks were triggered before the disconnect.

• No MTU exchange was observed.

The issue is intermittent. Most connections work normally, but occasionally a newly established connection is disconnected in this way.

Questions

1. What could cause a connection to be disconnected with reason 0x08 only ~163 ms after connection establishment, when the supervision timeout is 720 ms?

2. In this case, is 0x08 generated by our local controller's supervision timer, or can it also be reported when the peer terminates the connection due to its own timeout?

3. Is there any way to obtain additional diagnostic information from the SoftDevice Controller, such as debug counters or connection-event information, to determine the cause of the disconnect?

4. Are there any known issues on nRF54L-series devices that could cause this kind of intermittent short-lived connection with reason 0x08?

Any suggestions on what to check would be appreciated.

[tesc]

Hi,

I assume your device is acting as initiator / central.

In that case, I suspect what you are experiencing is that the central sends a CONNECT_IND packet (to indicate it wants to initiate a connection), but that the peripheral for some reason doesn't get that packet. In that situation, the central is considered connected, but the peripheral is not. The peripheral will not send any packets during the connection, as from the perspective of the peripheral there never was any connection to begin with. The central will then time out, as it never receives any packets from the peripheral within the connection events of the connection.

The particular timeout is a special case of supervision timeout. At the beginning of a connection, the central is mandated to time out already after six connection events, if at that point it has not received any packets at all from the peripheral. This is a special case for ensuring rapid timeout in the exact situation of a would-be peripheral not receiving the CONNECT_IND packet. For reference, please see the Bluetooth Core Specification v6.3, Vol 6, Part B, section 4.5.2 Supervision timeout.

In your case, with connection interval of 30 ms, the timeout should be expected after slightly more than 5 * 30 = 150 ms, and is consistent with the timing you see of 162.7 ms. (Five times the connetion interval, as the six connection event instances have a total of five gaps between them.)

A sniffer trace, for instance using the nRF Sniffer, will reveal what is actually going on over-the-air, and potentially further confirm that the above is what is happening. That is, the central aborting the connection after having sent packets at six consecutive connection events from the beginning of the connection, and the peripheral not sending any packets as part of the connection (but rather proceeding with its advertising as if nothing had happened.)

Regards,
Terje