2、蓝牙基础：BLE协议栈架构、GAP/GATT角色、广播与连接流程、MTU与ATT操作

在深入蓝牙芯片固件升级与OTA实现方案之前，必须扎实理解BLE（Bluetooth Low Energy，低功耗蓝牙）的核心运行机制。OTA升级本质上是在一条BLE链路上完成大块数据的可靠传输与存储，这要求我们清晰掌握协议栈的分层职责、设备间的角色定义、连接建立的时序过程以及数据交互的底层规则。本章将围绕这四个核心维度展开，为后续的固件分区设计、传输策略制定和异常恢复机制打下坚实的理论基础。

2.1 BLE协议栈架构：从物理层到应用层的职责划分

BLE协议栈采用分层设计，每一层只对上层提供服务，并屏蔽下层实现细节。这种分层架构使得蓝牙芯片的固件升级功能可以专注于应用层和GATT层的开发，而无需关心射频调制、跳频算法等底层细节。从OTA实现的角度看，我们最需要关注的是控制器层（Controller）与主机层（Host）之间的分工，以及它们与固件升级相关的数据通路。

核心原理：双核架构与数据通路

在绝大多数BLE芯片（如Nordic nRF52系列、TI CC2640、Dialog DA14531等）中，协议栈被划分为两个物理或逻辑上的独立部分：控制器（Controller）和主机（Host）。控制器包含物理层（PHY）和链路层（LL），负责射频信号的收发、数据包的编解码、跳频、白名单过滤等实时性要求极高的任务。主机则包含逻辑链路控制与适配协议（L2CAP）、属性协议（ATT）、通用属性规范（GATT）、通用访问规范（GAP）以及安全管理（SM）。主机通常运行在CPU上，以协议栈库的形式与应用代码链接。

对于OTA升级而言，数据流的路径是：应用层 → GATT层 → ATT层 → L2CAP层 → 链路层 → 物理层。每一层都会对数据添加或解析头部信息。理解这条路径有助于我们计算实际的有效数据传输速率，并定位升级过程中的瓶颈。

协议栈分层	核心职责	与OTA升级的关联点
PHY（物理层）	2.4GHz射频收发、GFSK调制、跳频	决定链路预算和抗干扰能力，影响升级稳定性
LL（链路层）	数据包组装、重传、加密、连接事件调度	负责可靠传输，重传机制保证升级包不丢失
L2CAP	协议复用、数据包分段与重组	将大块升级数据分割为适合LL层传输的PDU
ATT/GATT	属性操作、服务发现、特征值读写	定义OTA升级服务（如0xFF01），承载升级数据
GAP	设备发现、连接建立、广播配置	管理升级过程中的连接参数和角色切换
APP	业务逻辑、用户交互	实现升级流程状态机、Flash写入策略

判断方法：如何选择协议栈形态

根据芯片厂商的不同，协议栈的集成方式主要有三种：独立协议栈芯片（如BlueNRG-2）、片上集成协议栈（如nRF52系列）、纯Host协议栈（如Zephyr BT Stack）。选择时需考虑以下因素：

• Flash与RAM占用：片上集成协议栈通常占用约80-150KB Flash和10-30KB RAM，需评估是否影响固件升级的存储空间。
• 实时性要求：独立协议栈芯片通过SPI/UART与主控通信，存在通信延迟，不适合需要高吞吐的OTA场景。
• 调试便利性：片上集成协议栈支持单芯片调试，可通过JTAG/SWD直接查看协议栈状态。

2.2 GAP角色与连接流程：从广播到连接建立的完整时序

GAP（Generic Access Profile）定义了BLE设备如何被发现和连接。在OTA升级场景中，设备通常作为广播者（Advertiser）等待手机连接，或者作为从设备（Slave）在连接中接收升级数据。理解GAP角色转换和连接参数协商是确保升级过程不中断的关键。

核心原理：四种GAP角色

GAP定义了四种角色：广播者（Broadcaster）、观察者（Observer）、从设备（Peripheral）和主设备（Central）。在OTA升级中，手机APP通常扮演主设备角色，蓝牙芯片扮演从设备角色。从设备可以同时被多个主设备连接（在BLE 5.0之后支持多连接），但OTA升级通常只允许一个主设备操作，以避免Flash写入冲突。

操作流程：连接建立的三个关键步骤

1. 广播阶段：从设备以固定间隔（广播间隔，典型值100ms）发送广播包，包含设备地址、设备名称、服务UUID等信息。广播包类型分为可连接广播和不可连接广播，OTA升级必须使用可连接广播。
2. 扫描与连接请求：主设备扫描到广播包后，向从设备发送连接请求（CONNECT_IND）。该请求包含连接参数：连接间隔（Connection Interval）、从设备延迟（Slave Latency）和超时时间（Supervision Timeout）。
3. 连接建立与参数协商：从设备接受连接请求后，双方进入连接态。从设备可以在连接建立后通过L2CAP连接参数更新请求（Connection Parameter Update Request）来修改连接参数，以适应OTA升级对高吞吐的需求。

案例拆解：连接参数不当导致的升级失败

某智能锁产品使用DA14531芯片，OTA升级时频繁出现“连接已断开”错误。通过抓取空中数据包发现，手机端发起的连接请求中，连接间隔为30ms，从设备延迟为4，超时时间为2秒。在升级过程中，由于Flash擦写操作耗时较长（约80ms），导致从设备无法在连接事件内及时响应主设备的轮询，触发超时断开。

解决方案：在升级流程开始时，由从设备主动发起连接参数更新请求，将连接间隔调整为15ms，从设备延迟设为0，超时时间设为5秒。同时，将Flash擦写操作拆分为多个小段（每段4KB），穿插在连接事件之间执行，确保每个连接事件都能及时回复。修改后，升级成功率从78%提升至99.5%。

2.3 GATT与ATT操作：MTU协商与数据交互机制

GATT（Generic Attribute Profile）建立在ATT（Attribute Protocol）之上，定义了数据如何通过属性（Attribute）进行组织、发现和交互。OTA升级服务本质上是一个自定义的GATT服务，包含多个特征值（Characteristic），用于控制升级流程、传输固件数据和校验结果。

核心原理：属性表与特征值

每个GATT服务由一个或多个特征值组成，每个特征值包含：属性句柄（Handle）、类型（UUID）、权限（Permission）和值（Value）。在OTA升级中，典型的特征值包括：

• 控制点（Control Point）：用于发送升级命令（开始、暂停、擦除、校验等），通常支持Write和Indication。
• 数据特征（Data）：用于传输固件内容，通常支持Write Without Response（无响应写入）以提高吞吐。
• 版本特征（Version）：用于读取当前固件版本和升级包版本。

操作流程：MTU协商与数据写入

ATT_MTU（Maximum Transmission Unit）决定了单个ATT数据包能携带的有效载荷大小。默认ATT_MTU为23字节（其中3字节为ATT头，实际有效载荷20字节）。通过MTU协商，双方可以增大该值，最高可达247字节（BLE 4.2）或更大（BLE 5.0）。

// MTU协商流程（以nRF5 SDK为例）
// 1. 主设备发起MTU交换请求
uint16_t mtu = 247;
sd_ble_gattc_exchange_mtu_request(conn_handle, mtu);

// 2. 从设备在GATT事件中响应
case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:
    sd_ble_gatts_exchange_mtu_reply(ble_evt->evt.gatts_evt.conn_handle, mtu);
    break;

// 3. 协商成功后，有效载荷 = ATT_MTU - 3
uint16_t payload_size = mtu - 3; // 244字节

在OTA升级中，推荐使用Write Without Response（写无响应）操作来传输固件数据，因为它不需要等待从设备的ACK，可以连续发送多个数据包，充分利用连接事件。但必须配合从设备的Indication（指示）来确认每批数据已正确写入Flash。

ATT操作类型	方向	是否需要响应	OTA升级中的应用
Read	Client → Server	是	读取固件版本、升级状态
Write	Client → Server	是	发送控制命令（开始升级）
Write Without Response	Client → Server	否	批量传输固件数据（高吞吐）
Indication	Server → Client	是（Client需确认）	确认每批数据已写入Flash
Notification	Server → Client	否	推送升级进度（可选）

案例拆解：MTU协商失败的处理策略

部分老旧手机或蓝牙芯片不支持MTU协商（如BLE 4.0设备），此时ATT_MTU固定为23字节，有效载荷仅20字节。如果固件为120KB，需要发送6144个数据包。在连接间隔15ms下，每个连接事件最多发送6个包，理论耗时约15.4秒，加上Flash写入时间，实际约25秒。若使用Write With Response，则每个包需等待ACK，耗时将增加3-5倍。

优化方案：对于不支持MTU协商的设备，可采用分包聚合策略：将多个ATT数据包合并为一个L2CAP数据包（L2CAP支持最大64KB的SDU），减少协议开销。但需注意，L2CAP层的重组需要额外的RAM缓冲区，在资源受限的芯片上需谨慎使用。

2.4 广播与连接流程中的OTA特殊考量

在OTA升级过程中，广播和连接参数的设置直接影响用户体验和升级成功率。以下是一些经过验证的工程实践。

核心原理：广播超时与白名单

为了节省功耗，从设备通常会在广播一段时间后自动停止广播（如30秒）。在OTA升级场景中，用户可能需要较长时间才能打开手机APP并点击升级按钮，因此建议在进入OTA模式后，将广播超时设置为0（无限广播），或使用白名单（White List）机制，只允许特定MAC地址的手机连接，提高安全性。

操作流程：OTA模式下的广播参数推荐

// 广播参数配置示例（基于nRF5 SDK）
ble_gap_adv_params_t adv_params = {0};
adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;
adv_params.interval = MSEC_TO_UNITS(100, UNIT_0_625_MS); // 100ms广播间隔
adv_params.duration = 0; // 无限广播
adv_params.filter_policy = BLE_GAP_ADV_FP_ANY; // 允许任何扫描者

// 连接参数推荐
ble_gap_conn_params_t conn_params = {0};
conn_params.min_conn_interval = MSEC_TO_UNITS(15, UNIT_1_25_MS); // 15ms
conn_params.max_conn_interval = MSEC_TO_UNITS(30, UNIT_1_25_MS);
conn_params.slave_latency = 0; // 关闭从设备延迟
conn_params.conn_sup_timeout = MSEC_TO_UNITS(4000, UNIT_10_MS); // 4秒超时

案例拆解：广播参数对升级成功率的影响

某医疗设备在升级时，用户反馈“手机搜索不到设备”。排查发现，设备在进入OTA模式后，广播间隔设置为20ms（为了快速被发现），但广播功率过高导致射频前端饱和，实际覆盖范围反而缩小。同时，广播超时设置为10秒，用户来不及操作。

调整方案：将广播间隔调整为100ms（标准推荐值），广播功率降低至0dBm，广播超时设为0。同时，在广播数据中增加服务UUID（0xFF01），方便手机APP快速识别。调整后，设备发现成功率从85%提升至99%。

2.5 常见误区与总结复盘

在BLE基础知识的实际应用中，以下误区值得特别注意：

• 误区一：认为GATT连接建立后，数据可以随时双向传输。实际上，BLE是主从架构，从设备不能主动发送数据，必须通过Notification或Indication，且需要主设备先开启CCCD（Client Characteristic Configuration Descriptor）。
• 误区二：忽略连接参数更新请求的时序。从设备只能在连接建立后的一定时间内（通常是6秒内）发起参数更新请求，否则需要等待下一次连接事件。
• 误区三：将ATT_MTU与L2CAP的SDU大小混淆。ATT_MTU是ATT层的数据包大小，L2CAP的SDU是逻辑上的一次数据传输单元，两者在数据封装时存在映射关系。