• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 55 subscribers
  • Views 357 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.

CC2652R: DMM with BLE Peripheral + Ti15.4 Coordinator - how to send frames longer than 125 bytes

Michal Granda
Prodigy 62 points

Part Number: CC2652R

Tool/software:

Hello!

Initial information:

  • Sample: dmm_154collector_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos7_ticlang (with MAC security disabled)
  • SDK: simplelink_cc13xx_cc26xx_sdk_8_30_01_01

I am running a project based on sample project  "DMM 15.4 Collector + BLE Remote Display" and I have a need to send longer payloads than usual. Up until now I was fine with 125 bytes frame limit for the TI15.4 stack but that does not suit project needs any more. There is a need to send slightly longer payloads.

Problem 1

When trying to send longer payloads without any changes to project configuration I encountered an unexpected outcome: ApiMac_mcpsDataReq function returned quite expected result  (ApiMac_status_frameTooLong) but it resulted in heap corruption. And corruption in a very strange form - MCU started reporting to have more free memory than before. When multiple send attempts were made the free size exceeded total size of available heap memory.

Heap information was retrieved with ICall_getHeapStats

Q1: Is this an expected outcome that function returns proper error code but underlying implementation corrupts heap?

Problem 2

To resolve the issue with attempting to send frame of too big size I carefully read the available sources of the latest TI 15.4 stack (and some earlier releases where more files were available) and found a macro that can be set at compile time to allow for longer messages to be sent: MAC_MAX_FRAME_SIZE. I set this to 255 (I don't expect anything longer that 150 to be sent in real life scenario but wanted some room) and as expected no error was generated, ApiMac_mcpsDataReq returned success and no memory corruption happened when I attempted to send a message of length 120 bytes.

Unfortunately the message was NOT sent. I observed the traffic using a Ubisys dongle and Wireshark on the channel the network was formed on and nothing could be observed. I decided to play around with it and found out that the threshold payload length is 112 bytes. Anything above it will result in message not being sent.

Q2: Is this the correct way to enable TI15.4 stack to send longer payloads?

Reproduction

I could without problems reproduce the issue on the og sample project by simply attempting to send longer message. In my case I decided to modify the toggle LED request to not be 1 byte but instead 120 bytes. Receiving device does not really matter as the message is never sent as observed on the Wireshark

  • +1
    TI__Guru**** 223077 points

    Hello Michal,

    I assume that even though a DMM project is discussed, your questions center primarily around the TI 15.4-Stack and not Bluetooth LE.  You will find in a copy of the IEEE 802.15.4 2006 Specification (Section 6.4.1 PHY constants) that the max PHY packet size is 127 bytes, so this is not a parameter which can be exceeded by the TI 15.4-Stack solution.  Any difference between aMaxPHYPacketSize and MAC_MAX_FRAME_SIZE is due to packet header bytes.

    Thus packets which exceed this value should be thrown out by the TI 15.4-Stack library, hence the messages not being sent as you observed. The ApiMac_status_frameTooLong behavior is not expected and I'm not sure whether this happens due to being a DMM project as compared to standalone TI 15.4-Stack example.

    As this is a limitation of the IEEE Specification you will need to fragment the larger packet into two or more smaller packets, where the packets 2 to N are sent after confirmation of the previous packet having been sent out successfully (MAC_MCPS_DATA_CNF from the stack initiates dataCnfCB in the 15.4 application).

    Regards,
    Ryan