blecm_getAvailableTxBuffers() usually precede bleprofile_sendNotification() so as to ensure that there are available Tx buffers. As pointed by Victor, you may want to check out this part of the code in the speed_test app
You may also check following thread:
try the solution by esmith:
Thanks for suggestion, KT. The speed test example tests for the tx buffer count being non-zero, which does mean that it can (temporarily) tie up the last buffer. Yesterday I added a #define to my code to set a threshold, currently with a value of 2, and if I don't send notifications unless the available buffer count is >= 2, I don't see any of the lel2cap error messages in the trace output. I think this confirms that something else in the stack needed a buffer and I was starving it. Perhaps in a future SDK release Broadcom might wish to make this change to the speed_test application to avoid other developers encountering the same issue.
Does Esmith mean that, it's recommand to call bleprofile_sendNotification() when the TX buffer size is over 2 ?
Now our setting is over 0.
Pls help confirm. Many thanks...
Yes. Stop calling bleprofile_sendNotification() when size of free tx buffer decreased to 2.
Resume to send notification after the size of free tx buffer >=2.
Got it, tks...