• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1053 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: RTOS/CC2640

Nicole Wu
Prodigy 50 points
Part Number: CC2640


Tool/software: TI-RTOS

 

Hello


I use CC2640 to develope BLE central device and use 3-party chip (Dialog )to be BLE peripherl device.
I use cc2640 to upgarde BLE peripheral device and need upgrade several devices continuously.


I try to write 240bytes to peripheral device one time and repeat around 145 times per device for upgrading FW image.
Somehow if gateway upgrade 7-8 devices continuously, gateway would receive msg_buffer_not_avail error message.
And gateway could not upgrade any other devices with receiving the same error message.
 

Please refer to the following code .

req.pValue = GATT_bm_alloc(connHandle, ATT_WRITE_REQ, 240, NULL);
retVal = GATT_WriteNoRsp(connHandle, &req);

 

Afer increasing MAX_PDU_SIZE as 255 and modify MAX_NUM_PDU to 6,
The best total for upgarde pherial deives is around 170 devices,
And gateway still get the same error message (msg_buffer_not_avail), the following devices could not be upgrade.

For my project need use CC2640 upgrdae around 2000 peripheral devies.

Please help on the issue, thank you
 

  • 0
    TI__Guru 56590 points
    Hello Nicole,
    APIs that allocate memory (such as GATT_bm_alloc()) allocate memory from the ICall heap. You need to profile your heap usage which will be limited by RAM size. This heap is also shared with the Bluetooth low energy protocol stack and therefore there need to be some free space to the stack to operate correctly.

    If GATT_bm_alloc return NULL you should implement some form of back-off to allow the heap to recover some free space before you try to allocate more messages.

    Please see "3.11.4 Dynamic Memory Allocation" and "9 Development and Debugging" section in SWRU393, specifically the section for profiling the ICall heapmgr.
  • 0 in reply to Eirik V
    Prodigy 50 points

    Hello Eric

    The following is my source code. And I did free memory via GATT_bm_free API if GATT_WriteNoRsp fail.
    SWRU393 mention that use GATT_bm_free() to free the memory if the return value is something other than SUCCESS (for
    example, blePending). (5.3.5 Allocating Memory for GATT Procedures)
    But the gateway still get the same error message MSG_BUFFER_NOT_AVAIL after upgarding fw to serveral peripheral devices.


     retVal = GATT_WriteNoRsp(connHandle, &req);

    if (retVal != SUCCESS)
    {
    GATT_bm_free((gattMsg_t *) &req, ATT_WRITE_REQ);

    DEBUG("FAIL FROM CLIENT: ");
    }
    else
    {
    DEBUG("Write Patch Data OK\n\r");

    }

    Gateway would disconnect when writing data fail , the scenario was implemeted for error handling.

    I also upload sniffer log for you help check, thank you.


    MSG_BUFFER_NOT_AVAIL.psd
     

  • 0 in reply to Nicole Wu
    Prodigy 50 points

    Hello  Eirik,

    Any suggestion for the issue ? thank you.