bt_gatt_notify() blocks; notifications not queued; mainline zephyr has CONFIG_BT_ATT_TX_COUNT

[OwainJangor]

Nordic zephyr implementation of bt_gatt_notify() appears to block; then at some point later from system workqueue thread seems to unblock.

My code currently calls notify from a thread that is not allowed to block.

Mainline zephyr includes changes (CONFIG_BT_ATT_TX_COUNT) that allow notifications to be queued; ncs does not include these changes.

I suspect this issue has existed for a long time. See this old ticket....

bt_gatt_notify from thread


I could create a queue and farm my notifications out to another lower priority task; but would the underlying issue still be there if bluetooth subsystem does not flush out the notifications quickly? Is the mainline CONFIG_BT_ATT_TX_COUNT from mainline zephyr not necessary?

Do you have any suggestions?
Connect

[Sigurd]

Hi!

Mainline zephyr includes changes (CONFIG_BT_ATT_TX_COUNT) that allow notifications to be queued; ncs does not include these changes.

This was just recently added in upstream Zephyr. We have just recently merged these changes to our Zephyr fork on main branch.

Before CONFIG_BT_ATT_TX_COUNT was added, you could configure extra ATT buffers using CONFIG_BT_L2CAP_TX_BUF_COUNT

[OwainJangor]

Hi Sigurd,

I have updated from ncs2.3.0 and increased the l2 cap tx bug count from 3 to 10.

I no longer see my task blocking, I can only assume this change worked for me.

Many thanks,

Owain