nrf5340 occasionally stuck on BT_CONN_STATE_DISCONNECTING

[tonyh]

Hello,

We have an nrf5340 custom board and during frequent BLE connections/disconnections sometimes it seems the netcore gets stuck. We are connecting to an iOS app and from the app's side, the connection is no longer active (can't recieve any data) but from the nrf5340's point of view the connection is still maintained and we don't get any errors when sending over NUS. We have tried to get around this by having the app periodically send a heartbeat packet, but when the nrf5340 enters this state and we try to call bt_conn_disconnect(), the connection's state becomes BT_CONN_STATE_DISCONNECTING and is stuck there for hours. The connection never terminates and we can't resume advertising. Any help would be appreciated since this is a very strange issue.

Tony

[Edvin]

Hello,

Sorry for the late reply!

Can you please check the logs from your network core? Are there any clues there? 

What NCS version are you using?

If you are using an application based on the peripheral_uart then logging from the network core may be switched off. How to turn it back on depends on what NCS version you are using. In your application root folder, look for either a folder called child_image, or sysbuild, and there, look for either a file called ipc_radio\prj.conf, ipc_radio.conf, hci_rpmsg.conf or hci_ipc.conf (you will probably only find one). In that file, is there anything saying CONFIG_LOG=n or CONFIG_SERIAL=n or CONFIG_UART_CONSOLE=n?

If so, try to set them to "y" instead of "n", and open an UART terminal connected to your network core's UART (probably the other COM port that your DK provides). Does the log say anything at all when you boot up? And when the device is stuck in the BT_CONN_STATE_DISCONNECTING, does the log from the network core say anything? If it stops printing, what was the last thing that it said?

Best regards,

Edvin

[tonyh]

Hello,

Thanks for the reply. We are on NUS 2.5.0 (no sysbuild) and we've managed to figure out with the help of this similar issue on w/ 2.7.0  nRF5340 Missing Disconnect Event (Supervision Timeout)  and debugging with ozone that this issue occurs during a disconnect while there is a pending GATT read. When this happens the disconnect callback is missed. We've added a handshake before GATT reads and added CONFIG_BT_HCI_ACL_FLOW_CONTROL=n to mitigate this issue and seems that a permanent fix is coming.

Thanks

Tony

[Edvin]

Ah, yes. I had a discussion with my colleague Vidar about a similar issue, and he seems to know quite a bit about it. 

tonyh said:

and seems that a permanent fix is coming.

At least I know that our SoftDevice team was working on this ticket that Vidar has (probably the one you linked to). It seems to fit with the timeline as well.

Let me know if you experience further issues with this, and the workaround doesn't work.

Best regards,

Edvin