📚 课程目录第2章基础知识

2、基础知识：智能穿戴设备架构、固件组成、BLE协议栈与OTA基本概念

智能穿戴设备的固件升级并非简单的文件拷贝，而是一项涉及硬件资源约束、通信协议适配、数据安全与用户体验的系统工程。要理解OTA（Over-The-Air，空中下载）升级为何需要“模型参数”与“阈值”的精细管理，首先必须厘清穿戴设备的硬件架构、固件在存储介质中的布局，以及BLE（Bluetooth Low Energy，低功耗蓝牙）协议栈在数据传输中的角色。本节将围绕这四个核心维度展开，为后续章节的升级策略设计打下坚实基础。

上图从三个视角勾勒了智能穿戴设备的基础轮廓：左侧是典型的硬件组成，中间是Flash存储器的逻辑分区，右侧则是BLE OTA升级时的数据通路。这三者并非孤立存在，而是通过总线、中断和协议栈紧密耦合。理解这张图，是后续所有升级策略讨论的起点。

2.1 智能穿戴设备架构：资源受限的异构系统

智能穿戴设备（如智能手表、手环、戒指）在硬件架构上通常采用“主控+协处理”或“单芯片多核”的方案。与手机不同，穿戴设备对功耗、体积和成本极度敏感，这直接决定了其固件升级策略必须“精打细算”。

核心原理：MCU为中心的外设聚合

绝大多数穿戴设备以一颗低功耗MCU（如ARM Cortex-M4/M33）或SoC（如Apollo4、nRF52系列）为核心。这颗主控承担三方面职责：

应用处理：运行UI逻辑、算法模型（如心率、睡眠监测）、用户交互。
通信管理：通过BLE与手机交互，处理连接、配对、数据同步。
外设控制：通过I2C/SPI读取传感器（加速度计、PPG心率传感器），通过PWM驱动马达或屏幕。

值得注意的是，部分设备会采用“双芯片”方案：一颗超低功耗MCU负责传感器数据采集与计步算法，另一颗性能稍强的MCU负责UI与通信。这种架构下，OTA升级需要同时考虑两颗芯片的固件更新，且必须保证升级顺序与回滚机制，否则可能导致传感器数据格式不匹配。

  关键约束：穿戴设备的RAM通常只有64KB~512KB，Flash为1MB~8MB。这意味着OTA升级时无法像手机一样将整个固件镜像加载到RAM中再写入，而必须采用“边下载、边写入、边校验”的流式处理方式。同时，由于Flash擦写次数有限（通常10万次），频繁升级会缩短器件寿命。

判断方法：识别架构对升级的影响

在制定升级方案前，工程师应通过以下问题快速判断架构约束：

设备是否有独立BLE芯片？若有，BLE芯片固件是否支持OTA？
主控Flash是否支持双Bank（A/B分区）？这决定了能否实现无缝升级。
传感器算法是运行在主控还是协处理器上？模型参数存储位置在哪？
设备是否具备外部Flash（如SPI NOR Flash）？可用于缓存升级包。

2.2 固件组成：不仅仅是代码

很多初学者误以为固件就是“程序代码”。实际上，现代智能穿戴设备的固件是一个复合体，包含可执行代码、只读数据、可变配置和算法模型。理解固件的组成，是设计OTA升级包格式的前提。

核心原理：固件的四层结构

组成模块	内容说明	升级频率	失败影响
Bootloader	引导代码、启动校验、恢复入口	极低（仅修复Bootloader缺陷时）	设备变砖，需JTAG/SWD恢复
App Firmware	UI逻辑、驱动、主循环、通信协议	高（功能迭代、Bug修复）	功能异常，但可重新升级
Model Params	神经网络权重、决策树参数、传感器校准系数	中（算法优化时更新）	算法精度下降，但设备可运行
Thresholds	心率报警阈值、运动检测灵敏度、功耗策略参数	高（用户可调或云端下发）	误报或漏报，影响用户体验

从上表可以看出，模型参数和阈值与App固件具有完全不同的升级节奏和失败容忍度。例如，心率算法的神经网络权重文件可能占用200KB，而阈值配置仅占几百字节。若将两者打包在同一个固件镜像中，每次调整阈值都需要下载整个固件，既浪费带宽又增加升级失败风险。

工程实践：建议将固件包拆分为“基础固件包”（包含Bootloader+App）和“增量参数包”（包含模型参数+阈值）。参数包采用独立版本号，支持单独下载与回滚。例如，当用户手动调整“久坐提醒阈值”时，仅需通过BLE下发一个JSON或二进制配置块，而非整个固件。

2.3 BLE协议栈与OTA基本概念

BLE是穿戴设备与手机通信的事实标准。OTA升级依赖BLE的GATT（通用属性协议）进行数据传输，但其低吞吐量（实际有效数据速率约20-50KB/s）和链路不稳定性是升级设计的主要挑战。

核心原理：GATT与OTA服务

BLE协议栈中，GATT定义了客户端（手机）与服务器（设备）之间的数据交互方式。OTA升级通常自定义一个GATT Service，包含以下Characteristic：

OTA Control Point（写入）：手机发送升级命令（开始、暂停、擦除Flash、校验）。
OTA Data（写入）：手机分包发送固件内容，每包通常为MTU-3字节（默认MTU=23，实际可用20字节；协商后可达244字节）。
OTA Status（通知/指示）：设备上报升级进度、错误码、校验结果。

升级流程可概括为：手机App读取设备当前固件版本 → 发送升级包信息（大小、CRC） → 设备擦除目标Flash区域 → 手机循环发送数据包 → 设备写入Flash并回传确认 → 全部发送完成后设备进行CRC校验 → 跳转Bootloader执行固件切换。

操作流程：BLE OTA的关键步骤与参数

// 伪代码示例：设备端处理OTA数据写入
void on_ota_data_write(uint8_t *data, uint16_t len) {
    // 1. 检查当前状态是否为OTA_RECEIVING
    if (ota_state != OTA_RECEIVING) return;
    // 2. 写入外部Flash或内部Flash的临时区
    flash_write(ota_temp_addr + ota_received_len, data, len);
    ota_received_len += len;
    // 3. 每收到N包，回传一次进度通知
    if ((ota_received_len / len) % 10 == 0) {
        send_ota_status(OTA_PROGRESS, ota_received_len);
    }
    // 4. 若接收完成，触发CRC校验
    if (ota_received_len >= ota_total_len) {
        ota_state = OTA_VERIFYING;
        crc_verify();
    }
}

上述代码展示了设备端处理数据写入的核心逻辑。实际工程中，还需考虑Flash写入对齐（通常4KB扇区擦除）、写入失败重试、以及BLE断连后的续传机制。

2.4 案例拆解：一次因阈值参数引发的“假死”升级事故

为加深理解，我们分析一个真实场景：某品牌手环在推送V2.3版本时，将“心率过高报警阈值”的默认值从120bpm调整为150bpm，并将该参数打包在App固件中。结果导致部分用户升级后，手环在运动时不再报警，引发投诉。

背景与约束：该手环Flash容量为2MB，App固件占用1.2MB，模型参数占用300KB，阈值配置占用2KB。OTA升级包为完整固件镜像（1.5MB），通过BLE传输约需90秒（按17KB/s有效速率计算）。

初始现象：用户反馈“升级后心率报警不工作”。工程师排查发现，新固件中的阈值参数被错误地写入了模型参数分区，导致算法读取到异常值。

分析过程：

通过日志确认，升级后设备启动时，算法模块尝试从固定偏移地址读取阈值，但该地址在V2.3中已被模型参数覆盖。
根因是固件打包脚本未区分“代码段”和“参数段”，导致链接时变量地址偏移。
进一步发现，由于阈值参数与App固件强耦合，无法单独回滚阈值，只能回滚整个固件版本。

实际操作与结果：开发团队紧急发布V2.3.1，将阈值参数独立为可配置项，并通过OTA仅下发2KB的配置包。升级耗时从90秒降至2秒，且支持用户自定义阈值。事故复盘表明，将易变参数与稳定代码分离，是穿戴设备OTA设计的基本原则。

风险提示：切勿将用户可调参数（如阈值）编译进只读固件镜像。应使用独立的配置存储区（如Flash末尾的KV区域），并通过GATT服务提供读写接口。否则，每次参数调整都需要完整OTA，且极易因Flash擦写错误导致配置丢失。

2.5 常见误区与总结复盘

在智能穿戴OTA的基础知识学习中，以下误区值得警惕：

误区一：认为OTA升级就是“传文件”。实际上，BLE传输的是数据流，需要处理分包、丢包、重传、流量控制，而非简单的文件拷贝。
误区二：忽略Flash磨损均衡。频繁升级或反复擦写同一扇区会缩短Flash寿命，应使用动态分区或磨损均衡算法。
误区三：将模型参数与代码混编。这会导致算法更新时必须连带升级代码，增加失败风险和包体大小。
误区四：缺乏版本兼容性检查。设备端应校验App固件与模型参数的版本匹配关系，否则可能出现接口不兼容。