BLE stack busy prevents notification sending

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

cross mob
JaEl_4231596
Level 1
Level 1

Hi,

I've been working on a project that uses two PSoC 6's to send notifications (492-byte data packet) at a constant rate of 1.2Mbps. I'm currently using a connection interval of 25ms and have "LE 2 Mbps" and DLE enabled and I am running the complete Bluetooth device on the CM0+ with a reduced clock speed of 32MHz. I'm having a problem sending notifications at a consistent interval to achieve a throughput of 1.2Mbps. Every once in a while, there will be a "break" in the notification sending that will prevent my data from going through. I sent a signal high every time CY_BLE_EVT_STACK_BUSY_STATUS happened in my event handler and low when the stack freed. I know the stack needs to be busy at some points in time, but I'm curious as to exactly why the stack becomes busy and if I can control/adjust the timing so that I can send notifications at a more consistent interval. I'm also wondering if the rate at which you call Cy_BLE_ProcessEvents() affects how quickly the stack frees up.

The code I'm using to send the notifications:

for(;;)

    {

        for(bufferCnt = 0; bufferCnt < SUPER_BUFFER_SIZE;)

        {

            //

            bufferPtr = (totalBuffer + (SUB_BUFFER_SIZE * bufferCnt));

           

            //Process BLE Events

            Cy_BLE_ProcessEvents();

           

            if(charNotificationEnabled == true)

            {

                if(ADCON == 1)

                {

                    if (*bufferPtr == 1)

                    {

                        updateNTFPacket();

                        while(Cy_BLE_GATT_GetBusyStatus(appConnHandle.attId) != CY_BLE_STACK_STATE_FREE)

                        {

                            Cy_BLE_ProcessEvents();

                        }

                        if(Cy_BLE_GATT_GetBusyStatus(appConnHandle.attId) ==\

                           CY_BLE_STACK_STATE_FREE)

                        {

                            Cy_GPIO_Write(BUSYFLG_PORT,BUSYFLG_NUM,0);

                            Cy_GPIO_Write(BLEFLG_PORT,BLEFLG_NUM,1);

                            /* Send notification data to the GATT Client*/

                            Cy_BLE_GATTS_Notification(&notificationPacket);

                            Cy_GPIO_Write(BLEFLG_PORT,BLEFLG_NUM,0);

                        }

                    }

                }

            }

        }

    }

I sent some signals high to see when notifications were being sent/received and when the stack was busy. The devices normally behave like this:

pastedImage_10.png

Yellow signal goes high when notification is sent

Blue signal goes high when notification is received

Pink signal goes high when stack is busy

Green signal goes high when throughput is too slow

Every once in a while (15 minutes or so) they will behave like this:

pastedImage_7.png

Any information on the busy stack status or how I can reduce or eliminate the "breaks" in notification sending would be greatly appreciated!

Thanks

-Jack

0 Likes
1 Solution
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello Jack,

Please refer to the below points:

1. CY_BLE_STACK_STATE_BUSY indicates to the application that the BLE Stack's internal buffers are about to be filled, and the remaining buffers are required to respond to the peer BLE device. After this event, the application shall not initiate GATT, GAP Security, or L2CAP data transactions. However, the application shall respond to peer initiated transactions to prevent BLE protocol timeouts. Application initiated data transactions can be resumed after the CY_BLE_EVT_STACK_BUSY_STATUS event with parameter 'CY_BLE_STACK_STATE_FREE' is received.

2. CY_BLE_STACK_STATE_FREE indicates to the application that pending transactions are completed and sufficient buffers are available to process application-initiated transactions. The 'CY_BLE_EVT_STACK_BUSY_STATUS' event with 'CY_BLE_STACK_STATE_FREE' indicates to the application that whether the BLE Stack's internal buffer state has transitioned from 'CY_BLE_STACK_STATE_BUSY' to 'CY_BLE_STACK_STATE_FREE'.

3. To increase the BLE Stack's default queue depth(CY_BLE_L2CAP_STACK_Q_DEPTH_PER_CONN) and achieve better throughput for the attribute MTU greater than 32, use the AddQdepthPerConn parameter in the 'Expression View' of the Advanced tab in the BLE component GUI. To Access the 'Expression View', right click on the 'Advanced' tab in the BLE Component GUI and select the 'Show Expression Vew' option.

4. The Cy_BLE_ProcessEvents() must be called continuously, this function will checks the internal task queue in the BLE stack and processes any pending BLE operations. This function must be called at least once every ‘T’ intervals, where ‘T’ is equal to the Connection Interval or Scan Interval (if the device is a GAP Central), or the Connection Interval or Advertisement Interval (if the device is a GAP Peripheral) whichever is smaller.

5. It is recommended to monitor the BLE stack status continuously and whenever we get status as free please call the send notification API(Cy_BLE_GATTS_Notification) followed by Cy_Ble_ProcessEvents() API. You can also use a timer for calling the Send notification API for every timer intervals.

Thanks,

P Yugandhar.

View solution in original post

0 Likes
3 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello Jack,

Please refer to the below points:

1. CY_BLE_STACK_STATE_BUSY indicates to the application that the BLE Stack's internal buffers are about to be filled, and the remaining buffers are required to respond to the peer BLE device. After this event, the application shall not initiate GATT, GAP Security, or L2CAP data transactions. However, the application shall respond to peer initiated transactions to prevent BLE protocol timeouts. Application initiated data transactions can be resumed after the CY_BLE_EVT_STACK_BUSY_STATUS event with parameter 'CY_BLE_STACK_STATE_FREE' is received.

2. CY_BLE_STACK_STATE_FREE indicates to the application that pending transactions are completed and sufficient buffers are available to process application-initiated transactions. The 'CY_BLE_EVT_STACK_BUSY_STATUS' event with 'CY_BLE_STACK_STATE_FREE' indicates to the application that whether the BLE Stack's internal buffer state has transitioned from 'CY_BLE_STACK_STATE_BUSY' to 'CY_BLE_STACK_STATE_FREE'.

3. To increase the BLE Stack's default queue depth(CY_BLE_L2CAP_STACK_Q_DEPTH_PER_CONN) and achieve better throughput for the attribute MTU greater than 32, use the AddQdepthPerConn parameter in the 'Expression View' of the Advanced tab in the BLE component GUI. To Access the 'Expression View', right click on the 'Advanced' tab in the BLE Component GUI and select the 'Show Expression Vew' option.

4. The Cy_BLE_ProcessEvents() must be called continuously, this function will checks the internal task queue in the BLE stack and processes any pending BLE operations. This function must be called at least once every ‘T’ intervals, where ‘T’ is equal to the Connection Interval or Scan Interval (if the device is a GAP Central), or the Connection Interval or Advertisement Interval (if the device is a GAP Peripheral) whichever is smaller.

5. It is recommended to monitor the BLE stack status continuously and whenever we get status as free please call the send notification API(Cy_BLE_GATTS_Notification) followed by Cy_Ble_ProcessEvents() API. You can also use a timer for calling the Send notification API for every timer intervals.

Thanks,

P Yugandhar.

0 Likes

Hi P Yugandhar,

I appreciate your response. I changed the BLE stack's queue depth (increased by 30 on both GAP central and peripheral), which seemed to allow the stack to stay free more frequently and allow for sending of notifications at a consistent interval. I'm still having trouble on the receiving end (GAP Central). Even though the notifications are being sent at a consistent interval, there are still large "breaks" (25ms+) in the reception of the notifications which cause my throughput to plummet below what is necessary. Is the receiving of notifications failing? I am continuously running Cy_BLE_ProcessEvents() on the GAP Central CM0+ core. Again, any answers to why this is happening would be greatly appreciated.

pastedImage_0.png

Yellow signal goes high when notification is received

Blue signal goes high when notification is sent

Pink signal goes high when stack is busy (peripheral)

Green signal goes high when throughput is too slow

Thanks!

- Jack

0 Likes

Hello Jack,

1. Please make sure that the BLESS interrupt has the highest priority i.e., the priority should be 0.

2. If any custom function consumes more time for execution, call Cy_BLE_ProcessEvents() inside it.

Thanks,

P Yugandhar.

0 Likes