Central stalling with two peripherals when one is disconnecting

RE: Central stalling with two peripherals when one is disconnecting

Edvin — Tue, 07 Apr 2026 13:19:07 GMT

Hello Alberto,

Yes. That sounds about right!

In have not seen your application, but you can do a check every time you try to send a message, to see if you are still connected (set some flag in the disconnected event).

As you say, waiting for the TX complete callback will cause a drop in the throughput. One option is to keep some internal counter on how many packets you have queued and how many that have been acked, making sure you only have N queued messages at the time. Even better, if you keep track of what device each of these messages are meant for, you can clear that counter when one device disconnects, as these packets are discarded. This way, you can always have enough messages in the queue to maximize your throughput, without overloading the Bluetooth stack when you receive a disconnect.

Best regards,

Edvin

RE: Central stalling with two peripherals when one is disconnecting

Alberto Calatroni — Wed, 01 Apr 2026 07:02:49 GMT

Hi again Edvin and Nordic team,

We have some updates and we think we now understand what is happening.

Our hypothesis is that the "write without response" triggers the callback when the message could be successfully passed to the host, which does not mean that the host / controller were yet able to send this out. The consequence was that the internal buffers would get filled up if one of the connections was bad.

What we did is now to revert to the API which triggers a "write with response", and wait for the corresponding callback before unlocking the semaphore again. Like this, we only proceed when we are sure that the message was effectively sent (and acknowledged). This reduces somewhat the throughput, since we need to skip at least one connection interval, but is acceptable for our application.

Could you maybe confirm that our understanding is correct? Maybe it would be helpful to improve the include files / documentation regarding these behaviors.

Kind regards,
Alberto

RE: Central stalling with two peripherals when one is disconnecting

Alberto Calatroni — Fri, 27 Mar 2026 14:33:04 GMT

Hi Edvin,

Thanks for your quick answer. From the documentation I understand that the function is blocking if called from another thread, but from the same thread it should just return -ENOMEM. This is the assumption under which we based our architecture. Do we misunderstand something?

Best regards,
Alberto

RE: Central stalling with two peripherals when one is disconnecting

Edvin — Fri, 27 Mar 2026 14:08:18 GMT

Hello,

I am not sure how fast you are trying to push these messages. Could it be that you have filled the CONFIG_BT_ATT_TX_COUNT? The bt_gatt_write_without_response_cb() is a blocking call, meaning if it can't place the message in the buffer, it will block until it can fit the message.

Try increasing the CONFIG_BT_ATT_TX_COUNT and see if that helps. However, if you fill it up, it will still be blocking.

You could try to keep the transmission of the two different peripherals to different threads, and monitor how many messages are in each queue (to make sure you don't fill up the CONFIG_BT_ATT_TX_COUNT).

Best regards,

Edvin