Thread 中讨论的其他器件： CC2640、 CC2650、 CC2541、 BLE-STACK
似乎存在内部 TI 堆栈错误(这是1.4.2.2中的错误)。 堆栈)、其中断开连接有时会进入没有挂起计时器或事件的顶级 OSAL 运行循环、因此会进入深度睡眠(HAL_SLEEP_DEEPH、即 PM3)、从而停止广播。 如果使用外部中断从睡眠状态唤醒、则会获得预期的 GAP_LINK_TERMINATED_EVENT、最终导致调用带有 GAPROLE_WAITIN 的 peripheralStateNotificationCB、指示已断开连接、但广播尚未开始。 然后、广播开始、一个按 预期移动到 GAPROLE_advertising.状态。
仅当没有挂起的计时器或事件时、才会发生此错误、因此要重现此错误、必须禁用周期性事件(请参阅 SBP_PERIODICY_EVT_PERIOD 和 SBP_PERIODICY_EVT)、例如至少注释掉 SimpleBLEPeripheral_ProcessEvent 函数中的第一个 osal_start_timerEx 调用。 然后、用户可以使用 LightBlue iOS 应用(或您选择的任何其他应用)重复连接、然后断开连接(返回显示设备的主屏幕)、在执行此操作大约10到30次后、用户将看到广播永久停止的情况。 在正常断开连接时，有时广播会立即开始，而在其他时候，重新开始之前需要几秒钟，但故障的症状是，无论等待多长时间，它都不会再次广播-- 甚至远远超过6秒的监控超时时间、或者在关闭 LightBlue 应用或关闭手机电源后。
CC2540进入深度睡眠状态后、只能通过下电上电或外部中断将其唤醒。 然后、通过使用外部中断、我们看到断开消息将会通过。 最初、我们以为问题只是进入深度睡眠(HAL_SLEEP_DEEP_PM3或 PM3)、但将其更改为进入定时睡眠(HAL_SLEEP_TIMER 或 PM2)不起作用、因为显然尚未设置射频计时器。 这可能是竞争条件、在任务通风口检查完成后、如果 TI 始终设置计时器、则设置用于设置此类计时器的事件 (即、如果在广播计时器启动之前未停止连接间隔计时器、或者至少在同一过程中完成这两件事情、而这两件事未返回主等态运行循环)、则不可能出现竞态条件。
针对这种情况的一种权变措施是具有周期性事件(即不执行任何操作、例如每5秒一次)、因为我们已验证这将强制唤醒、然后用于广播的射频计时器/事件将按预期工作、 但这是一种权变措施、TI 应该修复此错误。
