工具与软件：
您好！
初始信息：
- 示例： dmm_154collector_remote_display_app_2_4g_CC26X2R1_LAUNCHXL_tirtos7_ticlang (禁用 MAC 安全性)
- SDK： simplelink_cc13xx_cc26xx_sdk_8_30_01_01
我正在根据示例项目 "DMM 15.4 Collector + BLE 远程显示"运行一个项目、我需要发送比平常更长的有效负载。 到目前为止、我完全支持 TI15.4堆栈的125字节帧限制、但这不适合项目需要的更多。 则需要发送稍长的有效负载。
问题1.
当尝试在不对项目配置进行任何更改的情况下发送更长的有效负载时、我遇到了意外的结果： ApiMac_mcpsDataReq 函数返回完全预期的结果 ( ApiMac_STATUS_frameTooLong )但它导致堆损坏。 和腐败一种非常奇怪的形式- MCU 开始报告具有比以往更多的可用存储器。 当进行多次发送尝试时、空闲大小超过了可用堆内存的总大小。
使用检索堆信息 iCall_getHeapStats
Q1:这是函数返回正确错误代码但底层实现破坏堆的预期结果吗?
问题2.
为了解决尝试发送过大帧的问题、我仔细阅读了最新 TI 15.4 Stack (以及一些早期版本中提供的更多文件)的可用源代码、并发现了一个可以在编译时设置以便发送更长消息的宏： MAC_MAX_FRAME_SIZE . 我将其设置为255 (在现实场景中、我不希望再发送150、但希望有一些房间)、并且正如预期的那样、没有生成错误、 ApiMac_mcpsDataReq 当我尝试发送长度为120字节的消息时、返回成功并且未发生内存损坏。
很遗憾、消息未发送。 我使用 Ubisys 软件狗和 Wireshark 在网络形成的通道上观察到流量、但没有发现任何情况。 我决定尝试一下、发现阈值有效载荷长度为112字节。 高于此值的任何内容都将导致无法发送消息。
Q2：这是否是让 TI15.4堆栈发送更长有效负载的正确方式？
复制
通过尝试发送更长的消息、我可以在 OG 样例项目上毫无问题地重现问题。 在本例中、我决定将切换 LED 请求修改为不是1个字节、而是120个字节。 实际上、接收设备并不重要、因为从不会像在 Wireshark 上看到的那样发送消息
