Is the BLE stack free'd after each CyBle_ProcessEvents() call?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm running into an issue where I believe that I'm overflowing the BLE stack with notify events. I can't seem to find any documentation of if the BLE stack is processed and empty after every CyBle_ProcessEvents() call. 

   

I have a function that looks like this: 

   

 

   

    while(temp != NULL) {        

   

        if (CyBle_GattGetBusStatus() == CYBLE_STACK_STATE_FREE) {

   

            // This methods writes data to the GATT profile 
​            printEvent(temp);

   

            temp = temp->next;

   

        }

   

    }

   

 

   

So my understanding is that the only time my printEvent() function will be called only when the BLE stack is free....

   

However, after a few runs through this I start getting CYBLE_INVALID_OPERATION error. This is leading me to believe that the stack is overflowing somehow....

   

 

   

This question is working off of this one: http://www.cypress.com/forum/psoc-4-ble/extremely-weird-error-when-writing-gatt-notify#comment-36604...

0 Likes
1 Solution
Anonymous
Not applicable

The stack state is either busy or free depending on whether it is actually in the middle of performing some operation (e.g. receive or transmit). It isn't necessarily busy before a CyBle_ProcessEvents() call, and it isn't necessarily free afterwards. However, this is different from whether the internal packet transmission queue is full or not, which is not directly detectable with an API method. You have to rely in this case on the return value from API calls which would add a new packet to the transmission queue, such as CyBle_GattsNotification().

   

EDIT: It seems the stack state is at least intended to provide exactly this information. However, I haven't yet been able to identify all cases where the state is actually marked "busy," other than when you initiate an indication (acknowledged data push) with CyBle_GattsIndication().

   

I believe there is a pending internal BLE component update which addresses an issue where this API method incorrectly returns CYBLE_INVALID_OPERATION in some cases where it should return CYBLE_MEMORY_ALLOCATION_FAILED instead. I suggest that you treat either error as an indication that you need to retry sending the same packet again.

View solution in original post

0 Likes
2 Replies
Anonymous
Not applicable

The stack state is either busy or free depending on whether it is actually in the middle of performing some operation (e.g. receive or transmit). It isn't necessarily busy before a CyBle_ProcessEvents() call, and it isn't necessarily free afterwards. However, this is different from whether the internal packet transmission queue is full or not, which is not directly detectable with an API method. You have to rely in this case on the return value from API calls which would add a new packet to the transmission queue, such as CyBle_GattsNotification().

   

EDIT: It seems the stack state is at least intended to provide exactly this information. However, I haven't yet been able to identify all cases where the state is actually marked "busy," other than when you initiate an indication (acknowledged data push) with CyBle_GattsIndication().

   

I believe there is a pending internal BLE component update which addresses an issue where this API method incorrectly returns CYBLE_INVALID_OPERATION in some cases where it should return CYBLE_MEMORY_ALLOCATION_FAILED instead. I suggest that you treat either error as an indication that you need to retry sending the same packet again.

0 Likes
Anonymous
Not applicable

Gotcha. Thank you so much! 

0 Likes