[参考译文] CC2340R5：需要支持器件在循环期间卡在 iCall_POSIX 中。

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1653563/cc2340r5-support-required-for-device-stuck-in-icall_posix-while-loop

器件型号： CC2340R5

尊敬的 TI 团队：
我们目前在应用中面临一个关键问题。

在某些情况下、我们观察到我们的器件卡在 iCall_POSIX.c 内的 while 循环中一旦出现此问题、整个应用程序就会停止运行。我们已经注意到看门狗计时器也停止工作、似乎没有需要执行的任务。为了从这种情况中恢复、我们需要执行硬复位或实现软件复位机制。

我们想了解这类问题在什么条件下会发生。您能否就器件进入该状态的可能原因和建议的调试方法提供指导？

此外、我们还观察到了与 BLE 通信相关的另一个场景。在通过 GATT 层向连接的设备发送通知时、如果对等设备同时断开连接、则我们的应用有时会进入相同的 while 循环条件。在发送通知之前、我们正在验证所有连接参数。但是、由于在 GATT 通知过程中可能会发生断开连接、因此可能会导致出现此问题。

您能否提出处理这种情况的最佳实践建议？
在什么情况下器件可以进入 iCall_POSIX.c while 循环？
当同时发生断开连接时、应该如何安全地处理 BLE GATT 通知？
是否有任何建议的软件恢复机制来避免完全的器件锁定？

这个问题目前阻碍了我们的发展活动。您能帮助我们了解根本原因并提出解决方案吗？

此致、
Ratan Dalei

3 个月前

0 admin 3 个月前

TI__Guru**** 2937200 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

请告诉我您使用的是哪个版本的 SDK？

当您进入无限循环时、您是否可以使用调试器和中断、以便我们可以明确知道 iCall_POSIX.c 中的哪个函数是阻塞函数？

此致、
Lea

0 admin 3 个月前

TI__Guru**** 2937200 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Lea：

感谢您的答复。

SDK：simplelink_lowpower_f3_SDK_8_40_00_61

此问题是零星的、并非每次都发生。我们偶尔在多次操作后在自由运行模式下观察到这种情况。但是、目前我无法在调试时重现问题。

在下面共享的屏幕截图中、您可以看到发生问题时应用程序卡住的位置。

我们还观察到了一种情况、即在 GATT 层发送 BLE 通知时设备断开连接。由于 GAP 层需要一些时间来更新断开连接状态、因此似乎存在一个应用程序仍尝试发送数据的计时窗口。在这种情况下、我们看到代码进入 while 循环并卡住。

为了便于您参考、我还分享了以下相关代码。

//找出每个连接的最大 MTU 大小
status = linkDB_getinfo (pItem->connHandle、&connInfo)；
偏移= 0U；

while (status ！= bleTimeout)&&(status ！= bleNotConnected)&&(len > offset))
｛
//确定分配大小
uint16_t allocLen =(len - offset)；
if (allocLen >(connInfo.MTU -(uint16_t) ATT_OPCODE_SIZE + 2U))
｛
//如果 len > MTU 将数据拆分为 MTU 大小的块

allocLen = connInfo.MTU -(uint16_t) ATT_OPCODE_SIZE + 2U；
}

/*在 BLE 通知期间特意更新“noti.len“
*数据包准备和分段处理。重新分配
*是正常通知缓冲区管理流程的一部分。
*/
Noti.len = allocLen；

Noti.pValue =(uint8 *) GATT_BM_alloc (pItem->connHandle、ATT_Handle_Value_Noti、allocLen、0)；
if (Noti.pValue ！= NULL)
｛
//如果分配成功、请复制数据并发送
if (Noti.len！= 0u)
｛
(void) memcpy (Noti.pValue、&pValue[offset]、Noti.len)；
}
noti.handle = pAttr->handle;

//通过 BLE 通知发送数据

状态= GATT_Notification( pItem->connHandle,&Noti, false );

//如果无法发送数据、则释放分配的缓冲区并返回
if (status ！= success)
｛

GATT_BM_FREE ((gattMsg_t *)&Noti、ATT_Handle_Value_Noti)；

}
暴露
｛
//递增数据偏移
Offset += allocLen；

}

此致、
Ratan

0 admin 3 个月前

TI__Guru**** 2937200 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

我很有信心,你描述的问题类似于 BLE_Loki-2493 在 SDK 9.10.00.83 版本中修复的问题: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/9.10.00.83/exports/docs/ble5stack/release_notes_ble5stack_9_10_00.html#fixed-issues

TT 中的注释描述了类似的情形、其中：
-问题并不总是发生（需要 30 分钟的压力测试才能重现）,并且是设备发送通知/指示时断开连接之间的时间问题
-症状是设备卡在 GATT_Notification 函数中

您能否尝试升级到最新的 SDK 并查看问题是否仍然存在？

此致、
Lea

0 admin 3 个月前

TI__Guru**** 2937200 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Lea：

感谢您的建议。我们将评估最新的 SDK、并检查是否仍然可以重现问题。

不过、我想表达一个关切。每当我们遇到问题时、建议通常迁移到更新的 SDK 版本。由于 TI 会定期发布 SDK 更新、除非明确找出并了解根本原因、否则很难将仅 SDK 迁移视为完整的解决方案。

我们当前的项目基于 SDK 版本 simplelink_lowpower_f3_SDK_8_40_00_61、其中一些产品即将上市。在此阶段迁移到新的 SDK 将需要大量的验证和回归测试工作。

对于我们当前的开发工程、我们可以考虑迁移到最新的 SDK。但是、仅靠 SDK 迁移并不能帮助我们了解问题的实际根本原因。由于问题是零星的、因此很难确定问题是已真正解决、还是只是在测试期间没有发生。

此致、
Ratan

0 admin 3 个月前

TI__Guru**** 2937200 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

在本例中、我们发现了与您的问题非常相似的问题、该问题已在 SDK 中识别和修复。在内部、我可以访问已解决此问题的 BLE 堆栈的合并请求。

如果将来您发现自己由于时间限制或由于版本差距过大而无法升级 SDK、我们也可以为您提供修复代码、以便您可以将其自行应用到 SDK 中、而无需进行升级带来的所有其他更改、如果 BLE 库中出现问题、您无法自己更改代码、我们也可以生成补丁 SDK。

但在这种情况下、即使我们要生成修补程序、测试问题仍然存在。我们确定了一个可能的修复方法,它的症状与您所面临的 bug 相似,唯一要确定的方法是测试修复程序是否在您的最终工作

如果您在升级 SDK 后仍然遇到问题、请随时更新。

此致、
Lea

Bluetooth®︎（参考译文帖）

Bluetooth®︎（参考译文帖）(Read Only)

[参考译文] CC2340R5：需要支持器件在循环期间卡在 iCall_POSIX 中。