【嵌入式无线升级实战】蓝牙OTA篇：从零构建STM32/AT32的空中固件更新系统

1. 为什么需要蓝牙OTA功能？

想象一下你家里有几十个智能灯泡，突然发现有个安全漏洞需要修复。如果每个灯泡都要拆下来用USB线刷固件，这工作量简直让人崩溃。这就是OTA（空中升级）技术存在的意义——让设备像手机APP一样可以无线更新。

我在2018年第一次接触OTA项目时就踩过大坑。当时给客户做的智能门锁出现BUG，不得不派工程师全国跑现场升级，光差旅费就花了十几万。后来我们给第二代产品加上了蓝牙OTA功能，同样的问题只需要推送个升级包就能解决。

蓝牙OTA相比WiFi方案有几个独特优势：

• 超低功耗：BLE协议天生为省电设计，纽扣电池都能撑半年
• 无需网关：直接用手机就能操作，特别适合简单IoT设备
• 开发成本低：nRF52832这类模块三十块钱就能搞定

2. 硬件选型与开发环境搭建

2.1 硬件组合方案

我经手过的项目中，这几个组合最稳：

• 性价比之王：STM32F103C8T6（主控） + nRF52832（蓝牙）
• 性能怪兽：AT32F403A（主控） + DA14531（蓝牙）
• all-in-one方案：STM32WB55（自带蓝牙）

最近帮客户调试时发现，AT32的FLASH擦写速度比同价位STM32快30%，特别适合频繁OTA的场景。不过STM32的生态更成熟，新手建议先从STM32入手。

2.2 开发环境配置

以Keil MDK为例，关键配置点：

1. 安装对应芯片包（STM32F4xx_DFP或AT32F4xx_AddOn）
2. 添加蓝牙协议栈（Nordic的nRF5_SDK或Dialog的SDK）
3. 配置调试工具（J-Link比ST-Link稳定）

c复制// 检查开发环境是否正常
#include "ble_gap.h"
void check_env(void) {
    if(ble_stack_init() != NRF_SUCCESS) {
        printf("蓝牙协议栈初始化失败！");
        while(1);
    }
}

3. 蓝牙协议栈深度适配

3.1 服务与特征值设计

OTA服务UUID建议采用自定义128位UUID，避免和标准服务冲突。我常用的特征值结构：

c复制// 蓝牙服务定义示例
static ble_uuid128_t ota_service_uuid = {
    .uuid128 = {0x12,0x34,...} // 自定义UUID
};

static ble_gatts_char_md_t char_md;
static ble_gatts_attr_md_t attr_md;
// ...（具体属性配置代码）

3.2 数据分包与流控

蓝牙MTU通常只有20字节，必须实现可靠的分包机制。我的经验是：

• 每包包含：包头(2B) + 包序号(2B) + 数据(16B) + CRC(2B)
• 采用滑动窗口协议，窗口大小建议3-5包
• 手机端要有超时重传机制

实测发现，不加流控的话，STM32F103接收大文件会丢包率达到15%。后来改用下面这个结构就稳了：

c复制#pragma pack(1)
typedef struct {
    uint16_t start_flag;  // 0xAA55
    uint16_t pkg_index;
    uint8_t  data[16];
    uint16_t crc;
} ota_package_t;
#pragma pack()

4. Bootloader设计精髓

4.1 双区备份机制

我推荐使用这种内存布局：

code复制0x08000000 ┌─────────────┐
           │ Bootloader  │ 16KB
0x08004000 ├─────────────┤
           │ Firmware A  │ 主程序区
0x08020000 ├─────────────┤
           │ Firmware B  │ 备份区
0x0803C000 ├─────────────┤
           │ OTA Config  │ 4KB
0x08040000 └─────────────┘

关键点：

• 通过SCB->VTOR动态切换中断向量表
• 跳转前关闭所有外设中断
• 备份区固件要通过CRC32验证

4.2 安全升级策略

去年有个客户产品被恶意固件攻击，后来我们加入了这些防护：

1. 签名验证：ED25519椭圆曲线签名
2. 版本防回滚：存储当前版本号到OTP区域
3. 看门狗保护：升级过程开启独立看门狗

c复制// 安全跳转示例
__asm void jump_to_app(uint32_t addr) {
    LDR SP, [R0]       // 加载新堆栈指针
    LDR PC, [R0, #4]   // 加载复位地址
}

5. 实战中的性能优化

5.1 加速FLASH写入

STM32的FLASH写入有个坑：必须先擦除整页。通过这两个技巧可以提速：

1. 预缓存：集齐16KB数据再统一擦写
2. 双缓冲：当A区写入时，B区准备下一批数据

实测AT32F407的FLASH写入速度优化前后对比：

5.2 低功耗处理

BLE广播时功耗可以做到15μA以下，关键配置：

• 广播间隔设150ms以上
• 关闭所有不用的外设时钟
• 进入STOP模式前保存RTC状态

c复制void enter_low_power(void) {
    HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
    // 唤醒后需要重新初始化时钟
    SystemClock_Config();
}

6. 常见问题排查指南

上周刚帮学员解决的典型问题：

现象：升级到50%必定失败
排查：

1. 用逻辑分析仪抓蓝牙数据，发现包序号不连续
2. 查手机端日志发现MTU设置未生效
3. 最终发现是蓝牙模块固件版本过旧

解决方案：

1. 更新nRF52固件到v7.2+
2. 在连接后手动触发MTU交换

其他高频问题：

• 升级后无法启动 → 检查向量表偏移量
• 连接经常断开 → 调整连接参数
• 数据校验失败 → 检查RAM是否溢出

7. 进阶开发建议

如果想做得更专业，可以考虑：

1. 差分升级：用bsdiff算法，升级包体积减少90%
2. 断点续传：记录已传输的包序号到FLASH
3. 多设备同步升级：通过mesh网络批量更新

最近用CubeMonitor发现个隐藏问题：STM32在FLASH写入时会产生2.4GHz频段干扰。解决方法是在关键代码段加屏蔽罩，或者改用AT32的独立Flash控制器。