[参考译文] CC2340R5：如何在两个 CC2340R5器件之间交换 GATT 数据包？

尊敬的 Aki：

感谢您评估 CC2340R5并将您的问题发布到 E2E 论坛！  TI 的所有 BLE E2E 论坛专家都将 在8月30日(星期五)休息、他们将按收到的顺序和优先级返回到应答论坛帖子。  在此之前、您可以进一步考虑以下一些资源、这些资源可以独立解决您的问题：

• 在 E2E 论坛上搜索相关问题
• 在 BLE5-Stack 用户指南中找到主题描述
• 读取  涵盖类似行为的 SimpleLink SLA

如果您找到问题的解决方案、请回复此 E2E 帖子！  否则、 感谢您  提供的所有调试信息 、以便在 BLE E2E 专家返岗时为他们提供最佳的支持。

此致、
Ryan

您好、Ryan、

感谢您的答复！ 我可以使用 TI 在 GitHub 上公开提供的开源代码解决先前的问题。
https://github.com/TexasInstruments/ble_examples

但是、我遇到了一个新问题。 我正在中央设备以无限循环的方式重复发送 GATT 数据包、但由于中央设备崩溃、连接在大约8次迭代后断开。 每次我重新连接并再次运行无限循环时、都会出现此问题。 您能帮助我了解导致此问题的原因吗？

下图显示了app_menu.c我根据 GitHub 上的 TI 开源代码修改后中的代码。

下图显示了我使用监听器监测数据包观察到的结果。 理想情况下、这两个器件应该能够无限地交换 ATT 数据包。 但实际上、在大约八次交换之后、连接会断开。

外设 UART

谢谢你。

今天的更新:即使使用函数GATT_bm_free()释放内存,崩溃的问题仍然存在。

您好！

感谢您联系我们！ 很高兴您取得了进步！ 我建议不要以这种方式实现功能。 相反、我建议利用发送数据包时返回的事件对后续数据包进行排队。 您可以使用全局变量来确定是否要发送新数据包、而不是使用无限的 while 循环。

此致、

1月

您好！

感谢您的建议！ 我现在删除了Menu_doEnableNotification()内的无限循环 app_menu.c

而且,根据你的建议,我 打电话Menu_doEnableNotification(1)在ATT_HANDLE_VALUE_NOTI情况中app_data.c.

我还打印一个计数器、用于跟踪发送的 GATT 数据包数。 但是、在发送大约162个数据包后、传输停止、但 CC2340R5不会像之前那样崩溃或断开。

该监听器还显示ATT_WRITE_CMD数据包总共传输了大约162次。

您能说明为什么会发生这种情况吗？

您好！

很高兴听到这种行为似乎有所改善！ 您是否可以尝试重新启动通知以查看是否发送了更多数据包？ 器件是否在响应？ 您仍然可以操作菜单吗？

此致、

1月

您好！
当我重新启动通知时、我通过监听器观察到通知不会再次发送。 其他类型的 ATT 数据包(例如 ATT_WRITE 和 ATT_READ)也无法发送。 通过调用状态返回的值不是0而是23、这似乎表示发送失败。

但是、仍然正常发送链路层数据包、例如 LL_encryption_req 和 LL_para_update_req。