工具与软件：
对于 TI 工程师来说、可能需要考虑这个问题、因为我们不确定相关的代码是否是开源的。。 [基于 SimpleLink 低功耗 F3 8.10.1.2 ]
场景：CC2340R5充当 UART <>BLE 桥、MTU 协商以允许最大 GATT Notify 负载244字节、每秒大约100帧。 该代码基于 DATA_STREAM_UART_OVER_BLE 示例。 只要不将任何东西连接到器件就不会出现问题-它将无限期运行、按照正确地切换每个到达 UART 的帧的 LED (但很明显、没有任何地方可用)。 连接后、它将继续正常工作-直到信号强度降低到无法再进行通信的程度。 此时堆栈会崩溃。
反向跟踪显示：
BLE4.12.7() Util_Task
SendUARTOverBLE ()
dsp_sendData ()
DSS_SetParameter()
DSS_sendNotification()
iCall_directAPI ()[GATT_Notification ()用索引258]定义到 iCall_directAPI ()
iCall_abort ()由于 iCall_waitMatch ()返回 ICALL_errno_timeout。
当然、iCall_abort ()不返回、因此可有效地结束 BLE 任务。 再次增大信号强度并手动允许 ICall_abort 在调试器内返回不能解决问题、器件仍"无效"(即没有进一步的 LED 活动和广播、尽管 FreeRTOS 仍为任务切换)。
我的直觉是、堆栈无法处理新数据、因为没有任何连接事件可以排空排队的通知、但它似乎并不能从容地出现故障。 也不清楚如何从这种情况中顺利恢复(从 iCall_abort()返回不起作用)。 对于我来说,栈可以优雅地说"不,不能这样做",抛弃通知,断开连接,回到广告,等待新的连接。 理论上,如果 GATT_Notification ()返回的结果不是成功,DSS_sendNotification ()会释放() malloc ()内存,因此不会有任何内存泄漏,但它当然不会返回。
非常感谢所有的帮助。
非常感谢
Patrick Herborn。
