国内做性视频网站,网页设计模板图片家乡,建网站做点什么好,wordpress提升速度1. 问题背景
客户使用 BlueNRG-345MC 开发了一个 BLE 外设#xff0c;和手机连接。在测试中发现#xff0c;手机连接上外设之后#xff0c;不断地在手机上点击蓝牙的开关按钮#xff0c;造成设备不断地断开、重连#xff1b;少则几次#xff0c;多则几十次。点击之后和手机连接。在测试中发现手机连接上外设之后不断地在手机上点击蓝牙的开关按钮造成设备不断地断开、重连少则几次多则几十次。点击之后必然出现 BLE 外设无广播信号的现象。该问题已经得到了解决。本文将展开聊聊该问题的解决过程和思路并就该问题总结、分享一些 BLE 连接过程的处理经验。
2. 定位问题
拿到该反馈描述后第一时间和客户沟通了几个问题明确了大概的方向。沟通的思路按照硬件问题、软件问题硬件问题是和设备相关板子相关、还是芯片相关软件问题根据设备类型是和 APP 相关、手机系统相关、BLE 主机固件相关、还是 BLE 外设固件相关这样的思路进行排查。通过以下问题粗略地进行问题的定位
“对端设备是什么如果是手机的话是否有 APP“——对端是手机并且有配套的APP。该问题确定了设备类型和软件类型。
“该问题是否必现且稳定复现问题出现后状态是否能保持“——问题稳定复现且必现而且状态能保持这是一个重要的依据由此依据我们可以进一步发问
“杀死配套 APP 的后台用其它手机、第三方 APPBLE 调试助手等是否能搜到设备的广播信号“——杀死配套 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
