企业官网建设流程全解析

“UM2825”这个编号刚拿到手的时候，容易被人当成又一份平平无奇的开发板用户手册。但如果你手里恰好是ST官方那块“具有STM32WB5MMG模块的探索套件”，我建议你在插USB之前，先把这份文档过一遍。它对应的板卡型号是STM32WB5MM-DK，核心不是普通MCU，而是把MCU、射频收发器、晶振、匹配网络和天线全部打包在一起的STM32WB5MMG模块。换句话说，UM2825不是一份“看看接线图”的PDF，它决定了你后续能不能顺利跑通BLE、Thread和Zigbee，也决定了你测功耗、改天线、做认证时会不会少走弯路。

这篇文章我会按一个嵌入式工程师正常的“上手路径”来写：先看硬件资源，然后把第一个BLE例程跑起来，接着去折腾无线栈和FUS，最后聊聊低功耗、射频实测和板卡恢复。整个过程中，你会反复回翻UM2825，所以我会把这份文档里真正值得看的东西也一并拆开。

1. 板子到手先别急着写代码：UM2825里的硬件信息要这么看

1.1 一块板子两个称呼，先搞清你在查哪个

ST搞“文档编号”和“板卡编号”是两套体系，新手经常被绕晕。UM2825是用户手册编号，全称语义就是“具有STM32WB5MMG模块的探索套件”，而实际硬件名称是STM32WB5MM-DK。你上官网搜索的时候，直接搜“STM32WB5MM-DK”比搜“UM2825”更容易找到板卡页面和对应固件包。

这块板子和常见的Nucleo开发板有一个本质区别：Nucleo板上贴的是裸芯片，而STM32WB5MM-DK的核心是一颗完整的SiP模组。模组内部把STM32WB55系列芯片、高频晶振、低频晶振、射频匹配、电源去耦以及天线都做了进去。你拿到手看到的是模组外面只有几个引脚，但真正决定该模块好不好用的所有射频细节，都已经在模组封装里固定下来了。

UM2825第一章通常会放一张“板卡框图”和“整体布局图”。很多人直接跳过，我建议你别跳。因为这张图里标了板载ST-LINK/V3的位置、模块的位置、电源路径、LED和按键，以及几个关键跳线的功能。没有这张图，后面测量功耗时你可能不知道该拆哪个跳线。

1.2 板载资源里，容易被忽略的那几个细节

STM32WB5MM-DK上的板载外设，不同批次可能略有差异，但几个关键思路是一样的：板载ST-LINK/V3调试器、USB接口、LED、按键，以及若干环境传感器和功耗测量点。

最容易被忽略的是ST-LINK/V3。它不只是烧录器，还带虚拟串口（VCP）功能。很多官方例程的日志输出就是走这个虚拟串口，不需要你额外接USB转TTL小板。这一点对调试非常方便，但前提是驱动要装好。Windows下，安装STM32CubeIDE或STM32CubeProgrammer时通常会一并装好驱动；Linux下则需要处理udev权限规则，否则ST-LINK设备可能被系统识别到却没权限访问。

另一个细节是“目标供电跳线”。板上ST-LINK和模块之间不是直接短接的，中间通常会留出跳线或0欧电阻位，目的是让你在测量模块功耗时能把调试器部分隔离开。很多人拿到板子第一步就是测功耗，结果万用表夹在USB电源入口，测出来的数值永远对不上数据手册，原因就是ST-LINK、传感器、LED的电流全混在里面了。

1.3 供电路径和调试链路的逻辑

STM32WB5MM-DK直接插USB就能工作，USB给板载ST-LINK/V3供电，再由ST-LINK上的稳压器输出目标电压给模块和外设。这套设计对评估开发非常友好，但有个反直觉的点：如果你要测试模块在低功耗模式下的真实电流，最好使用外部电源从目标侧供电，而不是依赖USB电源。官方在UM2825里对测量方式有说明，实操思路可以概括为“断开板载供电跳线、在供电回路里串电流表、确保板载调试器不参与目标侧供电”。

调试链路方面，UM2825会告诉你ST-LINK/V3如何使用SWD口访问STM32WB5MMG。这里有个细节：模块封装的是小封装，SWD引脚并不是标准插针，开发板已经帮你把调试口引出到ST-LINK/V3了。真正做自己产品时，如果你用的也是STM32WB5MMG模块，一定要在PCB上保留SWD测试点，否则量产板一旦固件异常，只能干瞪眼。

2. STM32WB5MMG模块的双核分工，决定了你写程序的方式

2.1 模块不是“帮你少画一点板”这么简单

很多人觉得STM32WB5MMG的价值就是省了天线设计和画板麻烦，这当然没错，但不全面。它真正的价值是把射频链路从“设计问题”变成了“选型问题”。自己做分立方案时，天线匹配、走线阻抗、晶振布局、EMI滤波，每一个环节都可能让无线距离、功耗、认证结果发生天翻地覆的变化。模块方案里，这些已经被原厂固定并验证过，BOM成本会高一些，但研发风险低很多。

UM2825里关于模块的硬件描述并不多，真正的引脚定义、天线净空区域、模块封装尺寸，要看STM32WB5MMG的数据手册。但探索套件存在的意义，就是让你在画PCB之前，先把模块的性能在官方验证过的板子上摸清楚。

2.2 M4和M0+各管什么

STM32WB5MMG内部是一个双核架构：Cortex-M4主要负责应用逻辑和计算，Cortex-M0+负责无线协议栈和底层无线处理。两个核通过IPC mailbox机制通信，共享内存缓冲区来传递数据。

为什么非要单独放一个M0+跑无线栈？因为BLE或802.15.4的协议栈非常在意时序。以BLE为例，每个连接事件的收发窗口是毫秒级甚至亚毫秒级的，如果协议栈和应用代码跑在同一个核上，应用某个长时间关闭中断的临界区就可能让协议栈错过射频事件，最终表现为连接不稳定、丢包、连接频繁断开。

M0+独立跑协议栈后，这种问题被隔离开来。你的应用代码即使写得再“奔放”，只要不是把M4的电源电压搞崩，M0+那边的无线时序一般不会受影响。反过来，M4可以利用全部算力去做业务逻辑。

对应到编程习惯上，你会看到官方例程里有大量和IPC相关的回调，比如HW_TS、tl_recv_data这类函数。这些都是M4与M0+通信的桥。刚上手时，不需要把所有IPC细节搞得很深，但要明白一个原则：M4发送数据给对端不是直接操作射频硬件，而是把数据交给M0+侧协议栈，协议栈再排队发送。这也是为什么某些教程会让新手用“中断接收、主循环处理”的惯性思维去写BLE，很容易踩坑。

2.3 集成天线和认证收益

STM32WB5MMG模块自带天线，这是它跟很多需要外接天线的Wi-Fi/BLE模组不一样的地方。模块内部已经做了天线匹配，外部只需要保证模块天线区域净空、不要在它周围铺铜、不要用金属外壳遮挡。

认证收益往往被低估。产品要做无线认证时，天线设计、匹配网络、PCB layout都是摇摆因素。如果模块本身已经通过了模块级认证，并且你的整机设计严格贴着参考设计，那么整机认证的工作量会小很多。探索套件虽然不能直接拿去做产品认证，但它是你验证“模块性能够不够”的最佳参照物。

以下是模块方案和分立SoC方案的大致对比：

如果你做的是量产产品，时间成本和射频不确定性往往是最大的成本。模块方案算的是总账，不是单颗BOM的账。

3. 从零跑通第一个BLE例程：环境、编译、烧录、验证

3.1 工具链版本匹配，是第一步也是最大的一步

跑STM32WB5MMG的BLE例程，推荐用下面这套组合：

• STM32CubeIDE：集成编译、烧录、调试，最省事。
• STM32CubeProgrammer：看无线栈版本、FUS状态，执行栈升级，必装。
• STM32CubeWB固件包：ST官方为STM32WB系列准备的SDK，里面包含例程、库和无线栈镜像。

版本匹配问题经常让人头大。STM32CubeIDE持续迭代，STM32CubeWB固件包也在持续更新。如果两个版本相差太远，导入工程时可能出现一堆莫名其妙的编译错误，实际上只是库版本和IDE内部的CMSIS组件不匹配。我的习惯是直接装最新版IDE，同时下载最新版CubeWB，避免被一些老坑绊住。

在STM32CubeIDE里导入例程，最常见的方式是File -> Import -> Existing Projects into Workspace，选择CubeWB里对应板卡的工程目录。工程路径一般长这样：

STM32CubeWB/Projects/STM32WB5MM-DK/Applications/BLE/BLE_HeartRate

注意，不同CubeWB版本目录结构可能略有变化，比如有的把例程放在Applications/Connectivity下。找不到时别硬找，看看目录列表里有没有Connectivity或者BLE关键字。

3.2 烧录App之前，先确认无线栈是否还在

STM32WB5MM-DK出厂时，ST一般会预烧FUS、BLE无线栈和示例应用。所以你在IDE里直接把官方BLE例程编译好，烧录进去，通常就能跑起来。

但这里有一个非常重要的常识：你在STM32CubeIDE里点击Run，下载的是Cortex-M4侧的Application。M0+侧无线栈是另一段固件，它不在Application的编译链接范围内。如果你的板子出厂软件被擦过，或者你之前用STM32CubeProgrammer做过“Full Chip Erase”，那么即使Application烧录成功，BLE也可能完全搜不到设备。

判断方法很简单：打开STM32CubeProgrammer，连接ST-LINK，查看M0+侧存储器或无线栈版本信息。如果版本号为空，说明无线栈没了，需要先重烧无线栈再烧App。别问我为什么知道这个坑——我自己就曾经很自信地擦了个全片，然后对着手机搜不到设备发呆了半小时。

3.3 编译、烧录和连接逻辑

以BLE_HeartRate例程为例，编译通过后，直接Debug或Run都行。连接ST-LINK后，IDE会通过SWD把固件烧进M4。烧录完成，板子复位，此时M4应用会通过IPC要求M0+启动BLE协议栈，协议栈随即开始广播。

手机端用ST官方App“ST BLE Sensor”或者“ST BLE Toolbox”扫描，可以看到一个广播名类似“HR”或者工程默认名称的设备。连接上之后，设备页可以看到模拟的心率数据。

如果扫描不到设备，优先看这几样：

• 板载LED是否在闪烁。大多数官方例程会用一个绿色LED来指示BLE广播状态，如果LED没动作，大概率是栈没跑起来。
• VCP串口日志有没有输出。STM32WB例程启动时会打印协议栈版本和初始化状态，如果串口没日志，先确认串口终端波特率是否和例程一致。
• ST-LINK/V3驱动和VCP枚举是否正常。Windows下打开设备管理器看有没有识别到ST-LINK设备；Linux下先确认udev规则。

3.4 串口波特率别想当然

官方例程的VCP输出波特率不是固定的，有的是115200，有的是921600。如果你用250000去读，看到的就是乱码。最好的做法是先去例程的app_conf.h里搜索CFG_DEBUG_TRACE或者LOG相关的定义，看它配置的波特率是多少。这个细节在UM2825里未必会提，但属于SDK例程里最常见的坑。

4. 无线协议栈烧录、FUS升级和并发模式部署

4.1 无线栈为什么要单独烧，而不是编进App里

STM32WB的无线栈运行在M0+核上，也有自己独立的安全启动流程。用户Application跑在M4核上，两个核共享Flash资源，但链接地址是分开的。你的M4工程在编译时会避开M0+栈所占用的Flash区域，也就是说，M4的Hex文件里根本不会包含无线栈二进制。

这就导致一个和普通MCU开发完全不同的习惯：烧录App只是半个步骤，无线栈本身要通过固件升级方式写入M0+侧。板子出厂时可能已经有BLE栈，但如果你要切换到Zigbee、Thread，或者要更新栈版本，就得走FUS流程。

FUS的全称是Firmware Upgrade Service，可以简单理解为M0+里的一个小型“Bootloader”。每次启动时，M0+首先执行FUS，再由FUS加载无线栈镜像。FUS本身也独立于应用，它负责无线栈的分区管理、版本校验和升级操作。

4.2 FUS升级的步骤与版本匹配

用STM32CubeProgrammer升级无线栈，大致思路是这样的：连接ST-LINK，打开“Firmware Upgrade Services”面板，选择对应的无线栈镜像文件，然后点击升级。部分版本也支持命令行：

STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -fwupgrade name=stm32wb5x_BLE_HCI_fw.bin

注意，这里stm32wb5x_BLE_HCI_fw.bin只是举例。不同CubeWB版本中的镜像文件名可能会写为stm32wb5x_BLE_Stack_fw.bin，所以实际操作时以固件包实际文件为准。

最让人疼的是版本匹配。M4侧的Application在编译时，默认关联了特定版本的无线栈，比如CFG_BLE_MAX_CONNECTION、BLE_STACK_VERSION这类宏定义，会和栈内部的版本号比对。如果你发现BLE能初始化但总是连接不上，或者官方例程跑起来后手机一连接就复位，大概率就是M4 App和M0+栈版本不匹配。

解决思路很简单：不要混搭。每次更新CubeWB时，把配套的无线栈镜像同步刷进去，再烧对应Application。官方例程目录里通常有专门的Projects/STM32WB5MM-DK/Applications/BLE和对应的Wireless_Binaries目录，前者是工程，后者是配套镜像，两者对齐使用。

4.3 BLE和Thread/Zigbee动态并发的实际体验

STM32WB5MMG的一个重要能力是“动态并发”，也就是同一时刻运行BLE和802.15.4协议栈。比如设备可以同时作为Thread节点和BLE外围设备，一边联网，一边用手机App配置。

这项能力听起来很炫，但它的角色组合有严格限制。不是所有BLE角色都能和Thread/Zigbee共存，官方应用笔记里会列出支持的并发组合。以BLE Peripheral和Thread Router这样的组合比较常见，而BLE同时做Central又导线程，往往就不在支持列表里。

跑并发例程的时候，需要先烧一个“同时包含两个栈”的镜像，再烧M4侧的Concurrent Application。这个镜像通常比单BLE栈更大，烧录时间也更长。UM2825里不会详细讲并发协议细节，但它会告诉你板子上如何选择启动模式、如何看板载指示灯状态来区分当前工作在哪种模式。

我的建议是：初次接触STM32WB，先不要碰并发模式。先把BLE跑通，再把Thread或Zigbee单独跑通，最后再试并发。否则当板上两个栈同时初始化时，你很难判断问题到底出在M4 Application、FUS还是栈组合上。

5. 用探索套件做低功耗和射频实测的经验

5.1 测电流的位置，决定了数能不能看

STM32WB5MMG的低功耗特性是它的一大卖点，但探索套件上测电流并不是“万用表夹住USB口”就行。USB口供电是所有电路的源头，包含ST-LINK和板载外设电流，测出来的数会比模块真实功耗大好几倍，完全没有参考价值。

正确做法是找到UM2825里标出的目标供电测量点，把测试跳线帽取下，在跳针两端串入电流表。如果板上不是跳线而是0欧电阻，那就要先焊下电阻再接电流表，或者从供电接口处做“注入式”测量。

这里我分享一个实操经验：别用普通万用表的电流档去测低功耗模式。STM32WB的Sleep模式电流可能低至微安级，普通万用表电流档的内阻和分辨率都未必够。最好用带积分功能的功率分析仪，或者至少用一台支持微安级分辨率的台式万用表。如果没有，那就用串联电阻测电压再换算。

5.2 天线净空区域比你想的更严格

STM32WB5MMG模块自带天线，但“自带天线”不代表“板子上随便放都行”。模块数据手册里一定会有一个天线净空区域，也就是模块周围一圈禁止铺铜和布线的区域。你评估探索套件时感受不到这个问题，因为官方板已经把这个区域留好了。但如果你自己画板，把模块贴在铜皮密集的区域，天线性能会大幅下降。

我在自研板上第一次接触类似模块，经验告诉我：不要想着“就铺一点铜不影响”，天线近场区的铜皮和地平面直接影响天线效率。模块周围至少要保证数据手册要求的净空，天线正上方不要走平行长线条，也不要让外壳金属件紧贴天线位置。

5.3 距离测试时，USB线和调试器就是干扰源

在探索套件上做BLE距离测试，最容易犯的错是插着USB线和ST-LINK开始测。USB线、ST-LINK调试线以及板上的VCP通路都会成为意外的天线辐射体，它们会让接收信号质量变得很奇怪。你测出的“10米就断连”不一定代表模块不行，可能只是你的测试环境里躺着一根USB线在捣乱。

我的做法是：涉及射频距离验证时，让板子用锂电池或干电池供电，彻底断开USB线和调试器。手机或对端设备离开发射板至少半米以上，避免近场耦合。同时，测试场地尽量选在周围没有大金属家具的室内环境。

如果距离还是明显偏短，就用ST OPENTX或频谱仪去看一下模块是否真的在发射，以及发射功率是否达标。这个探索套件本身已经调好天线和匹配，如果距离都上不去，优先怀疑供电噪声或附近干扰源，而不是怀疑模组设计。

6. 跳出UM2825：配套文档、板卡恢复和一条少走弯路的顺序

6.1 文档地图怎么搭配看

UM2825不是唯一要看的文档，但它是一切的入口。我通常这样搭配使用：

UM2825里关于无线协议栈的篇幅其实不多，因为它是一份“Development Kit”文档，解决的是板卡级问题。真正要理解无线栈、FUS、IPC，需要借助STM32CubeWB包里的文档目录，以及ST官网搜到的应用笔记。把这些文档配合起来看，效率远高于反复试错。

6.2 板卡被锁死的恢复方案

玩STM32WB很容易因为不小心开启RDP（读保护）把板子锁死。尤其是你折腾Option Bytes，或者在某次调试中勾了一个不该勾的保护选项，之后ST-LINK就无法正常连接MCU。解决方法是使用STM32CubeProgrammer的Hot Plug模式，强制连接，然后把RDP等级降回Level 0。

命令行方式大致是：

STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -ob RDP=0xAA

RDP=0xAA对应Level 0，也就是解除读保护。需要注意，执行这个操作通常会擦除整个Flash，包括M0+侧无线栈。解除保护后，你必须重新烧录FUS和无线栈，再烧Application。

我个人的建议是：不要轻易对这块开发板做“Full Chip Erase”。STM32WB的Flash里不只是你的代码，还躺着协议栈和FUS。每次需要清板时，先在STM32CubeProgrammer里记录一下当前无线栈版本，再决定是否擦除。养成这个习惯之后，能省下很多“恢复出厂设置”的时间。

6.3 一条比较顺的学习路径

结合我自己玩这块板子的过程，如果让我重新走一遍，我会按这个顺序来：

1. 先跑官方BLE_HeartRate例程，只改广播名和连接参数，理解BLE基础流程。
2. 再用P2P Server/Client例程，理解GATT服务和数据收发。
3. 然后找一个下午专门研究FUS升级，把BLE栈升级到和CubeWB匹配的版本，彻底搞清楚M0+和M4的关系。
4. 之后跑Thread或者Zigbee的单协议例程，理解802.15.4和BLE的差异。
5. 最后再碰并发模式。

这套顺序的考虑是：BLE例程最容易看到成果，先建立信心；FUS是最容易翻车也最容易让人退缩的环节，必须在前面解决；并发模式建立在单协议栈完全熟悉的基础上，否则出了问题你根本定位不了。

最后再分享一个我从踩坑里换来的小技巧：在STM32CubeIDE里点Run，IDE默认只会下载M4侧的Application，它不会检查M0+侧无线栈是否存在。所以每当你换了一个例程、换了一个CubeWB版本，烧录前先用STM32CubeProgrammer看一眼M0+侧栈版本。这一步只要花30秒，但它能省掉你至少半天“为什么连不上”的排查时间。