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.