【应用笔记】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. 蓝牙抓包记录

仔细检查客户的代码，果然，客户将连接成功的依据放在了 MTU 交换成功之后，即，用户层的蓝牙连接状态，和实际的链路层的连接状态，在快速操作蓝牙开、关的动作之后，脱钩了！该问题可通过下面的序列图描述：

图4. 问题图示

之所以把蓝牙连接成功的标志，在 MTU 交换成功的回调中置位，客户的想法很简单：用户层需要依据 MTU 的大小，来决定用户层数据包的尺寸，而用户工程师发现，每次蓝牙连接时，MTU 交换完成回调函数都会被执行，于是，想当然的认为可以依据该回调来设置用户层蓝牙的连接标志。

发现了问题的根因后，解决方法也比较简单，把置位连接成功标志的动作，放到连接建立回调函数中即可。

5. 小结

蓝牙协议栈是个分层的协议，当我们说蓝牙已连接时，想表达的意思应该是链路层链路建立，而现实中，很多工程师都把蓝牙已连接理解成了可以收、发数据了。实际上，从蓝牙链路建立，到协议栈可以为用户层收、发数据，中间还差了十万八千里。总而言之，从本文的解题思路出发，我总结以下几点经验：

• • 用户程序应该深刻理解“蓝牙已连接”的概念， 做好状态管理。
• • 链路建立后是蓝牙最繁忙的时刻，用户任务处理应尽可能避开该时间段。
• • 加快链路建立繁忙时间段的方法包括：
  -o 链路建立后，使用较快的连接间隔，并在之后调慢以平衡功耗
  -o 使用 GATT CACHING 特性

---

本文档参考ST官方的《【应用笔记】LAT1315+串口DMA接收不定长数据的一种方法》文档。
参考下载地址：https://download.csdn.net/download/u014319604/89055623