CC2642R: CC2340R5: system stuck when calling GATT_Notification

Hi Patrick,

Thank you for reaching out to us. We will take a look at your queries and get back to you as soon as possible. In the meantime, At a glance, if the issue happens after some time transmitting, I would check the memory consumption or the heap size to ensure we are not overflowing. Can you try changing the rate at which you send the notifications? Does varying the rate impact the time until the behavior occurs?

Best Regards,

Jan

After I added a debug message output next to the GATT_bm_alloc line, the traffic rate was slowed down and can run much longer about 20 minutes. Also, if I increase the FreeRTOS heap size form 0x5000 to 0x5f00, it can run a bit longer about 5 seconds.

The Peripheral_SendNotification function is triggered in BLEAppUtil_Task loop when mq_receive has no message received. It is implemented by setting attribute of the message queue io O_NONBLOCK so that the function can be called if no message in the queue.

Hi Patrick,

Thank you for reaching out.

All makes me think to a memory leak. 

May I kindly ask you to review the following lines?

    uint16_t len = txOctets - TOTAL_PACKET_OVERHEAD; // txOctets = 251
    attHandleValueNoti_t noti;

    noti.handle = 0x1e;
    noti.len = len;
    noti.pValue = (uint8 *)GATT_bm_alloc(connDevice.connHandle, ATT_HANDLE_VALUE_NOTI, GATT_MAX_MTU, &len);

It seems you allocate GATT_MAX_MTU (0xFFFF) bytes, but this value is not reflected on noti.len. I guess this could lead the stack to freeup an incorrect memory length.

I would humbly suggest to modify the code leveraging the following snippet:

    uint16_t len = txOctets - TOTAL_PACKET_OVERHEAD; // txOctets = 251
    attHandleValueNoti_t noti;
    bStatus_t status;
    
    uint16_t alloclen = 0;

    noti.handle = 0x1e;
    noti.len = len;
    noti.pValue = (uint8 *)GATT_bm_alloc(connDevice.connHandle, ATT_HANDLE_VALUE_NOTI, len, &alloclen);
    
    if(alloclen != len)
    {
        /* Memory allocation failed */

    }

I hope this will help,

Best regards,

Hi Jan,

This does not help. The symptom is exactly same as before.

Best Regards

Hi Patrick,

I think we need to look at the heap consumption here to get a better picture of what may be going on. Can you use the process detailed in the "Debugging Common Heap Issues" section of the Debugging guide packaged with the CC23XX 6.40 SDK installation (Found in {SDK}/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index-cc23xx.html). This section provides the process required for how to enable heap tracking and how to monitor the heap.

Best Regards,

Jan

Hi Jan, I will do and keep you updated. Thanks!

Hi Jan,

I have debugged it and figured out it is caused by a forever loop in heap_4.c. The free memory still has big enough.

The loop in heap_4.c is

You can see the pxNextFreeBlock always points to 0x20002900:

Hi Patrick,

Thank you for running this test and reporting back your results! I find it strange that we are finding a circular loop in the next free block structure. Can you share a picture of the call stack? To confirm, this loop is contained within the pvPortMallock() function correct? This will show us where we are calling this function and might provide us with some insight into why we may be getting stuck in this loop.

Best Regards,

Jan

Yes, It is in pvPortMalloc(). I am not sure if the below is the capture you want. If not, please let me know how to get it.

Hi Patrick,

Yes that is exactly what I was looking for. Are you calling GATT_bm_free() later on in your code in case the notification is not sent? Can you share the code for the Peripheral_SnedNotificaiton() function?

Best Regards,

Jan

The full code for sending the notification is already in my init post. As I mentioned in the init post, if the GATT_Notification is commented out, the issue can not be reproduced. So, I believe the root cause is in GATT_Notification.

Hi Patrick,

My apologies, I was looking at the code snippet in one of the replies. Does GATT_Notification() always return success even when we are leading up to the unexpected behavior?

Best Regards,

Jan

No, it does not always return success. Because it's configured to 5 packets per connection event, it returns failures after 5 successful transmissions. The following is the debug output I added after GATT_Notification() is called. 'd' means SUCCESS and 'f' FAILURE. At the end, it got stuck and stopped the output.

===== DEBUG LOG =====
dddddffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffdffdffdfffddddfdddddfddddddfdddddfdddddfdddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffddddfddddddfdddddfddddddfdddddfdddddfddddddfdffffdddddfddddddfdddddfdddddfddddddfdddddfdddddfdfffdfddddddfdddddfdddddfddddddfdddddfddddddfddddffffddfddddddfdddddfdddddfddddddfdddddfdddddfddddffffdddfddddddfdddddfdddddfddddddfdddddfdddddfdddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdddddfddddddfdddddfddddddfdddddfdddddfddddddffffdfddddddfdddddfddddddfdddddfddddddfdddddfddddffffdddfdddddfddddddfdddddfdddddfddddddfdddddfdddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdddddfdddddfddddddfdddddfddddddfdddddfdddddfdfffdfdddddfddddddfdddddfddddddfdddddfdddddfdddddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffddfddddddfdddddfddddddfdddddfdddddfddddddfdddffffddddfdddddfdddddfddddddfdddddfdddddfddddddfddffffddddfddddddfdddddfdddddfddddddfdddddfdddddfddfffffddfdddddfddddddfdddddfdddddfddddddfdddddfdddffffddddfddddddfdddddfddddddfdddddfddddddfdddddffffffddddfdddddfddddddfdddddfddddddfddddffdddfdfdfdfffdfdddddfddddddfdddddfdddddfddddddfdddddfdddddffffddfdddddfdddddfddddddfdddddfdddddfddddddfddddffffddfddddddfdddddfdddddfddddddfdddddfddddddfdddffffdddfddddddfdddddfdddddfddddddfdddddfdddddfdddffffddddfdddddfddddddfdddddfdddddfddddddfdddddfddffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfdfffdfdddddfdddddfddddddfdddddfdddddfddddddfdddddffffdfddddddfdddddfddddddfdddddfdddddfddddddfddddffffddfddddddfdddddfdddddfddddddfdddddfddddddfdddffffdddfddddddfdddddfdddddfddddddfdddddfdddddfdddffffddddfdddddfddddddfdddddfdddddfddddddfdddddfddffffdddddfdddddfdddddfddddddfdddddfdddddfddddddfdffffdddddfddddddfdddddfdddddfddddddfdddddfdddddfdfffdfdddddfddddddfdddddfddddddfdddddfdddddfdddddffffddfdddddfddddddfdddddfdddddfddddddfdddddfddddffffdddfdddddfddddddfdddddfdddddfddddddfdddddfdddffffddddfdddddfddddddfdddddfdddddfddddddfdddddfddffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfdfffdfdddddfdddddfddddddfdddddfdddddfddddddfdddddffffddfdddddfdddddfdddddfddddddfdddddfdddddfdddddffffddfdddddfddddddfdddddfdddddfddddddfdddddfddddffffdddfdddddfdddddfddddddfdddddfdddddfddddddfdddffffdddfddddddfddddffdddfddddddfdddddfddddddfddddffffddfdddddfddddddfdddddfdddddfddddddfdddddfddddffffdddfddddddfdddddfdddddfddddddfdddddfdddddfdddffffddddfdddddfddddddfdddddfdddddfddddddffddfddddffffdddfddddddfdddddfdddddfddddddfdddddfdddddfdddffffddddfddddddfdddddfddddddfdddddfdddddfddddddfdffffdddddfdddddfddddddfdddddfdddddfdddddfddddddfdffffdddddfddddddfdddddfdddddfddddddfddffffffffffffffffffdddfdddddfddddddfdddddfdddddfddddddfdddddffdffffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfdfffdfdddddfdddddfddddddfdddddfdddddfddddddfdddddffffdfddddddfdddddfdddddfddddddfdddddfdddddfdddddffffddfddddddfdddddfddddddfdddddfddddddfdddddfdddffffddddfdddddfddddddfdddddfdddddfddddddfdddddfddffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfdfffdfdddddfdddddfddddddfdddddfdddddfddddddfdddddffffdfddddddfdddddfddddddfdddddfdddddfddddddfddddffffddfddddddfdddddfdddddfdddddffdddfdddddfddddddffffdfddddddfddddfffffffffffffffffffffffffffffffffffffffffffffddfddddddfdddddfdddddfddddddfdddddfdddddffdddfdfffdfdddddfddddddfdddddfddddddfdddddfddddddfddddffffddfddddddfdddddfddddddfdddddfdddffffffffffffffffffffdddddfdddddfddddddfdddddfdddddfddddddfdddddfddffffdddddfdddddfddddddfdddddfddddddfdddddfddddddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdddfdddddfddddddfdddddfddddddfdddddfddddddfddfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffddfdddddfddddddfdddddfddddddfdddddfddddddfdddffffdddfddddddfdddddfdddddfddddddfdddddfddddddfddffffddddfddddddfdddddfddddddfdddddfddddddfdddddfdfffdfdddddfddddddfddddd

Hi Patrick,

Got it. Since we are configured to do 5 packets per connection event, then can you try adding a conditional statement in the Peripheral_sendNotification() function that keeps track of how many notifications have been sent since the last connection event and only queues up a notification if we have not sent 5 or more? I'm curious to see if that has an impact on the beahvior since it seems there are last stretches of time where there are repeated failures to send the notifications.

Best Regards,

Jan

Hi Jan,

To quickly sort out the issue, I would like to share our code to you. It needs 1 LauchPad-EM-CC2340R5 board and 2 LAUNCHXL-CC2640R2 boards. Could you setup the test environment on your side? If okay, please give me an email address so I can send you the code.

The code is not open-source and used internally for us to test the BLE performance.

Thanks!

Hi Patrick,

I have sent you a friend request. Please accept the request and then we can exchange emails via private messages.

Best Regards,

Jan

Thank you, Jan. I will send you the code after I organize the code and document it.

Hi Patrick,

Sounds good. I have sent you my email so we can take this discussion off of the forums.

Best Regards,

Jan

Hi Jan,

I seem to have encountered the same problem, could you please share the solution