打印
[应用相关]

关于连接参数更新进程后导致断连的问题分析

[复制链接]
30|0
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
呐咯密密|  楼主 | 2024-3-11 09:54 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
01
引言

通常客户在做低功耗蓝牙模块设计的时候,如果蓝牙模块在实际使用场景中和手持移动设备(如手机等)绑定使用的话,往往会非常注意蓝牙模块与不同品牌、不同型号的手机的兼容性测试。这些测试项目可能包括长时间连接状态的保持,频繁建立连接,或主动断连后再次建立连接等场景。本文描述的问题是客户在其兼容性测试中发现的一个比较典型的问题,即当从设备在与手机端处于连接状态下,从设备启动连接参数更新进程后,会导致断连的问题。由于是兼容性测试,测试设备,特别是作为主设备的手机来自不同的供应商,在兼容低功耗蓝牙协议的基础上,某些细节部分的差异难以避免。所以,本文只论述了该客户问题的分析过程及得出的结果,并不期望涵盖所有类似场景下导致断连的原因。

02
连接参数更新进程简述

低功耗蓝牙的核心规范中有规定,当主从设备建立连接后,可以通过启动特定的进程改变当前连接的相关参数,如连接间隔(ConnInterval),从设备延迟(SlaveLatency)和监控超时(SupervisionTimeout)等。

低功耗蓝牙的核心规范中定义了几个不同的连接参数更新流程,有的流程主设备和从设备都可以启动,有的流程只能由从设备或主设备启动。为避免引入过多对本文关注话题的无用信息,我们在这里只介绍一种由从设备启动的连接参数更新的流程。即由从设备通过调用L2CAP 层的命令的方式启动的连接参数更新流程。

流程图如图 1 所示。流程图的前提条件是主从设备端之间已建立连接,从设备希望改变当前已建立连接的连接参数。

整个流程的步骤解析如下:

第一步:从设备发起 Connection Parameter Update Request,提交新的连接参数给主设备,希望主设备可以采用这些参数。主设备接收到从设备的 Request 后,会根据自身当前条件(是否能支持这些连接参数)决定是否接受请求。如果接受,则执行第二步;如不接受,则直接跳到第四步拒绝该 Request。

第二步:主设备接受请求,给从设备发送链路层数据包LL_CONNECTION_UPDATE_REQ,该数据包中包含了主设备在分析了从设备在第一步中提交连接参数后,决定最终使用的目标连接参数,并约定在后续的特定连接事件开始使用新的连接参数。

第三步:从设备在接收到 LL_CONNECTION_UPDATE_REQ 数据包后发送一个链路层的空包作为响应,并结束当前连接事件。

第四步:主设备发送 L2CAP 层的 Connection Parameter Update Response 命令,作为对第一步中 Request 命令的回复,回复中的相关标志标明是接受(Accept)还是拒绝(Reject)之前的 Request 命令。如果是接受,则主从设备双方会在第二步中LL_CONNECTION_UPDATE_REQ 数据包中所指定的后续特定连接事件中开始使用新的连接参数,并成功完成连接参数更新过程。

03
客户可能的测试逻辑和问题现象描述

客户使用智能手机和 ST 的 BlueNRG LP 作为测试的主从设备。客户的兼容性测试中需要使用预设连接间隔和监控超时时间。为了在测试过程中可以实时调整相关参数,需要手机端作为主设备通过私有逻辑将新的连接参数通过低功耗蓝牙连接发送给从设备( BlueNRGLP ), 并由从设备启动上述的更新流程,以完成连接参数的更新并继续执行后续的其他测试项。

问题现象:

主从设备在完成上述流程第四步后,且主设备发送 Connection Parameter UpdateResponse 命令所给出的响应也是接受的情况下,主从设备在上述流程中第二步LL_CONNECTION_UPDATE_REQ 命令所指定的特定连接事件中开始采用新的连接参数时会发生断连。从设备重新进入广播状态。

客户的疑惑点在于主从设备已经完成了上述连接参数更新的交互,意味着应该可以顺利切换到新的连接参数,没有道理会导致后续的断连,由于作为主设备的智能手机是某大品牌产品,怀疑 BlueNRG 的协议栈是否存在兼容性问题。

04
问题分析

根据问题复现时使用低功耗蓝牙抓包工具所抓取的 log 数据,做如下分析。

4.1.分析 LL_CONNECTION_UPDATE_REQ 数据包内容

4.1.1. 如图 2 所示,LL_CONNECTION_UPDATE_REQ 数据包内容,需要重点关注如下数据:

1. Event counter:29, 表示 LL_CONNECTION_UPDATE_REQ 发送时所在的连接事件编号为 29。
2. Instant:35:约定在第 35 个连接事件中,主从设备开始使用新的连接参数。
3. Interval:816(1020msec), 表示新的连接间隔为 1.02 秒。
4. Window Size/Window Offset:第 35 个连接事件中,主从设备开始使用新的连接参数进行第一次数据包交互时,接收、发送窗口的定时信息。

图2.LL_CONNECTION_UPDATE_REQ PDU 抓包数据

4.1.2. 从下图 3 中获取从连接事件 29 到从设备进入广播状态这个过程中每个连接事件及连接时间中数据包收发的时间戳。



使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

认证:苏州澜宭自动化科技嵌入式工程师
简介:本人从事磁编码器研发工作,负责开发2500线增量式磁编码器以及17位、23位绝对值式磁编码器,拥有多年嵌入式开发经验,精通STM32、GD32、N32等多种品牌单片机,熟练使用单片机各种外设。

351

主题

2775

帖子

40

粉丝