ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

STM32WB5MMG的FUS与BLE协议栈升级实战指南

STM32WB5MMG的FUS与BLE协议栈升级实战指南 STM32WB5MMG 这个模组我从评估板一直用到量产大半年里前前后后给不下二十块板子刷过 FUS 和软件栈。前几天刚把一批设备的 BLE 协议栈从旧版本升到新版本顺手把 FUS 也更新到了最新状态整个过程比想象中容易踩坑版本号看错、FUS 状态不对、CPU2 起不来最后一片都没跑通。这篇就把这次升级 STM32WB5MMG 的完整过程、工具准备、关键步骤和排错记录整理出来给正在做无线产品固件维护的同行一个参考。1. 项目概述与升级思路1.1 为什么要动 FUS 和软件栈STM32WB5MMG 是 STM32WB55 的模块化封装内部是双核架构。M4 核跑用户应用M0 核跑无线协议栈。无线协议栈不是放在用户 App 工程里一起编译的而是以独立固件形式存放在安全 Flash 区域由 FUSFirmware Update Service固件升级服务统一管理。换句话说你更新 BLE 功能、802.15.4 功能不是重新编译 App 那么简单而是要把 FUS 和协议栈本体都保持正确版本。为什么要动这套东西常见场景包括协议栈发布安全补丁、BLE 要升级到新的连接参数特性、产品过认证需要指定栈版本、产线需要统一固件基线。还有一个容易被忽略的原因如果你刚拿到新版本的 STM32Cube_FW_WB 固件包新栈往往要求 FUS 也升级到对应版本否则 FUS 会拒绝写入新栈。所以这次我干脆把 FUS 和软件栈一起刷掉省得后面反复折腾。1.2 先认清三种升级路径升级路径我实测可用的有三种。第一种是通过 STM32CubeProgrammer 的 SWD 接口直接操作这是我最常用的方式。设备端不用跑任何 App只要 ST-LINK 能连上 M4 核就行最适合开发阶段和产线预烧。第二种是 STM32CubeMonitor-RF 之类的工具通过无线通道下发升级适合产品已经发到客户手里、想远程修 bug 的场景。但 OTA 依赖当前栈本身还能正常工作如果栈已经坏了这条路根本走不通。第三种是自研 Bootloader 或者 App 里集成 FUS 命令通过 UART、USB 或 SPI 发送升级帧适合量产后的自更新方案。从稳妥角度看本地开发我强烈建议优先走第一种。原因很简单它不依赖业务代码不依赖无线状态只要硬件连接正常大概率能救回来。三条路径的差异可以先记一下升级路径适用场景优点缺点STM32CubeProgrammer SWD开发、产线不依赖栈和 App需要拆外壳接线STM32CubeMonitor-RF / OTA远程维护无需物理接触栈损坏时无法使用FUS 命令集成在 App 中量产自更新可控性强需要额外开发和测试成本不少朋友一上来就写 OTA我的建议是先把 SWD 流程跑通确认版本组合没问题再上 OTA 不迟。1.3 版本兼容性怎么查升级前第一件事不是下载固件而是查兼容性。STM32CubeProgrammer 连接后能看到当前 FUS 版本和无线栈版本也可以在芯片内部信息里读出来。目标版本怎么选打开 STM32Cube_FW_WB 固件包的 Release Notes里面通常有一张 FUS 版本与无线协议栈版本的对应表。另一个重要依据是固件文件名。以我这次用到的文件为例文件含义FUS_0.10.0_1.1.0.binFUS 固件文件名里的版本号需要和 Release Notes 对应stm32wb5x_BLE_Stack_1_15_0_fw.binBLE 协议栈固件stm32wb5x_BLE_Stack_light_fw.bin轻量版 BLE 栈固件不同版本的固件包文件名规律相同。查 Release Notes 时要特别注意对应关系不是随便拿个新版本就能往上刷。我自己总结了一条经验先升 FUS再升栈最后重新烧 App这个顺序不要乱。2. 升级前的准备与关键细节2.1 硬件连接和电源检查STM32WB5MMG 是模块很多朋友直接用手头的 DC-DC 电源给它供电。这里要特别提醒模块在开启射频发射时瞬时电流会明显上跳供电纹波一大升级过程中 MCU 自己复位整个更新大概率失败。我在实验室吃过这个亏后来换了一台稳压电源并把 SWD 线缩短到十厘米以内问题才解决。连接方面至少接 SWDIO、SWCLK、GND、NRST 四根线。如果板子自带 ST-LINK直接用 USB 连接即可如果是裸模块建议用独立 ST-LINK。ST-LINK 和模块必须共地别偷懒只接一根信号线。NRST 被 STM32CubeProgrammer 用来控制复位这条线不能省。还要注意 BOOT0 引脚。STM32WB5MMG 支持系统 Bootloader 启动。通过 SWD 连 FUS 时一般不需要改 BOOT0但在某些恢复场景下要把 BOOT0 拉高进入系统 Bootloader再用 UART 或 USB 重新刷写。这个细节等到排错部分我会再提。2.2 工具链和固件文件清单需要准备的东西不算多但版本要对得上。STM32CubeProgrammer版本尽量新老版本对 STM32WB 的 FUS 更新支持不完整。和你的目标栈配套的 STM32Cube_FW_WB 固件包里面包含 FUS 二进制、BLE 和 802.15.4 栈二进制。ST-LINK 驱动以及一个能用的串口工具主要用于看 App 日志。如果模块上已经烧了用户 App准备一份 App 的.bin或.hex升级完栈之后大概率需要重新下载。有一点很容易被忽略固件包解压路径不要带中文和空格否则后续工具解析路径会出奇怪问题。尤其是从网盘下载的压缩包解压出来常常是“新建文件夹 (1)”之类的路径我建议先改成一个干净的英文路径再开始操作。2.3 理解 FUS 和软件栈的边界FUS 不是传统意义上的 Bootloader。它跑在 CPU2M0 核的安全侧主要做三件事管理 FUS 自身升级、安装无线协议栈、维护安全通信密钥。CPU2 的代码和栈区域在 Flash 中有独立分区M4 核的应用没有直接改写权限必须通过 FUS 的机制去更新。看一下 STM32WB 的 Flash 布局就能理解FUS 位于安全 Flash 区域系统启动时先由它接管。无线协议栈放在另一个特定区域由 FUS 加载到 CPU2 运行。M4 核的用户 App 放在普通 Flash 区应用通过 API 与 CPU2 通信。正因为分区隔离严格所以升级过程中要注意 RDP读保护和 PCROP代码保护。如果之前为了防抄板把 RDP 设成了 Level 1SWD 读操作会被限制升级前需要评估是否要临时降级。RDP Level 2 更危险一旦设置基本等于永久锁定调试口只能靠系统 Bootloader 恢复很多情况下板子直接废掉。我不建议新人在升级流程里碰 RDP。3. 实操流程从确认版本到完成升级3.1 第一步连接设备并备份当前状态把 ST-LINK 连好后打开 STM32CubeProgrammer选择 ST-LINK 连接方式点击连接。如果模块里已经有正常应用你会看到 Flash 起始地址上有内容也可以在 STM32WB 相关页面看到 FUS 版本和栈版本。我习惯先做两件备份操作。第一把 Option Bytes 完整截图或导出方便恢复配置第二如果用户 App 还有价值用 Read 功能把 Flash 内容导出成.bin文件。虽然升级 FUS 不一定会擦掉用户 App但“不一定”三个字不能作为不备份的理由。备份后把当前版本号记下来。我这次升级前是 FUS 0.9.xBLE 栈 1.13升级目标是 FUS 0.10.xBLE 栈 1.15。记录版本号可以帮你在升级失败后快速判断是哪个环节出了问题。3.2 第二步升级 FUS在 STM32CubeProgrammer 里找到 STM32WB 的操作区通常在 Firmware Upgrade 页面。这里有两个关键功能FUS Upgrade 和 Wireless Stack Upgrade。先做 FUS Upgrade。点击 FUS Upgrade选择你刚才准备的 FUS 二进制文件比如FUS_0.10.0_1.1.0.bin确认后开始升级。工具会先复位设备并进入 FUS 模式然后通过私有协议把新 FUS 写入安全区域。整个过程大概一两分钟视供电质量而定。升级期间不要碰 USB 线也不要手动复位模块。这里有个很多人忽略的细节FUS 更新如果跨大版本工具可能先执行一次擦除擦掉原来的无线栈和部分安全存储导致升级完成后回去看栈版本变成了空。所以 FUS 升级完成后不要急着跑 App先重新进入 STM32WB 页面看 FUS 版本号是否已经更新同时确认栈是否还在。如果栈丢了进入下一步重新刷。3.3 第三步升级无线协议栈FUS 就绪后回到 Wireless Stack Upgrade 页面。选择对应的栈固件这里要特别注意选 BLE 全功能版还是轻量版。全功能版连接更多、特性更全但占用 Flash 和 RAM 更多如果项目只做两三个连接轻量版完全够用。选错变体虽然不会让升级失败但可能导致 App 内存不够运行后偶发死机这种问题非常难查。点击 Start Stack Upgrade。工具会把栈文件发送给 FUS由 FUS 完成校验和安装。进度条走完后设备会自动复位栈版本号应该更新到目标版本。我实测下来如果 FUS 和栈版本兼容这一步基本不会失败。3.4 第四步恢复用户 App 并验证栈更新完用户 App 可能还在也可能已经被擦掉。稳妥做法是重新烧录一次 App。用 STM32CubeProgrammer 的编程页面选择 App 的.bin文件烧录后复位。验证环节是关键。串口日志应该能看到 App 初始化 CPU2 成功并打印出栈版本。如果日志里有类似 Stack version 的字样对照一下是否为预期版本。没有日志的话最简单的验证方法是打开手机蓝牙扫描设备名称能扫到就说明 BLE 栈已经在正常跑。注意不要只验证一次因为有些栈资源问题会在重连几次后才暴露。3.5 关于自动化和产线刷写开发阶段手工点按钮没问题产线不能一台台点。STM32CubeProgrammer 提供了命令行工具STM32_Programmer_CLI可以完成连接、擦除、下载等操作适合写脚本跑。我一般会写一个简单的批处理脚本把 FUS 文件、栈文件、App 文件按顺序下载并在每一步之后检查返回码失败就终止。但有一点要说明命令行对 FUS 和栈升级的覆盖能力不如 GUI 直观不同版本的工具参数有差异。我第一次写脚本时直接照抄网上的命令结果在 FUS 升级环节失败最后还是回到 GUI 里观察状态才发现是工具版本太旧。我的建议是先用 GUI 跑通一次再考虑脚本化。4. 常见问题与排查技巧实录4.1 FUS 升级完栈还是老版本这个现象我遇到不止一次。FUS 升级成功但回来后看栈版本仍然是旧版。原因一般是升级 FUS 时把栈区域擦了但工具没有自动刷新栈的显示或者模块没有彻底断电。处理方式很简单把模块完全断电重新上电再连一次 STM32WB 页面看栈版本。如果确实空了按 3.3 的步骤重新刷栈。还有一种情况FUS 版本太老拒绝安装新栈。这通常表现为升级栈时进度条卡住或者弹出一个未知错误。解决方法是先更新 FUS 到支持该栈的版本再刷栈。4.2 升级后 M4 应用连不上 CPU2栈刷好了但 App 起来后 BLE 初始化失败无法和 CPU2 通信。这类问题十有八九是栈变体不对或者 App 编译时用的栈版本接口与当前栈不一致。比如 App 是基于旧版 SDK 编译的硬对接新栈内部结构已经变了初始化很容易崩。排查思路先确认栈版本确实是对的再确认栈变体是否匹配 App 的配置。如果对不上要么换回旧栈要么升级 App 代码里的栈相关驱动和库。另外注意 CPU2 的复位逻辑。刷完栈之后要确保 M4 复位后 CPU2 也处于正确状态。很多人只复位 M4CPU2 还停在旧状态通信自然错乱。彻底断电再上电是最省事的办法。4.3 连接失败、端口消失和超时STM32CubeProgrammer 提示连接失败或者 ST-LINK 在升级过程中掉线这类情况往往不是软件问题而是硬件连接。SWD 线太长、接触不良、供电不足都会导致。排查顺序我一般是先看 ST-LINK 驱动能不能识别到目标再用万用表确认 3.3V 电源正常最后才怀疑软件配置。如果 ST-LINK 能识别但连接不上检查复位引脚。有些板子在复位期间被外部电容拉低导致升级信号发不进去。4.4 RDP 和 PCROP 保护导致刷写失败如果设备之前设置过 RDP 或 PCROP升级时可能看到读保护相关错误。RDP Level 1 下STM32CubeProgrammer 通常能连接但无法读取 Flash而 FUS 更新本身需要一定访问权限导致失败。解决方案是先在 Option Bytes 里把 RDP 降回 Level 0。这个操作会触发整片擦除所以之前的备份意义就在这里。PCROP 则需要在 Option Bytes 里检查代码保护区设置临时移除保护后再升级。如果产品最终要开保护务必在全部固件升级验证完成后再打开。4.5 常见问题速查表现象可能原因处理方式FUS 版本不更新设备未彻底断电断电上电后重新读取栈升级卡住FUS 版本过旧先升级 FUS再刷栈BLE 初始化失败栈变体不匹配换匹配的栈变体或升级 App 栈库ST-LINK 连接失败SWD 线过长或供电不稳缩短线缆、换稳压电源报 RDP/PCROP 错误读保护或代码保护开启临时降低 RDP 或移除 PCROP刷完 App 无法启动栈和 App 版本不匹配按 Release Notes 组合版本重刷5. 实操心得与避坑建议5.1 我怎么判断升级是否真正成功很多人看到 STM32CubeProgrammer 提示 Success 就觉得完事这个不够。我自己判断升级成功有几个硬标准串口日志无错误蓝牙扫描能看到设备连续开关机十次都能正常重
返回列表