This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC2640: Determine number of notifications in Bleutooth stack

Part Number: CC2640

Tool/software: TI-RTOS

We have an application that sends timed sensor messages over BLE.

It will occur that the connection is lost, and we provided a buffer mechanism to make sure not all messages are lost.

So when connection is re-established, the buffered data is sent over BLE. This will completely fill the BLE stack buffers.

We now that 5  - 15 messages will be committed to the stack (because if we disable notifications, we loose this amount of messages)

How can we check the number of messages in the stack buffers? We don't need to put in 5 - 15 at a time, 2-5 should be enough. As a consequence, the stack can also handle other notifications (like battery low notifications), which now are often lost due to heap malloc not succeeding.

Currently we see heapmgrSanityCheck sometimes not returning 0. (not triggered immediately after the stack is full, but is happens fairly quickly but unpredictable during unit testing)

  • Hello Herwin,

    Unfortunately, the BLE specification does not define such an interface to peek at the HCI buffers in the controller. If you need a more reliable method to know that your PDU has been transmitted and received, it's recommended to use Indications which provide a confirmation.

    If you are seeing heap issues, I would reduce the MAX_NUM_PDU define to prevent the enqueuing of too many PDUs or exhausting your heap. You could also use the HCI Extension connection event callback to determine if you can enqueue a new Notification. If the API status is SUCCESS that means one or more Notifications were sent by the controller in the previous conn event.

    Best wishes
  • So there is no easy way to use the Heap metrics to check for available storage?

    I will check your suggestions, and do some tests with it. I will certainly check the connection event callback, maybe I can add some checks there.