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.

CCS/CC2650STK: Why I can't make MTU more than 23 bytes?

Part Number: CC2650STK
Other Parts Discussed in Thread: CC2640

Tool/software: Code Composer Studio

Hi, everyone

I am using CC2650STK with BLE_SDK_2.2.2.25. My program is based on simple_peripheral. And I can't send packets with length more then 22 bytes.

I made all the changes as recommended in "SWRU393_CC2640_BLE_Software_Developer's_Guide.pdf":

MAX_PDU_SIZE                  255

MAX_NUM_PDU                   5

-DBLE_V42_FEATURES=EXT_DATA_LEN_CFG

And I use HCI_LE_WriteSuggestedDefaultDataLenCmd(APP_SUGGESTED_PDU_SIZE , APP_SUGGESTED_TX_TIME);

and HCI_LE_SetDataLenCmd.

Client device (Android) execute GATT_ExchangeMTU().

In BT logs on Android  I see, that  MTUReq is 251 but MTUResp from Sensortag is 23... It is imaged on attached picture.

And  one important thing else, HCI_LE_WriteSuggestedDefaultDataLenCmd return 0x01 (failed)... I don't know why...

Earlier HCI_LE_WriteSuggestedDefaultDataLenCmd returned 0x04 (MSG_BUFFER_NOT_AVAIL),  when I used AUTOHEAPSIZE. But now I use HEAPMGR_SIZE=6300.

Why return this function this error? What am I doing wrong?

Thanks in advance,

Karlin  Egor

  • Hi,

    I would recommend to take a look at software developer's guide section 9.6 Profiling the ICall Heap.
    It could be you are running out of heap.
  • Hi,

    Now I am using AUTOHEAPSIZE. HEAPMGR_SIZE = 7316. HCI_LE_WriteSuggestedDefaultDataLenCmd return 0x01 (failed).
    pArray = (uint8_t*)ICall_malloc(255) work correct. But maxLen in simpleProfile_ReadAttrCB() is 22.

    1) Why don't work HCI_LE_WriteSuggestedDefaultDataLenCmd()?
    2) Why maxLen is 22?
    3) What should I do to maxLen will more then 22?

    Thanks in advance,
    Egor
  • Hi,

    When you set Data length to be 255bytes, it allocates more than that

    Both the transmit and receive buffers are allocated based on the respective PDU sizes negotiated for each connection. By default, 4 RX buffers is used per connection, that means when you set PDU to be 255, the extra heap required will be 4*255* (number of supported connection).
  • Hi,

    hmm okay. If I reduce number of buffers and connections, so I will need smaller heap size. It can work, if problem tied with heap size. I will try this solution.

    But I have some questions. Why number of buffers is 4? Can I use only 1 buffer and what consequences will it give?

    Egor
  • The number of RX buffer can't be changed as as a receiver, you will not know how many packets the sender is going to send during one connection.