nRF5340 Missing Disconnect Event (Supervision Timeout)

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

tdfilip — Mon, 23 Mar 2026 08:10:56 GMT

Hello,

I updated ncs from 3.1.0 to 3.2.2 and I started observing exactly the same behaviour. I don't receive disconnected event when the supervision timeout occurs. I'm using nRF9151 as hci host + nRF52840 with hci lpuart example. The issue started to occur after updating nRF52840 app to ncs 3.2.2. It didn't occur when both apps were on ncs 3.1.0 but also it didn't occur when nRF9151 app was already using ncs 3.2.2 but the nRF52840 was still on ncs 3.1.0.

Are you aware of that issue on ncs 3.2.2? Maybe it is already fixed on newer ncs versions?

Regards
Filip

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Sat, 14 Jun 2025 08:58:22 GMT

Kelso , please take a look at this if you're still experiencing the issue:BLE Advertisement Issue in nRF Connect SDK v2.7.0 (DRGN-23231) – Any Cherry-Pick or Temporary Fix Available?

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Kelso — Wed, 23 Apr 2025 23:42:17 GMT

Also in the same boat. Proposed workaround does not work.

nRF Connect SDK v2.6.1 using nRF5340

CONFIG_BT_BUF_CMD_TX_COUNT = 10
CONFIG_BT_BUF_ACL_TX_COUNT = 7
CONFIG_BT_BUF_ACL_RX_COUNT = 6
CONFIG_BT_BUF_ACL_[TR]X_SIZE = 136

attempting to support BLE periph + BLE central + ANT is encouraging me to stick to this version of the code...

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

dario.sortino — Tue, 28 Jan 2025 11:28:01 GMT

Is there any news on this topic? I am facing the same issue of not having the disconnection callback triggered, hence having "Found valid connection with address (random) in connected state" when trying to reconnect again.

Working on 2.6.0

The workaround proposed in this comment doesn't work for me

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Thu, 16 Jan 2025 15:10:27 GMT

Jeff,

I understand you’ve been in contact with one of our developers on Discord and found a suitable workaround. So I assume I can consider this ticket resolved for now. Please let me know if that’s not the case. Of course we still need to address the issue in the host or controller to remove the need for this workaround in the first place.

Workaround:

Set CONFIG_BT_BUF_CMD_TX_COUNT >= (CONFIG_BT_BUF_ACL_RX_COUNT + 1) , i.e. CONFIG_BT_BUF_ACL_RX_COUNT=10 and CONFIG_BT_BUF_CMD_TX_COUNT=11 in your ipc_radio.conf

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Tue, 07 Jan 2025 10:57:18 GMT

Jeff,

Thank you! I hope you got some time off as well. The developers are able to reproduce the issue now with the project you provided and they have set aside time to investigate further. I will try to update you as soon as there is any progress or relay any requests they may have.

--Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Fri, 03 Jan 2025 14:04:21 GMT

Thanks Vidar!

Hope you and the Nordic team had a great holiday season.

Yesterday we started more mitigations, but ended up causing more issues than we solved.
(Looking for RSSI dithering of attached peripherals to plateau for >10s due to a missed disconnect, and forcing a system reboot)
On our end we're going to work to get the kinks out of our mitigation, but we're experiencing this issue in all of our units.

Happy to assist in any way possible to hopefully get a proper root cause and solution.

--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Wed, 18 Dec 2024 17:08:21 GMT

Jeff,

Thank you! This case has been on my mind lately, but I haven't had any updates to share as the team has not had a chance to revisit the issue yet. I understand this is a blocker for you and I think it is very unfortunate that we still have not been able to provide a solution. Since we will have reduced staffing during christmas due to public holidays, I’m afraid it is not realistic that we will come to a conclusion before new year. But one of the developers said they would have another look at this tomorrow so I will let you know if there are any new findings.

--Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Wed, 18 Dec 2024 14:44:01 GMT

Vidar,

Congrats to the team on getting v2.9.0 across the finish line for nRF54, cool stuff. :)

Glad you were able to reproduce it -- has there been any more news on this from the devs?

We're back on the SoftDevice Controller after a couple upstream sagas, so this problem is again our biggest blocker for production.

P.S. Happy Holidays!
--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Tue, 10 Dec 2024 12:11:04 GMT

Hi Jeff,

Thank you. I’m able to reproduce the issue now. It seems the developers were powering the kit on and off but likely missed the critical window you described. They will test again following your instructions.

--Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Mon, 09 Dec 2024 14:15:42 GMT

Hey Vidar,

Thanks for following up.
My colleague was just able to get the condition in 3 attempts.

We're more successful by switching the peripheral nrf52840dk power switch to OFF and waiting for the supervision timeout, rather than hitting the reset button.

Also make sure you wait until the second raise TX IRQ after connection parameters are exchanged. :)
--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Mon, 09 Dec 2024 12:54:03 GMT

Hi Jeff,

Sorry for the delayed response. Both R&D and I have made several attempts to reproduce the issue with the missed disconnect, but without any luck. Were you able to reproduce this fairly consistently on your side?

Below is the central log from the nRF5340 after having reset the 52840 peripheral. Since the scanner is always active in this sample and the peripheral starts advertising immediately after a reset before the supervision timer on the central has expired, I do see repeated warnings showing that the peripheral is already connected before the link is actually terminated by the supervision timeout.

--Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Fri, 29 Nov 2024 12:29:03 GMT

Hi Jeff,

I have requested a status update on this issue.

--Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Wed, 27 Nov 2024 18:49:31 GMT

Hey Vidar,

Not expecting any solutions -- just curious if any teams were able to reproduce the problem given the sample, or not yet. :)

--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Fri, 22 Nov 2024 13:56:14 GMT

Jeff,

Thank you very much for creating this sample. We will use it to reproduce the issue on our end and hope to identify the root cause soon.

Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Thu, 21 Nov 2024 16:22:57 GMT

Vidar,

My colleague was able to create a barebones sample to demonstrate this missing disconnect.

We modified your sample in these ways-
Peripheral:
On send enabled (this is after MTU update), we send 1000 bytes of zeros.
Central responds with 1000 bytes of ones.
Repeats sending ones/twos/threes.
After we receive the last packet, we update the connection interval parameters and go idle.

Central:
Switch to IPC_RADIO
No auto connect on filter match
Vendor specific connection event report is enabled
Scanning is only disabled while connecting (code in main.c does not support multiple connections, but it is modeled after our application)

Inside the zip is a readme.
Central was a nRF5340dk
Peripheral was a nRF52840dk

devzone.nordicsemi.com/.../MissingDisconnectModifiedSamples.zip

[00:00:23.747,192] <dbg> bt_conn: tx_notify_process: conn 0x200018c8
[00:00:23.747,222] <dbg> bt_conn: tx_notify_process: tx 0x2000297c cb 0 user_data 0
[00:00:23.747,222] <dbg> bt_conn: tx_free: 0x2000297c

-- NOT ORIGINAL LOG --
-- BEGIN WINDOW WHERE I TURN OFF POWER TO 52840DK PERIPHERAL --

[00:00:23.747,253] <dbg> bt_conn: tx_notify_process: raise TX IRQ
[00:00:23.747,283] <dbg> bt_conn: bt_conn_tx_processor: start
[00:00:23.747,283] <dbg> bt_conn: bt_conn_tx_processor: no connection wants to do stuff
[00:00:24.047,241] <dbg> bt_conn: bt_conn_ref: handle 10 ref 2 -> 3
[00:00:24.047,271] <dbg> bt_conn: bt_conn_unref: handle 10 ref 3 -> 2

-- NOT ORIGINAL LOG --
-- END WINDOW --
-- IF DISCONNECTED, TURN ON AND TRY AGAIN, VARY WHEN POWER IS TURNED OFF IN THIS WINDOW --
-- IF UNABLE TO REPRODUCE, TRY SLIGHTLY BEFORE OR AFTER WINDOW--

[00:09:06.285,400] <inf> central_uart: Filters matched. Address: D4:BC:F8:83:7F:87 (random) connectable: 1
[00:09:06.285,583] <dbg> bt_conn: bt_conn_tx_processor: start
[00:09:06.285,583] <dbg> bt_conn: bt_conn_tx_processor: no connection wants to do stuff
[00:09:06.289,550] <dbg> bt_conn: bt_conn_ref: handle 10 ref 2 -> 3
[00:09:06.289,672] <wrn> bt_conn: Found valid connection (0x200018c8) with address D4:BC:F8:83:7F:87 (random) in connected state 
[00:09:06.289,672] <dbg> bt_conn: bt_conn_unref: handle 10 ref 3 -> 2
[00:09:06.289,703] <dbg> bt_conn: conn_le_create_common_checks: Conn check failed: ACL connection already exists.
[00:09:06.289,703] <err> central_uart: bt_conn_le_create failed (err -22)

--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Wed, 20 Nov 2024 09:10:11 GMT

Jeff,

It is surprising that this occurs when almost nothing is happening besides scanning. The issues we found earlier would only occur during high BLE activity. I have reported this as new issue internally. I also found out that we already include tests that simulate sudden disconnects by resetting the peer device. However, it seems we are not able to replicate the same conditions seen with your application.

Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Wed, 20 Nov 2024 01:36:24 GMT

Vidar,

I appreciate the suggestions, but both the central and peripheral are multi-connection. Unfortunately due to this topology, just because the peripheral is advertising again does not mean that the central missed a disconnect event.

The connection pointer needs to have the correct state. I don't know how the supervision timeout does not get processed when almost nothing besides scanning is happening.

For the time being we're using the Split LL again, but ideally we move back to Nordic for a more familiar path to SIG certification.

--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Tue, 19 Nov 2024 09:14:19 GMT

Jeff,

[quote user="JeffWelder"]I think there's a small misunderstanding.
The Central device wrongly stays in a "connected state" when the link should have been terminated due to missing Link Layer packets.[/quote]

I was wondering what prompted the central to reconnect when it still believed it was connected to the peripheral. However, I had a single link GAP central in mind when I asked this. For a multi-link central, you would continue scanning after the connection has been established, so I think this part makes sense now.

As a workaround, would it make sense to check if you already have a valid connection for a given address before calling bt_conn_le_create()? This seems like an easy way to detect a missed disconnect event. You could then call bt_conn_disconnect() on the stale connection object to attempt to free it before establishing the connection again.

[quote user="JeffWelder"]Only thing going is LL packets.[/quote]

The flow control bug we attempted to address in v2.8.0 should only occur when the stack needs to wait on resources (buffers) to be freed and is not expected to happen during low BLE traffic.

Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Fri, 15 Nov 2024 15:35:10 GMT

Vidar,

I think there's a small misunderstanding.
The Central device wrongly stays in a "connected state" when the link should have been terminated due to missing Link Layer packets.

1) Central connects to peripheral
2) DTLS over NUS until handshake is completed. NUS data stops. Only thing going is LL packets.
3) Battery is pulled on peripheral device (proxy for real world disconnect due to range)
4) Supervision timeout does not hit after 6 seconds. Wait around 30s-1 minute at this point.
5) Battery is replaced, device advertises (with same address)
6) Central tries to reconnect to the device but bt_conn_le_create fails with -22 because bt_conn_exists_le fails and prints "<wrn> ble_conn: Found valid connection (0x2000f540) with address F1:61:8:6E:9A:B2 (random) in connected state.

This prevents reconnecting to the peripheral device because internally there is still a conn found by bt_conn_lookup_addr_le where the state is still connected in some combination of the host/controller, even though it has not gotten any connection LL packets past the supervision timeout.

The nRF52 peripheral correctly gets the supervision timeout in all real world (non-battery-pull) cases.

I appreciate the suggestions, and some methods like failing a GATT write from the controller might cause a disconnect after a timeout (30s, but recently configurable iirc), but we're in a bluetooth proximity tethering application that requires being fast acting, so actually getting the supervision timeout disconnected event is ideal.

Happy to clarify further, also available on the Zephyr Discord (Jeff Welder) if that line of communication proves more efficient,
--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Fri, 15 Nov 2024 09:15:58 GMT

Jeff,

Does the peripheral use different addresses for its advertisements? If not, what could be triggering the central device to reconnect to the peripheral when it has not received a disconnect callback? Another approach might be to use write or notify with callbacks and trigger a disconnect if the callback is not received within a certain time. I would not expect this to have a noticeable impact on your power budget.

As I understand from the developers, the proper fix for this will likely require additional changes to the controller itself.

Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Thu, 14 Nov 2024 18:14:52 GMT

Vidar,

Since the disconnected callback isn't raised, we don't know when to issue this disconnect -- the peripheral device is multi-connection, so advertising packets come out during a valid connection, so we can't just rely on the connect failing due to seeing a device that's already connected.

We would have to implement application layer pinging as an additional supervisor timeout. I don't think this fits into our primary cell power budget on the peripheral.

I guess our only option is to go back to the Zephyr split controller until Nordic fixes this IPC?

--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

Vidar Berg — Thu, 14 Nov 2024 17:45:42 GMT

Jeff,

This is unfortunate and not what I had hoped for. It seems we were only able to partially resolve this issue in this release. As a possible workaround, would it be an option to call bt_conn_disconnect(<conn object>, BT_HCI_ERR_REMOTE_USER_TERM_CONN) when this error is raised (even though the link will already have been terminated by the controller at this point)? This should allow the host to free the connection object. Potential drawback of this workaround is that it could cause a valid link to be disconnected if another advertiser starts advertising with the same address. This may not be likely, but it’s something to consider.

Vidar

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Wed, 13 Nov 2024 19:45:01 GMT

Vidar,

Unfortunately we updated to v2.8.0-rc2 and are still having this issue.
EDIT: v2.8.0 release also has this issue

Here is our exact Zephyr:
github.com/.../v2.8.0-eti-rc2

Our test is as a central to connect to a device, get through a NUS data exchange (DTLS handshake), and wait specifically for the log message tx_notify_process: raise TX IRQ to come out:

[00:00:10.963,623] <dbg> bt_conn: bt_conn_ref: handle 0 ref 3 -> 4
[00:00:10.963,653] <dbg> bt_conn: bt_conn_unref: handle 0 ref 4 -> 3
[00:00:10.963,745] <dbg> bt_conn: bt_conn_unref: handle 0 ref 3 -> 2
[00:00:10.963,806] <dbg> bt_conn: bt_conn_tx_processor: start
[00:00:10.963,806] <dbg> bt_conn: bt_conn_tx_processor: no connection wants to do stuff
[00:00:11.012,512] <dbg> bt_conn: bt_conn_ref: handle 0 ref 2 -> 3
[00:00:11.012,573] <dbg> bt_conn: bt_conn_unref: handle 0 ref 3 -> 2
[00:00:11.012,603] <dbg> bt_conn: tx_notify_process: conn 0x2000f7c8
[00:00:11.012,634] <dbg> bt_conn: tx_notify_process: tx 0x200203dc cb (nil) user_data (nil)
[00:00:11.012,664] <dbg> bt_conn: tx_free: 0x200203dc
[00:00:11.012,695] <dbg> bt_conn: tx_notify_process: raise TX IRQ
[00:00:11.012,725] <dbg> bt_conn: bt_conn_tx_processor: start
[00:00:11.012,756] <dbg> bt_conn: bt_conn_tx_processor: no connection wants to do stuff
[00:00:11.312,347] <dbg> bt_conn: bt_conn_ref: handle 0 ref 2 -> 3
[00:00:11.312,377] <dbg> bt_conn: bt_conn_unref: handle 0 ref 3 -> 2
[00:00:42.877,471] <dbg> ble: scan_filter_match: Found device that we are already connected to EF:40:43:07:0C:1D (random)

At this point, if the battery is removed from the peripheral during the ref->unref activity afterwards, the connection and ref stays, but obviously the link is lost. Supervision timeout (6s) does not hit, and we have a stale ref where we can't "reconnect" to the same device.

Attached is our .config from IPC_Radio
devzone.nordicsemi.com/.../6406_2E00_ipc_5F00_radio_2E00_config
Our application has:

CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_CMD_TX_SIZE=65
CONFIG_BT_BUF_EVT_RX_SIZE=68
CONFIG_BT_BUF_ACL_TX_SIZE=27
CONFIG_BT_BUF_ACL_RX_SIZE=1536
CONFIG_BT_L2CAP_TX_MTU=1536

Let me know how we can further assist debugging,
--Jeff

RE: nRF5340 Missing Disconnect Event (Supervision Timeout)

JeffW — Thu, 07 Nov 2024 14:48:16 GMT

Vidar,

We will keep tabs on the releases.
Thanks for the expected timeline, and continued support with the developers. It is greatly appreciated :)

--Jeff