BLE连接建立底层流程全解析：从广播、扫描到连接请求

1. 项目概述与核心价值

如果你正在开发一款基于蓝牙低功耗（Bluetooth Low Energy, BLE）的物联网设备，比如一个智能门锁、一个健康手环，或者一个资产追踪标签，那么你一定会遇到一个最基础也最核心的问题：两个设备究竟是如何“看见”彼此并最终“牵手成功”建立连接的？这个问题看似简单，背后却是一套精密、高效且充满智慧的通信协议在运作。今天，我们就抛开那些高层的API和SDK，深入到芯片指令和状态机的层面，来彻底拆解BLE连接建立的完整流程——从广播者发出第一声“呐喊”，到扫描者“听见”并回应，再到最终发起连接请求的“握手”全过程。

这份解析的价值在于，它能让你从“知其然”跃升到“知其所以然”。当你遇到设备发现不了、连接不稳定、功耗异常高这些棘手问题时，仅仅调整扫描间隔或广播频率可能治标不治本。理解底层机制，比如广播包的类型差异、扫描者的过滤策略、连接请求中的时序计算，才能让你精准定位问题根源，写出更健壮、更省电的嵌入式代码。无论是进行深度功耗优化，还是实现复杂的多设备管理逻辑，这份对底层流程的掌控力都至关重要。

2. 广播者：主动发声的设备

广播者是整个BLE发现过程的发起方。它就像一个不断发出自我介绍信号的灯塔。在芯片层面，这个“发声”行为是通过执行特定的命令来触发的。

2.1 广播命令的家族与核心参数

根据TI的CC26xx系列芯片文档，广播操作主要由几个核心命令发起：CMD_BLE_ADV（可连接非定向广播）、CMD_BLE_ADV_DIR（可连接定向广播）、CMD_BLE_ADV_NC（不可连接广播）和CMD_BLE_ADV_SCAN（可扫描非定向广播）。每个命令都携带两个关键的数据结构指针：pParams和pOutput。

pParams参数是广播行为的“剧本”，它定义了广播的所有细节。其中，advConfig子结构体尤为重要，它包含了设备地址类型（deviceAddrType，决定地址是公共地址还是随机地址）、广播数据指针（pAdvData）和长度（advLen）等。pOutput则是一个“成绩单”，用于在广播结束后，由射频内核（Radio CPU）填写本次广播的统计信息，比如发送了多少个包，方便主CPU查询。

注意：pParams中的endTrigger和endTime参数是控制广播时长的关键。你可以设置一个绝对时间或一个事件作为停止广播的触发器。这对于实现间歇性广播以节省功耗非常有用。例如，设备可以广播5秒，然后休眠30秒，如此循环。

2.2 可连接非定向广播详解

这是最常见的广播类型，对应CMD_BLE_ADV命令。设备通过发送ADV_IND类型的广播包来宣告自己的存在，并允许任何扫描者发起连接。

其工作流程是一个“发送-监听”的循环：

1. 发送阶段：射频内核在三个广播信道（37， 38， 39）上轮流发送ADV_IND包。这个包包含了广播者的设备地址（AdvA）以及可选的广播数据。
2. 监听阶段：发送完成后，射频内核会立即打开接收机，在一个短暂的窗口内监听可能的回应。它主要期待两种回应：
   • 扫描请求：如果扫描者处于主动扫描模式且策略允许，它可能会回复一个SCAN_REQ来请求更多信息。广播者收到后，会回复一个SCAN_RSP包，其中可以包含设备名称、服务UUID等补充信息。
   • 连接请求：如果有一个发起者（Initiator）设备决定连接它，会直接发送CONNECT_REQ包。

文档中的“Action Number”清晰地描述了射频内核在监听阶段遇到不同情况时的行为逻辑。例如，“Action Number 4”对应“收到连接请求”，此时操作会以BLE_DONE_CONNECT状态和FALSE结果结束，标志着广播者成功被连接，角色即将转变为连接状态下的从设备。

2.3 其他广播类型与定向广播的妙用

• 可扫描广播：使用CMD_BLE_ADV_SCAN命令，发送ADV_SCAN_IND包。它允许扫描者发送SCAN_REQ来获取扫描响应，但不允许直接发起连接。适用于那些需要被发现、提供信息，但连接由用户手动触发的设备（如信标）。
• 不可连接广播：使用CMD_BLE_ADV_NC命令，发送ADV_NONCONN_IND包。它只发送数据，不监听任何回应，发送完毕即结束。这是功耗最低的广播方式，常用于单向数据广播场景，如温度传感器定期上报读数。
• 可连接定向广播：使用CMD_BLE_ADV_DIR命令，发送ADV_DIRECT_IND包。这是最特殊的一种。它只针对一个特定的目标设备（通过pWhiteList指定其地址）。包内同时包含广播者地址（InitA）和目标设备地址（AdvA）。发送后，广播者只监听来自这个特定目标的连接请求，忽略其他所有设备。这能极大提高连接建立的私密性和速度，常用于快速重连场景。

实操心得：在开发中，我曾用定向广播来实现设备间的快速配对。当两个设备通过某种方式（如按键）进入配对模式后，双方互相将对方地址加入白名单，并开启定向广播。这样，它们能在广播信道上快速、精准地找到彼此并建立连接，避免了在普通广播中可能受到的无关设备干扰，配对成功率和速度显著提升。

2.4 广播的结束与状态解析

广播操作会以多种状态结束，status字段和result字段共同决定了后续操作。

• BLE_DONE_OK(TRUE)：通常表示一次完整的“发送-监听”周期正常结束，未收到连接请求，可以继续下一次广播。
• BLE_DONE_CONNECT(FALSE)：这是广播者最期待的“成功”状态之一，表示收到了有效的连接请求，广播任务圆满完成，设备将进入连接状态。
• BLE_DONE_ENDED/BLE_DONE_STOPPED(FALSE)：由endTrigger触发或CMD_STOP命令停止，属于计划内的正常停止。
• BLE_ERROR_PAR(ABORT)：参数错误，例如广播数据长度非法或信道值错误。这通常是应用程序配置错误，需要检查pParams中的参数。

每次命令结束时，都会产生COMMAND_DONE中断，系统CPU通过读取命令结构体中的状态字段，就能知道发生了什么，从而决定是重新开始广播、进入连接状态还是处理错误。

3. 扫描者：主动发现的侦探

扫描者是通信中的主动发现方。它持续或间歇地在广播信道上“倾听”，寻找感兴趣的广播者。

3.1 扫描命令的启动与核心配置

扫描操作由CMD_BLE_SCANNER命令启动。其pParams参数中的scanConfig结构体是控制扫描行为的核心。

• bActiveScan：决定是被动扫描还是主动扫描。被动扫描只接收广播包；主动扫描在收到可扫描或可连接广播后，可以发送SCAN_REQ去请求额外的扫描响应数据。
• scanFilterPolicy与白名单：这是扫描过滤的灵魂。策略决定了扫描者如何处理收到的广播包。策略0（SCAN_FILTER_ACCEPT_ALL）会报告所有收到的广播包；策略1（SCAN_FILTER_ACCEPT_WLIST）则只报告在白名单中的设备发来的广播包。白名单是一个存储在内存中的设备地址列表，用于过滤无关设备，能有效降低主CPU的处理负荷和功耗。
• bStrictLenFilter：长度严格过滤开关。打开时，只接受符合BLE规范长度字段的包，能过滤掉一些非标或错误的包，增强鲁棒性。

3.2 扫描者的决策逻辑：一张表看懂所有

文档中的表23-121是理解扫描者行为的关键。它根据收到的PDU类型、CRC校验结果、过滤策略、白名单匹配情况以及是否主动扫描，来决定采取哪个“动作编号”。

我们来解读几个典型场景：

1. 收到一个ADV_IND（可连接广播），CRC正确，过滤策略为1（使用白名单），且发送者不在白名单中：无论是否主动扫描，都执行动作1（bIgnore=1），即忽略此包，继续扫描。这实现了白名单过滤。
2. 收到一个ADV_IND，CRC正确，过滤策略为0（接受所有），且处于主动扫描模式：执行动作3。这意味着扫描者需要先执行一个“退避”过程，然后发送SCAN_REQ去请求扫描响应。
3. 收到一个ADV_DIRECT_IND（定向广播），CRC正确，且其中的InitA字段与扫描者自身地址匹配：这表示这个定向广播是“冲着我来的”。此时，如果过滤策略允许，会执行动作2。动作2意味着可以结束扫描操作（如果bEndOnRpt设为1），或者继续扫描。

3.3 退避算法：避免空中冲突的智慧

当扫描者决定发送SCAN_REQ时（对应动作3），并不是立即发送，而是要先执行一个退避（Backoff）过程。这是一个防止多个扫描者同时响应一个广播者导致无线电冲突的机制。

流程如下：pParams->backoffCount是一个计数器。每次准备发送SCAN_REQ前，先将其减1。只有当它减到0时，才真正发送请求。如果减1后不为0，则本次放弃发送，扫描操作可能直接结束（取决于配置）。

backoffCount的初始值和更新规则由backoffPar参数控制，其更新逻辑在表23-124中定义，核心是一个简化的二进制指数退避算法：

• 上次请求失败：logUpperLimit可能增加（上限为8），使得下次的backoffCount随机范围变大，降低冲突概率。
• 上次请求成功：logUpperLimit可能减少（下限为0），使得下次能更快响应。
• backoffCount最终是一个在1到2^logUpperLimit之间的伪随机数。这个随机种子randomState需要由系统CPU提供一个真随机或伪随机值来初始化，以确保不同设备的行为有所差异。

注意事项：很多开发者会忽略退避参数的初始化。文档明确要求，在设备进入扫描状态时，必须将backoffCount初始化为1，backoffPar.logUpperLimit等字段初始化为0。如果使用随机种子，也需在此处初始化。如果不做初始化，退避逻辑可能不会按预期工作，导致扫描请求发送行为异常。

3.4 扫描响应的处理与统计

发送SCAN_REQ后，扫描者会等待对方的SCAN_RSP。表23-123定义了处理规则：只有CRC正确且AdvA与请求对象一致的响应才算成功。成功后，扫描者就获得了广播者的额外信息（如完整的设备名）。

pOutput结构体在扫描过程中会累积大量有价值的统计信息：成功接收的广播包数（nRxAdvOk）、被忽略的包数（nRxAdvIgnored）、CRC错误的包数（nRxAdvNok）、发送的扫描请求数（nTXScanReq）等等。这些数据对于调试射频性能、评估空中流量、优化扫描参数至关重要。例如，如果nRxAdvNok异常高，可能意味着环境干扰严重；如果nRxAdvIgnored很多，可能是白名单过滤太严格或扫描间隔设置不当。

4. 发起者：连接建立的最后一环

发起者是扫描者角色的一个特化和延伸。它的目标非常明确：找到特定的可连接设备，并与之建立连接。它由CMD_BLE_INITIATOR命令启动。

4.1 发起者的精准定位策略

发起者的过滤逻辑比普通扫描者更直接。通过pParams->initConfig.bUseWhiteList参数，可以选择两种模式：

1. 单目标模式：bUseWhiteList = 0。此时，pWhiteList指向一个单一的设备地址。发起者只寻找地址与此匹配的广播者。这是最常见的点对点连接场景。
2. 白名单模式：bUseWhiteList = 1。此时，pWhiteList指向一个白名单。发起者会尝试连接白名单中的任意一个设备。这在需要连接多个已知设备之一时有用。

其决策逻辑在表23-126中定义，比扫描者更简洁：

• 对于ADV_IND，地址匹配就执行动作2（发送连接请求）。
• 对于ADV_DIRECT_IND，除了地址匹配，还要求其中的InitA字段与自身地址匹配（即这个定向广播是指向自己的），才会执行动作2。

4.2 连接请求的构造与动态窗口偏移

当决定连接时，发起者会构造并发送CONNECT_REQ数据包。这个包包含了连接的所有关键参数：接入地址、CRC初始化值、窗口大小（WinSize）、窗口偏移（WinOffset）、连接间隔、从设备延迟、监控超时等。其中，WinOffset和WinSize定义了连接建立后，第一个数据通信窗口的开启时间和持续时间。

这里有一个高级功能：动态窗口偏移计算。通过设置pParams->initConfig.bDynamicWinOffset = 1，可以让射频内核自动计算最优的WinOffset和WinSize。它是如何工作的呢？

发起者芯片知道它准备发送CONNECT_REQ的时刻（connectTime），也知道请求中的连接间隔。第一个连接事件必须发生在connectTime + N * 连接间隔这个时间点上。射频内核的任务是，计算一个WinOffset，使得定义的传输窗口能够刚好覆盖第一个可能的连接事件，并留出足够的裕量（Margin），确保主从设备都能在这个窗口内成功通信。

芯片会自动在pParams->pConnectData缓冲区中写入计算好的WinSize（1或2）和WinOffset值。同时，它会把计算出的第一个连接事件的实际开始时间写回pParams->connectTime。这个功能极大地简化了应用层开发，无需手动进行复杂的时间计算，就能实现稳健的连接时序。

4.3 连接建立的时序与状态管理

发送完CONNECT_REQ后，发起者操作就结束了。此时，发起者设备转变为主设备，广播者设备转变为从设备。双方将按照CONNECT_REQ包中协商的参数，在指定的第一个连接事件窗口进行首次数据通信，从而正式进入连接状态。

和广播、扫描一样，发起者操作也受endTrigger和timeoutTrigger控制。timeoutTrigger通常用于设置一个“扫描窗口”，例如只在前10毫秒内尝试寻找设备；endTrigger则用于完全停止发起操作。

5. 实战经验与深度避坑指南

理解了流程，我们来看看在实际开发和调试中，有哪些容易踩的“坑”和必须掌握的技巧。

5.1 白名单管理的常见陷阱

白名单是过滤的神器，但用不好也会带来麻烦。

• 地址类型不匹配：白名单中存储的设备地址必须包含地址类型（公共地址或随机地址）。如果广播者使用随机地址广播，而你在白名单中将其记录为公共地址，过滤就会失败。务必确保peerAddrType与对方广播包中的TXAdd位一致。
• 白名单更新时机：在扫描/发起命令运行期间，直接修改pWhiteList指向的内存内容可能是危险的，因为射频内核可能正在读取它。安全的做法是停止当前命令，更新列表，然后重新启动命令。
• 自动忽略功能：扫描配置中的bAutoWlIgnore位是个实用功能。当它和过滤策略同时启用时，射频内核在成功报告或扫描一个白名单设备后，会自动标记该白名单条目，在一段时间内忽略来自同一设备的后续广播。这能防止主CPU被同一设备的重复广播频繁打断。但要注意，这可能会让你错过该设备广播数据的更新。

5.2 广播与扫描的参数调优

参数配置直接影响功耗、发现速度和可靠性。

• 广播间隔：在pParams中设置。间隔越短，被发现的速度越快，但功耗越高。需要权衡。通常，快速配对时用短间隔（如20ms），待机发现时用长间隔（如1s以上）。
• 扫描窗口与间隔：扫描不是连续的，而是周期性的。scanWindow是每次扫描的持续时间，scanInterval是扫描周期。scanWindow/scanInterval的比例称为“占空比”。提高占空比能提高发现概率，但也增加功耗。一个常见策略是：初始高占空比快速发现，之后降低占空比维持连接或节能监听。
• 超时设置：合理设置timeoutTrigger和endTrigger。对于发起者，设置一个连接尝试超时（如30秒）是必要的，避免在找不到设备时无限期扫描。

5.3 连接建立失败问题排查清单

当设备无法建立连接时，可以按照以下步骤排查：

5.4 中断处理与资源管理

射频内核通过中断与系统CPU通信。高效的中断处理程序至关重要。

• 避免在中断服务程序中进行复杂操作：收到RX_OK或COMMAND_DONE中断后，应快速读取状态、拷贝必要数据到安全缓冲区，然后设置标志位，让主循环来处理业务逻辑。
• 管理好RX/TX队列：BLE_ERROR_RXBUF错误表示RX缓冲区已满。你需要确保系统CPU能及时取走射频内核接收到的数据包，避免缓冲区溢出导致丢包。同样，在发送多个数据包时，也要管理好TX队列。
• 命令状态机：每个命令（广播、扫描、发起）都是独立的。一个命令结束后（COMMAND_DONE），系统CPU需要根据result和status决定下一个动作。例如，广播结束后如果是BLE_DONE_OK，可能需要重新启动广播；如果是BLE_DONE_CONNECT，则需要启动连接状态机。

深入理解从广播、扫描到连接请求的完整底层流程，是进行高性能、低功耗BLE应用开发的基石。它让你能从协议栈的“黑盒”之外，清晰地看到每一个无线电脉冲背后的逻辑，从而在遇到问题时能直击要害，在优化设计时能有的放矢。希望这份结合了协议规范和实战经验的解析，能成为你BLE开发工具箱里的一件利器。