bt_gatt_notify() blocks thread nrf Connect SDK v2.4

[kpreiss]

Hi,

We're using nrf Connect SDK v2.4 and have issues when calling bt_gatt_notify() from our main thread.  The bt_gatt_notify() function blocks even though we have the CONFIG_BT_L2CAP_TX_BUF_COUNT parameter set to 20.  What is the earliest version of the SDK which will not block when calling bt_gatt_notify() if one exists?  Is there  a function we can call to determine how many notifications are pending in the transmit queue?

[Amanda Hsieh]

Hi, 

We're using nrf Connect SDK v2.4 and have issues when calling bt_gatt_notify() from our main thread.  The bt_gatt_notify() function blocks even though we have the CONFIG_BT_L2CAP_TX_BUF_COUNT parameter set to 20.

Could this post help?

What is the earliest version of the SDK which will not block when calling bt_gatt_notify() if one exists?

I cannot find the release note or change log regarding this, so I have no idea what the earliest version supports your requirement.  

Is there  a function we can call to determine how many notifications are pending in the transmit queue?

Check this post. 

Regards,
Amanda H.

[kpreiss]

Amanda,

No, this doesn't help.  I want to know if there are versions of the SDK available which do not block the calling thread of the bt_gatt_notify() function.  Additionally, if the notification queue becomes full, will the bt_gatt_notify() return an error instead of waiting for a buffer to become available?

I suppose we could use the callback to keep track of the number of notifications transmitted but it seems the number of buffered packets should be accessible to the application layer already.

[Amanda Hsieh]

Hi, 

kpreiss said:

if the notification queue becomes full, will the bt_gatt_notify() return an error instead of waiting for a buffer to become available?

No, bt_gatt_notify() in NCS will not return an error when the buffer is full. Instead, the function that requests the notification buffer will wait with K_FOREVER for the buffer to be available. 

-Amanda H.

[helpfulchicken]

I have this problem too, causing intermittent serious misbehaviour in our product.

No solution yet. I'm considering at least protecting the main thread from this blocking issue by moving the top level function calling bt_gatt_notify into a new thread purely for the purpose of isolating the burden of the blocking wait.

I have this issue reproducibly occurring when connections with a subscriber device are intermittent, leading to the main thread blocked for multiple seconds. Unacceptable result.

[helpfulchicken]

I ended up "solving" this issue by tracking in the application level whether notification requests had resolved or not. bt_gatt_notify_cb lets me use a callback to catch when it sends successfully, and a disconnect event handler lets me catch when the queue gets cleared as a result of disconnection - either means that one or more items are no longer in the tx queue which means it is safe to do one more notify attempt.