手里拿到一块 Nucleo-WBA25CE1 开发板第一件事不是点灯而是把它切到 Direct Test ModeDTM里跑一趟射频指标。这个标题看着像是蓝牙协议栈里的一个冷门模式实际上凡是做 BLE 产品的硬件工程师、射频调试工程师还有准备做蓝牙认证的研发朋友都绕不开它。这篇文章我就把为什么需要 DTM、怎么在 Nucleo-WBA25CE1 上把 DTM 跑起来、以及实操中常见的坑串成一条完整链路记录下来希望能帮到正在折腾同样事情的你。先说结论性的一句话Direct Test Mode 是蓝牙核心规范里为射频物理层测试专门定义的一种工作模式它让设备不经过完整的蓝牙协议栈直接在 PHY 层做收发测试。对开发板来说这就等于给射频前端开了一个“旁路开关”我可以绕开 GAP、GATT 这些上层逻辑直接命令射频芯片在指定信道上发射特定包型、或者在指定信道上接收并统计误包率。对正在调试射频匹配、准备做认证预扫、或者想评估板卡发射功率的人来说这是最快、最干净的验证手段。下面我按照完整的实操链路来写从原理到工具从编译烧录到测试执行最后是问题排查大家可以根据自己的情况直接跳着看。1. 为什么偏偏要用 Direct Test Mode 验证 NUCLEO-WBA25CE11.1 从测试视角理解 DTM绕开协议栈直达射频底层蓝牙设备平时工作的时候数据要经过应用层、GATT 层、L2CAP 层、链路层最后才到射频物理层。这个链路好处是功能完整坏处是如果我想精确测量某个频点的发射功率、频率误差、调制特性这些上层协议反而成了干扰变量。DTM 的思路很直接把链路层之上全部摘掉只保留物理层收发让测试设备通过一串很简单的控制命令就能让 DUT被测设备持续发射或者接收。打个比方这就跟汽车出厂前的台架测试一样。整车路测需要考虑路况、变速箱、驾驶习惯但发动机本身有没有问题得把发动机拆到台架上直接踩油门看转速稳定不稳定、功率曲线达不达标。DTM 就是这个“台架”它测试的是射频前端本身的能力抛开了协议栈的调度影响。具体到 Nucleo-WBA25CE1 这块板子它用的是 ST 的 STM32WBA 系列无线 MCU集成了 2.4GHz 射频收发器。在正常 BLE 工程里射频模块由协议栈驱动但一旦进入 DTM单片机里的协议栈主体不参与工作取而代之的是一小段 RF 驱动代码它等待接收来自测试仪或者串口的 DTM 控制命令然后立刻执行对应的射频动作。这也解释了为什么 DTM 固件往往非常精简启动快、行为可控、没有多余的软件干扰。1.2 实际项目中 DTM 能解决什么问题很多朋友第一次接触 DTM 是卡在实验室认证那一步但实际上它的应用远不止认证。第一个场景是蓝牙 SIG 认证里的 RF-PHY 测试。做蓝牙认证时认证实验室会要求 DUT 进入 DTM然后把测试仪和 DUT 连接起来跑一组规定的发射、接收测试项。如果没有 DTM 支持设备没法被测试仪控制认证流程走不动。所以产品要过蓝牙认证DTM 几乎是必备能力。第二个场景是研发阶段的射频调试。比如你觉得天线的匹配不太好想看看板卡在信道 192440 MHz上的实际发射功率是否达标这时候只需要把 DTM 固件烧进去让射频持续在某信道发包再用频谱仪看结果。整个过程可以在几分钟内完成不用写一整套 BLE peripheral 应用代码。同样的测试接收灵敏度时可以让测试仪持续发射DUT 在 DTM 接收模式下统计误包率。第三个场景是产线射频校准。很多 BLE 模组厂在出厂前会对每个模组做射频功率校准和频偏校准产线上的自动化测试程序正是通过 DTM 命令来驱动待测模组搭配综测仪读取实际发射功率再通过调整内部寄存器来校准。这时候 DTM 不是可选项而是产测工具链的地基。2. 开发板与 DTM 测试环境准备2.1 先看清 NUCLEO-WBA25CE1 的硬件底细Nucleo-WBA25CE1 是 NUCLEO-64 规格的开发板核心是一颗 STM32WBA25 系列无线 MCUCortex-M33 内核主频 100MHz带 2.4GHz 射频收发器。板载了 ST-LINK 调试器通过一根 USB 线就能同时完成供电、调试和虚拟串口输出这对 DTM 测试来说非常方便——因为 DTM 控制命令和日志输出正好可以走这个虚拟串口。板卡上的 LED、用户按键、Arduino 兼容接口、ST Zio 扩展接口这些资源在 DTM 工程里一般用不到。但有一点要特别注意射频测试必须保证天线或者射频连接路径是正常的。开发板的天线区域一般会设计匹配网络和天线座如果你要做传导测试需要确认板上是否有 SMA 座或者预留的射频测试点如果是用 PCB 天线做辐射测试测试环境放在屏蔽箱里保证外部干扰不影响结果。供电也要提一嘴。BLE 射频发射电流并不小当射频连续发包时瞬时功耗会比单片机空跑高不少。建议用 USB 供电时选择质量好一点的线不要用那种只能充电不能传输数据的线。如果测试过程中发现发射功率异常偏低第一步先排除供电问题。2.2 四样工具一次备齐软件、固件、串口、射频仪器软件方面需要准备四样东西。第一个是 STM32CubeIDE或者其他支持 STM32WBA 系列的 IDE比如 Keil、IAR看个人习惯ST 生态下我用 STM32CubeIDE 最省事。第二个是 STM32CubeProgrammer用于烧录和擦除也可以直接在 IDE 里下载程序但 CubeProgrammer 在单独处理固件时更独立。第三个是 STM32CubeMonitor-RF这是 ST 官方的 RF 测试上位机工具支持把开发板变成一台简易信号源和分析仪具体支持程度要看工具版本对 WBA 系列的支持情况。第四个是串口助手我用过很多功能上其实都差不多自己习惯就好。射频仪器方面如果你手头有蓝牙综测仪比如 Anritsu MT8852B、Rohde Schwarz CMW270/CMW500、LitePoint IQxel 这一类那直接走正规 DTM 测试流程。如果暂时没有综测仪也可以用频谱仪加信号源做一个简化版测试前提是你能手动控制 DTM 信道和包型。这篇文章下面会分别讲这两种路径。串口驱动也要提前确认。Nucleo 板载 ST-LINK 的虚拟串口在 Windows 下通常会自动识别为 COM 口如果插上 USB 后设备管理器里看不到端口去 ST 官网装一下 ST-LINK USB 驱动。这一步看着简单但我在实践中遇到过好几次同事卡在“板子不亮串口”上最后发现就是驱动没装。2.3 测试连接拓扑根据测试方式选择接线在正式操作前先把线连对。大致分两种连接拓扑一是软件控制的闭环测试电脑通过 USB 连接开发板开发板的天线端连接测试仪器。电脑上的 STM32CubeMonitor-RF 或串口助手下发 DTM 命令DUT 执行发射或接收然后由仪器侧测量结果。这种方式适合快速验证发射功率和基本信号质量。二是测试仪直接作为 DTM 主控测试仪通过串口连接开发板的 UART 引脚DTM over 2-wire同时测试仪通过天线口连接 DUT。这个方式更贴近蓝牙认证实验室的做法因为测试仪会自己控制 DTM 命令序列逐项执行测试用例。使用这个方式时需要把开发板上的虚拟串口换成实际 UART 引脚具体引脚号以开发板手册和示例代码里的管脚定义为准。提一句做传导测试时天线如果没有断开或者没有通过良好屏蔽的同轴线接到仪器上测试结果会被周围环境干扰导致功率读数虚高或误包率异常。这是我见过最多的测试数据问题源头所以接线时不要图省事。3. 烧录 DTM 固件从 Cube 到串口 Log 全流程3.1 获取 STM32CubeWBA 固件包找到 DTM 示例工程STM32WBA 系列的外设驱动、BLE 协议栈和示例代码都在 STM32CubeWBA 固件包里。下载方式有两种在 STM32CubeMX 的软件包管理器里直接安装或者到 ST 官网下载对应版本的压缩包。安装好后固件包目录结构大概是STM32Cube_FW_WBA_Vx.y.z里面按板卡和例程分类存放。要找 DTM 例程在Projects目录下进入对应板卡目录例如Projects/NUCLEO-WBA25CE1/Applications/BLE/里面应该能看到带有 DTM 或 RF 关键字的应用工程比如BLE_RF_DTM。如果你的固件包版本还没有预置 WBA25CE1 的板级例程也不要慌可以找一个同系列相近板卡的 DTM 工程复制后通过 STM32CubeMX 重新选择 Board 或者 Device调整引脚后再编译。这一步就是 STM32Cube 生态常规操作只要原理图匹配基本能启动。顺带提醒一下STM32CubeWBA 固件包里不同版本的示例代码可能在文件名、目录结构上有差异不要拿着旧版本的教程硬套新版本路径。最稳的做法是在工程目录下搜 “DTM” 关键字或者看 README 里的描述确认例程是不是做射频直接测试的。3.2 编译、烧录与串口验证一个环节都不能省拿到例程之后下一步是编译。用 STM32CubeIDE 直接导入工程文件一般选.project或.ioc所在的目录。导入后先检查工程配置里的芯片型号确认是 STM32WBA25 系列。如果编译器报找不到头文件或器件定义多半是固件包版本与 IDE 器件支持包不匹配去 CubeMX 里更新一下固件包或者在 IDE 中更新器件库。编译通过后把开发板通过 USB 连到电脑在 IDE 里选择调试方式为 ST-LINK点击下载。烧录完成后打开设备管理器确认虚拟串口的 COM 口号用串口助手打开。DTM 示例工程通常会在启动时打印一些日志比如固件版本、初始化成功信息、进入 DTM 等待命令的提示。如果串口一个字都不打印先查驱动和 COM 口号再查工程里的日志默认波特率是不是和你串口助手一致。常见默认波特率是 115200但有些工程会用 921600不要想当然。这里有第一个关键心得DTM 示例的日志输出和 DTM 命令入口在很多 ST 例程里是复用同一个 UART 的。也就是说你在串口助手里既能收到启动日志也能直接往下发 DTM 命令字节。所以在正式测试前先确认一下这个串口是不是命令通道。如果用 STM32CubeMonitor-RF它会自动识别并打开这个端口不要和串口助手同时占用同一个 COM 口否则会互相冲突表现为“端口被占用”或命令无响应。4. 三种方式实操 NUCLEO-WBA25CE1 的 Direct Test Mode4.1 方式一用蓝牙综测仪做标准的 DTM 测试这是最接近实验室认证的方案。你需要一台蓝牙综测仪比如 Anritsu MT8852B 或者 CMW270以及一根合格的射频电缆。连接方式是综测仪的 RF 口通过线缆连接到开发板天线端最好在测试前先校准线缆损耗把这个损耗值在综测仪里做补偿。然后需要让 DUT 进入 DTM over UART 模式。把开发板的 UART 引脚连接到综测仪的 DTM 控制口。不同综测仪的物理接口可能不一样有的用 DB9 串口有的用 USB 转串口需要做一个电平转换和接线板。接线前一定要确认电平一致BLE 的 DTM UART 一般是 3.3V TTL很多蓝牙测试底板也是 3.3V但还是量一下最稳电平不一致轻则通讯失败重则烧引脚。综测仪上选择 Bluetooth LE 的 Direct Test Mode 测试项配置需要的信道、包长和包型。测试仪下发命令后DUT 就会开始发射或接收仪器端实时显示发射功率、频率误差、调制特性、接收误包率等指标。这套流程的优势是自动化程度高测试项覆盖完整和蓝牙认证实验室的测试方法保持一致适合在产品定型前做一次全面的射频体检。如果条件允许建议至少跑这几个测试项单信道发射功率最低信道、中间信道、最高信道各测一次、频率偏移和漂移、发射调制特性、接收灵敏度。这些指标能覆盖射频前端大部分问题。测灵敏度时仪器会在不同功率电平下发射DUT 在接收模式下提交统计结果测试仪自动算出临界灵敏度。整个过程跑完可能需要几分钟但它给出来的信心值远高于“频谱仪看着信号好像还行”。4.2 方式二用 STM32CubeMonitor-RF 免综测仪快速验证如果只是想做研发阶段的初步验证不想动用实验室里的综测仪或者实验室仪器档期排满了可以用 STM32CubeMonitor-RF 在电脑上直接配合开发板做测试。这个工具本来是 ST 生态里用于无线 MCU RF 性能评估的上位机连接 ST-LINK 虚拟串口后可以直接控制板卡进入类似 DTM 的收发模式。具体流程是打开 STM32CubeMonitor-RF选择对应的串口界面上一般会要求选择当前连接的板卡或目标器件。连接成功后工具会自动识别芯片并读取固件中的 RF 相关信息。然后你就可以在界面上配置发射信道、包类型、包长点击开始工具就能通过板载射频完成发射或接收测试。发射模式下外接频谱仪就能看到持续的载波或调制信号接收模式下需要外接一个信号源以指定频率和功率发射数据工具内部会统计误包率并显示出来。这个工具的界面不同版本可能有差异但核心操作逻辑不变选串口、配参数、启动测试。如果你打开工具后发现连不上板卡先确认是不是串口助手占用了端口如果能在工具里看到信号但数据一直为 0检查一下开发板天线端是否接入了测试设备或者板卡射频初始化是否成功。这里必须说清楚一个边界STM32CubeMonitor-RF 不等于蓝牙认证用的 DTM 测试仪它能做快速验证和趋势观察但正式的蓝牙认证报告还是以综测仪数据为准。所以我的习惯是研发阶段先用它把大方向调对送认证前再用综测仪做完整回归。4.3 方式三手动 HCI 命令 频谱仪理解底层原理如果你想彻底搞明白 DTM 的底层机制或者想为产线写一套自定义的自动化测试脚本可以尝试手动下发 HCI 命令来驱动 DTM。这个方法要求你对蓝牙 HCI 层有一定了解但它不受限于 ST 工具也更容易集成到自己的测试系统里。在蓝牙核心规范里与 BLE DTM 相关的三个核心 HCI 命令分别是 LE Receiver Test、LE Transmitter Test、LE Test End。发送这些命令时需要按 HCI 命令包格式构造数据包含操作码和参数。比如 LE Transmitter Test 命令需要指定测试信道、测试数据长度和数据包型LE Receiver Test 需要指定接收信道。命令下发后DUT 会立即开始发射或接收直到接收到 LE Test End 命令才会停止。DUT 接收测试的统计结果也在 LE Test End 的返回事件中上报。在你的电脑上可以用串口助手以十六进制方式向开发板的 DTM 串口发送命令。命令的完整字节序列以蓝牙核心规范和 ST 的 HCI 接口文档为准不同版本的协议栈可能对命令封装有细微差别。自己拼包时最容易犯错的就是字节序和参数取值范围比如测频点不是信道号直接换算而是通过指定信道号由公式计算BLE 广播信道 2402MHz 对应起始频率信道间隔 2MHz信道 k 的频点等于 2402 2k MHz。信道 0 到 39 对应 2402MHz 到 2480MHz。用这种方式你可以在没有综测仪的情况下做一个简单的闭环验证让 DUT 在某个信道持续发射用频谱仪观察频率是否落在目标频点、功率是否在预期范围再切换成接收模式用信号源发射已知分组看 DUT 统计的误包率和发射功率的关系。方式灵活但需要你自己维护命令序列和测试逻辑。代价是要花时间调通命令通路而且一旦命令格式写错DUT 不会有任何反应排查成本比前两种方式高。我的建议是先把方式二跑通再利用它的上位机日志观察命令交互再用方式三自行构造命令这样学习曲线会平缓很多。5. 问题排查与避坑笔记5.1 环境与烧录阶段的常见问题烧录 DTM 固件时遇到问题是最打击人的因为还没看到希望就卡住了。我整理了几个高频问题第一个是 ST-LINK 无法识别。表现是 STM32CubeProgrammer 里看不到目标芯片或者 IDE 下载时报 ST-LINK 连接失败。排查顺序是换一根 USB 数据线确认不是充电线检查电脑设备管理器里 ST-LINK 枚举是否正常在 IDE 里把 ST-LINK 的固件升级到最新。很多时候 ST-LINK 固件太老会导致新芯片连接不稳定。第二个是编译报错找不到器件定义或者宏定义。这个多半是固件包和 IDE 器件支持包版本不匹配。解决方法是在 STM32CubeMX 中重新安装并更新 STM32WBA 系列的固件支持包保证 IDE 里能看到对应芯片型号。如果某一个头文件路径报错检查工程属性里的 include path 是否完整。第三个是串口无输出。确认串口号是不是板卡的虚拟串口有的电脑 USB 插上后会枚举出两个串口别选错了。再确认波特率。如果两个都没问题按一下板卡上的复位键看启动日志会不会重新打印可能是程序已经在运行但日志没刷新出来。5.2 DTM 测试执行阶段的数据异常排查射频测试本身有时也会出现一些让人挠头的数据。我把典型现象整理成表格方便对照排查。现象可能原因处理办法频谱仪看不到发射信号天线没接好或射频线缆损坏重新检查射频路径换线测试发射功率比预期低很多供电电压不足、线缆损耗未补偿换 USB 线或外接稳压电源校准线缆损耗频率偏移超限晶振校准未完成或环境温度异常检查是否有准确的 32MHz 晶振必要时做频偏补偿误包率PER高接收路径衰减过大、外部干扰、天线阻抗失配检查衰减器设置使用屏蔽环境排查天线匹配DTM 命令无响应串口端口被占用或命令格式错误关闭串口助手使用隔离供电重新对照命令字节测试结果反复跳动测试环境不稳定线缆连接松动固定所有连接件减少人体靠近天线的干扰尽量在屏蔽箱中测试关于 PER 和 BER我再补充一个细节。BLE DTM 的接收测试一般统计的是误包率测试仪连续发送一定数量的数据包DUT 在接收模式下每收到一个错误包就把它计入统计测试结束时通过 LE Test End 命令把统计结果上报。所以如果你看到 PER 很高先不要急着怀疑芯片检查接收路径的衰减和匹配才是第一位的我修过很多“灵敏度差”的板子最后发现是测试线缆本身有问题。最后说一个我自己的习惯任何正式测试前先把已知正常的板卡或者现成参考板跑一遍同样流程确认测试系统本身是好的再测试被测板。这样能把测试系统引入的误差和被测试对象的问题区分开省掉大量排查时间。这个内容后续要扩展的话其实还可以向量产测试方向走比如把 DTM 命令封装成 Python 脚本结合串口和频谱仪做一轮自动化的产测冒烟。只要掌握了 DTM 的底层逻辑在 Nucleo-WBA25CE1 上用代码控制射频发射就只是串口收发和协议解析的问题了。