【应用笔记】LAT1413+快速开关蓝牙导致设备无广播

1. 问题背景

客户使用 BlueNRG-345MC 开发了一个 BLE 外设，和手机连接。在测试中发现，手机连接上外设之后，不断地在手机上点击蓝牙的开关按钮，造成设备不断地断开、重连；少则几次，多则几十次。点击之后，必然出现 BLE 外设无广播信号的现象。该问题已经得到了解决。本文将展开聊聊该问题的解决过程和思路，并就该问题总结、分享一些 BLE 连接过程的处理经验。

2. 定位问题

拿到该反馈描述后，第一时间和客户沟通了几个问题，明确了大概的方向。沟通的思路按照：硬件问题、软件问题？硬件问题是和设备相关，板子相关、还是芯片相关？软件问题根据设备类型，是和 APP 相关、手机系统相关、BLE 主机固件相关、还是 BLE 外设固件相关这样的思路进行排查。通过以下问题，粗略地进行问题的定位：

“对端设备是什么，如果是手机的话，是否有 APP？“——对端是手机，并且有配套的APP。该问题确定了设备类型，和软件类型。

“该问题是否必现，且稳定复现，问题出现后，状态是否能保持？“——问题稳定复现且必现，而且状态能保持，这是一个重要的依据，由此依据，我们可以进一步发问：

“杀死配套 APP 的后台，用其它手机、第三方 APP（BLE 调试助手等）是否能搜到设备的广播信号“——杀死配套 APP 的后台，确保设备断连、处于广播状态，然后通过第三方的手机、APP 搜索设备的广播，确定当问题出现后，出现异常的是主机方、还是从机方。客户反馈第三方 APP 搜索不到该设备，说明此时从机方出现了异常且保持在异常状态中。

“问题出现后，设备是否还能正常运行“——确定了从机方出现异常后，我们需要进一步定位该异常。该问题可确认问题是局部问题，还是系统问题。如果此时系统还能正常运行（比如，有 LOG 输出，有 LED 闪烁，有按键反应等），就说明是局部问题，系统还没死机。客户反馈系统还正常，这真是一个好消息！蓝牙问题最怕是系统性的问题，即因为系统奔溃，导致的蓝牙奔溃，如果是系统性的问题，那可能性就多很多了，丢给客户的问题就可能包括：

“是否和低功耗管理有关，关掉低功耗试试？”
“是否和特定板子有关，换块板试试？”
“是否和供电稳定性有关，用直流电源试试？电量低是否更容易复现？”……

既已确定了是局部蓝牙的问题，那么，如果对蓝牙的 LL 状态机和基本的 GAP 流程熟悉的话，那基本就可以通过这个问题来定位该问题了：
“请仔细检查下用户层的操作逻辑，是否能确保蓝牙断连时，必能调用使能广播的 API，且拿到成功的状态返回？”——客户拿到该问题后，不知道从何下手，于是，现场支持。

3. BLE 背景知识

话接上文，解决该问题需要对 LL 状态机和 GAP 流程有一定的了解。本章节便先对相关背景知识先做一个补充陈述。
蓝牙链路层（Link Layer）的运转过程可通过一个状态机进行描述。蓝牙从机的状态机简单描述如下：
图1. LL 状态机
在这里插入图片描述
对于该状态机的理解，需要注意以下几点：

• 设备断开连接之后，LL 层进入的是 Standby 状态，而不会自动重新发起广播，此时必须由 Host 主动启动广播才能让设备被主机搜索到。
• 设备处于 Standby 状态时，必须先进入广播状态，才能由此进入连接状态。对于从机，如果设备不进入广播状态，即使主机发起回连，也不可能被连接成功。
• 广播中的设备，当它被上层停止广播、或者被主机连接时，便会退出广播状态。此处需要注意的是，当链路建立，协议栈会将链路建立事件层层上传，其中，就包括 GAP层。GAP 层在接收到链路建立事件之后，便会开始执行一系列的流程……

这些流程包括，特性交换流程，MTU 交换流程，连接参数更新流程，安全流程（配对流程、绑定流程、加密流程），GATT 服务发现流程等。刚连上那会的几秒钟，是 BLE 外设最繁忙的时间段，也是最容易出现问题的时间段。有经验的工程师，一般都会将一些时间敏感的任务的处理，和这段时间段进行错开。下面的序列图描述了这一过程：
图2. GAP 序列图
在这里插入图片描述

从图中可知，从机协议栈遵循 LL 状态机的运转流程，在三个状态中切换；用户层在断开回调函数中，必须稳妥地开启广播，才能让协议栈从机的状态机按照我们的预期运转。

4. 解决问题

相信通过 BLE 背景知识的介绍，部分人已经大概了解了问题的原因了。到达客户现场调试时，通过蓝牙抓包器、并让客户当场复现问题，我把蓝牙主、从机的空中交互过程记录下来。仔细观察抓包器的记录过程，发现当问题发生时，断开连接的事件出现得非常早期：在链路建立、特性交换流程刚执行完后，即发生了断连。
图3. 蓝牙抓包记录
在这里插入图片描述