BLE 蓝牙智能硬件 App 通信协议与固件 OTA 工程实践

关键工程指标 (Key Engineering Metrics)

• 固件 OTA 升级成功率 (OTA Completion Rate)：99.6%
• 断连重连恢复耗时 (Auto-Reconnect Recovery)：< 1.5s
• 变砖事故率（双分区回滚） (Bricked Device Rate)：0.00%

工程落地核查清单 (Architecture Checklist)

• 连接建立后先完成 MTU 协商与连接间隔（Connection Interval）优化，再启动高频数据吞吐
• 所有 BLE 指令封装入串行异步队列（Command Queue），严格匹配 Seq 序列号、ACK 与超时重试
• 协议帧内置帧头、命令字、分包序号、有效载荷长度与 CRC16/CRC32 校验，防御丢包粘包
• OTA 升级前强制校验固件数字签名、硬件版本号与电量阈值（如低于 30% 禁止启动升级）
• 配合硬件 A/B 双分区与断点续传偏移量记录，任何时刻断电或杀进程均可重连续传或安全回滚

一、BLE 连接链路与 GATT 通信协议设计

1. Reliable BLE Connection Lifecycle & Custom GATT Packet Framing

稳定 BLE 架构首先要定义清晰的 GATT 服务和特征值，通常包括命令通道、数据通道、通知通道和 OTA 通道。App 端需要处理蓝牙状态、权限、扫描过滤、RSSI、自动重连、连接参数更新和多设备兼容。协议帧应包含帧头、命令字、序列号、载荷长度、数据、CRC 与结束标记，所有写操作采用请求-应答或通知机制，避免无状态连发。iOS 与 Android 还要适配 MTU、分包长度、写类型和后台限制。

Separate GATT characteristics into Command (Write + Notify ACK), Realtime Telemetry, and High-Throughput OTA Data (Write Without Response + Windowed ACK). Because iOS CoreBluetooth and Android BluetoothGatt differ in MTU negotiation and GATT error codes (e.g., Android status 133), wrap all operations in a serialized state machine.

二、固件 OTA 分片传输、进度同步与异常恢复

2. Chunked Firmware OTA, Sliding-Window ACK & Resume-on-Disconnect

固件升级前，App 应读取设备型号、硬件版本、当前固件版本、电池电量和存储空间，校验固件签名、目标版本与降级策略。传输时按协商 MTU 分片，支持序号确认、滑动窗口、超时重传、CRC 校验和断点续传。设备端需将固件写入临时分区，完整校验后再切换启动分区；失败时回滚到备份固件。App 要持久化升级会话，处理杀进程、断连、来电、蓝牙关闭等场景，重连后从已确认偏移继续。

Sending ACK on every single 20-byte packet makes OTA painfully slow; sending without flow control overflows the MCU buffer. We use sliding-window bursts (e.g., 16 frames per window according to negotiated MTU) followed by a block CRC verification and persistent offset checkpointing.

三、稳定性调试、灰度发布与量产质量保障

3. Cross-Device Compatibility Matrix, Grayscale Rollout & Telemetry

BLE 问题往往出现在机型兼容性和真实无线环境中，因此必须建立协议日志、设备串口日志、手机端抓包和云端升级日志的联动分析。关键指标包括扫描成功率、连接成功率、发现服务耗时、指令超时率、OTA 开始率、完成率、平均耗时和失败原因分布。固件发布应采用版本灰度、设备白名单、强制升级与可选升级策略，并在生产线加入射频、功耗、按键、传感器和 OTA 自检。发布后保留异常固件拉闸与回滚能力。

Correlate mobile BLE ring-buffer logs with MCU crash registers and cloud OTA funnels. Roll out new firmware in staged cohorts by MAC/serial prefix with an instant server-side kill switch.

参考实现代码 (ble/ota_packet_framer.dart (CRC-16 Sliding Window Frame))

import 'dart:typed_data';

Uint8List buildBleCommandFrame({
  required int opcode,
  required int seq,
  required Uint8List payload,
  required int Function(Uint8List) crc16,
}) {
  final header = BytesBuilder(copy: false)
    ..addByte(0xAA) // Magic byte
    ..addByte(opcode & 0xFF)
    ..addByte((seq >> 8) & 0xFF)
    ..addByte(seq & 0xFF)
    ..addByte(payload.length & 0xFF)
    ..add(payload);
  final body = header.toBytes();
  final checksum = crc16(body);
  return Uint8List.fromList([...body, (checksum >> 8) & 0xFF, checksum & 0xFF]);
}

常见问题解答 (FAQ)

问：BLE OTA 传输到一半断连，如何避免设备变砖？ (How do you prevent bricking a hardware device if BLE disconnects mid-OTA?)

答：设备应使用 A/B 双分区或临时下载区，固件完整接收并通过签名、CRC、版本校验后才写入或切换启动分区；App 持久化偏移量，重连后断点续传，升级失败自动回滚原固件。 Use an A/B dual-partition bootloader on the MCU. Incoming OTA chunks write only to the inactive staging partition. The bootloader switches the active partition flag only after the full image passes SHA-256 signature and CRC verification; otherwise it boots the intact partition and resumes from the last committed offset.