Unable to allocate TX context when "spamming" bt_gatt_notify_uuid?

[Kyrre Aalerud]

Values change rapidly and bt_gatt_notify_uuid is called at 10ms interval while bluetooth connection is set up for 15ms connection interval.
I assumed this would simply queue up 1-2 notifications that would be delivered during a connection event, but instead application core hangs/crashes after repeated TX context failures.
Notified data is 12 bytes to full length UUID. Using SDK 1.6.0 atm.

[ovrebekk]

Hi Kyrre

That's interesting. Normally the notification calls should simply be blocking when the buffers fill up, but I haven't done much testing with the bt_gatt_notify_uuid(..) function. 

From where in the code are you calling this function?
Is it in a separate thread, or from interrupt context?

Have you tried with the regular bt_gatt_notify(..) function, to see if the issue is the same?

Best regards
Torbjørn

[Kyrre Aalerud]

I have this particular notify set up in a timer callback if a value has changed.
The callback is registered with the timer during setup.

[ovrebekk]

Hi Kyrre 

Any chance you could try using a thread instead?

Then you can make a simple while loop in the thread where you send an update, add some delay (optionally), and check if the data has changed before sending another packet. 

Setting up your own thread in Zephyr is very simple, as shown in the basic/threads sample. 

Best regards
Torbjørn

[Kyrre Aalerud]

Sure, we already use 6 threads. At full load we are still 97% idle. Interestingly we stopped getting crashes from the log system after switching to log v2.

[ovrebekk]

Hi Kyrre

Did you try it out?

It would be interesting to know if moving the bt_gatt_notify_uuid calls to a thread solved the issue. 

Best regards
Torbjørn

[Kyrre Aalerud]

No, it did not.
We still get the context issue. I did enable logging in the hci_rpmsg image for network core, and it does not log any faults as the application core fails.