企业官网建设流程全解析

1. 先把需求框死：STM32配蓝牙模块，选型比写代码更影响成败

A同学前段时间做一个小车项目，主控是STM32F103，加一个蓝牙模块做手机遥控。他前后折腾了两天，代码改了三版，最后发现问题出在模块买错了型号——他以为所有蓝色小板子都是"蓝牙串口"，结果手里那块是BLE从机，手机连上之后发过来的数据是GATT特征值写入，而不是他想象中的串口透传流。这个场景在嵌入式入门阶段太常见了。STM32 和蓝牙模块的组合，硬件上只有两根线，软件上却横跨了串口配置、协议理解、状态机设计三层东西，任何一层想当然，都会表现为"连上了但没数据"这种没有报错信息的死局。

这篇内容想解决的就是这件事：从选模块开始，把 STM32 侧串口怎么配、AT 指令怎么打、应用层协议怎么定、出了问题是哪一层引起的，按一条完整的链路走一遍。适合刚接触 STM32 外设、想用蓝牙做短距离无线通信的开发者，也适合已经能点亮灯但被"数据不通"卡住的人。文中给的代码基于 HAL 库，F1、F4、G0 系列都能直接搬，差异点我会单独标出来。

1.1 经典蓝牙SPP和BLE，到底该选哪一类

这一步选错，后面所有代码都白写。市面上那些带引脚的蓝牙小模块，粗分两类。

第一类是经典蓝牙 SPP（串口透传协议），代表型号 HC-05、HC-06。它内部封装了一个虚拟串口，配对成功之后，手机发一个字节，模块的 TX 脚就吐一个字节出来，完全不需要关心 GATT、服务、特征值这些东西。HC-05 可以设主从角色，HC-06 基本只能做从机。做遥控、传调试信息、短指令交互，这类模块是性价比最高的选择。

第二类是低功耗蓝牙 BLE，代表型号 JDY-31、AT-09、HC-08 这类（很多是同一颗 BLE SoC 的不同封装）。BLE 的优势是功耗低、能和手机原生生态配合，但它的"串口透传"其实是模块固件模拟出来的：模块内部建了一个透明传输服务，手机端必须用特定 App 或者自己写 GATT 客户端去连接指定服务和特征值，才能收发数据。用系统自带的蓝牙设置直接配对，通常是连不上的。

我的判断标准很朴素：

还有一点必须提前确认：模块是"从机"还是"主从一体"。HC-06 这类纯从机模块，你没法让它主动去连另一块模块，两个 STM32 想无线对话就做不成。买之前看清单页上的 ROLE 说明，这一步花三十秒，能省两天。

1.2 供电、引脚和天线：三个最容易被忽略的硬件前提

选完型号，很多人直接对着丝印把 VCC、GND、TX、RX 四根线插上去，然后开始怀疑人生。实际上有三个硬件细节值得单独拿出来说。

供电电压和 IO 电平不是一回事。很多 HC-05 底板标称 VCC 支持 3.6V~6V，因为它板上带了 LDO；但它的信号引脚电平是 3.3V 逻辑。如果你用 5V 给模块供电，同时把模块的 TX 直接接到 STM32 的 RX 上，那根线上跑的就是 5V 电平。STM32 大部分引脚虽然是 5V 容忍（FT 标注），但不是全部，PA0~PA7 这类模拟引脚往往不容忍。稳妥做法是：模块统一用 3.3V 供电，或者至少在模块 TX 到 STM32 RX 之间串一个 1kΩ 电阻做限流。反过来 STM32 的 TX 到模块 RX 一般不用管，3.3V 输出对模块来说是合法高电平。

峰值电流比手册上的静态电流重要得多。模块在广播、建链、发射瞬间的电流会突然抬升，几十毫安是常态。如果和 STM32 共用一路 LDO，又没有做去耦，很容易出现"一连接就复位"或者"数据发一半就断"的现象。我的习惯是在模块 VCC 和 GND 之间并一颗 100μF 的钽电容加一颗 0.1μF 的陶瓷电容，位置尽量靠近模块引脚，而不是放在板子另一头。这颗电容的钱不能省。

天线的净空区必须留出来。模块板载的 PCB 天线或者陶瓷天线，下方和正前方不能铺铜、不能走线、不能贴电池、不能有金属外壳紧贴。有些同学把模块塞进一个铁皮盒子做外壳，结果通信距离从十米掉到半米，还以为是模块坏了。装配的时候至少保证天线区域往外 5mm 到 10mm 是空的。

提示：模块底板上印的 TX/RX 是相对模块自身而言的。模块的 TX 要接 STM32 的 RX，模块的 RX 要接 STM32 的 TX。这个交叉关系每个人都"知道"，但真正接线时接反的比例高得离谱。

2. 接线这一步，把方向感和电平问题一次解决

接线看起来是最没有技术含量的环节，但我在帮人排查问题时，十次里有三四次最终定位到这一层。所以这里不写"接好四根线"这种废话，而是把接线过程中真正会出岔子的地方摊开说。

2.1 TX/RX 交叉与串口选择

STM32 的串口不止一个，选哪个有讲究。USART1 挂在 APB2 上，时钟频率通常比挂在 APB1 上的 USART2/3 高，能支持的波特率上限也更高，同时它的引脚复用组合更多。如果只是 9600 或 115200 的蓝牙通信，任何一个串口都够用，这时候优先考虑的是这块板子上哪个串口的引脚没有被别的外设占用。

举个具体的例子：一块常见的 STM32F103 最小系统板，USART1 默认是 PA9（TX）和 PA10（RX）。这两个脚经常被拿去接 LED 或者按键，冲突了就得重映射到 PB6/PB7。重映射不是改个宏就完事，需要在初始化里打开 AFIO 时钟并且调用重映射函数，CubeMX 里勾选了会自动生成，手写代码时容易漏。

接线之后，第一件事不是烧程序，而是用万用表通断档确认四根线的连通性，尤其是用杜邦线的时候。劣质杜邦线内部断芯、母头簧片松垮的情况非常多，表现就是"有时候通有时候不通"，这种间歇性故障会让你怀疑一切软件逻辑。

2.2 电平转换的两种做法与各自的代价

前面提到模块 TX 到 STM32 RX 的电平问题，这里给两个具体方案。

方案一是串电阻，1kΩ 到 2kΩ 都行。原理是限制流入 STM32 引脚钳位二极管的电流。成本几分钱，缺点是它只降低电流，不改变电压幅值，如果模块输出真的是 5V 推挽，那 STM32 引脚上测到的还是接近 5V，只是电流被限制了。对短时间调试够用，长期可靠性一般。

方案二是用双向电平转换芯片，比如常见的 MOS 管方案或者专用转换芯片。成本高一点，占板面积大一点，但电压幅值是真的被转换了。如果项目要做成产品、要过长时间老化，我建议上这个方案。

还有第三种更省事的做法：选一块原生 3.3V 逻辑的模块底板。很多模块的底板上有电平选择焊盘或者跳线，翻过来看看背面，说不定已经给你做好了。

2.3 上电顺序与模块状态灯的读法

模块上电后，板上一般有个 LED，它的闪烁模式是免费的状态指示器，学会读它能省很多时间。

• 快闪（大约每秒闪好几次）：模块在广播或者等待配对，没连上。
• 双闪、慢闪：HC-05 在 AT 模式下的典型表现之一，或者模块进入了可发现状态。
• 常亮：已经建立连接。这时候串口上才可能有透传数据。
• 完全不亮：先查供电和地线，别急着怀疑模块坏。

我个人的经验是，先让模块单独上电看灯，再接 STM32。这样能把"模块本身有没有问题"和"STM32 有没有问题"隔离开。如果模块单独上电灯都不闪，那问题百分之百在供电或者模块本身，跟你的串口代码一毛钱关系都没有。

另外提一句上电顺序：如果 STM32 先上电、模块后上电，模块上电瞬间的浪涌有可能在 TX 线上产生一个毛刺，被 STM32 当成一个字节收进去。如果你的协议没有帧头校验，这个毛刺就会变成一个假的指令。所以协议设计那章我会强调帧结构的重要性，这不是过度设计。

3. STM32侧串口收数的三种写法，以及我为什么最后留下两种

串口发送简单，HAL_UART_Transmit一行搞定。真正麻烦的是接收，因为数据什么时候来、来多长，主机事先都不知道。这里把三种常见写法摆出来，说清楚各自适合什么场合。

3.1 轮询接收：只适合验证阶段

最简单的写法是主循环里不停调HAL_UART_Receive(&huart1, &ch, 1, 10)，超时 10ms，收到就处理。代码三行，逻辑清晰。

uint8_t ch; while (1) { if (HAL_UART_Receive(&huart1, &ch, 1, 10) == HAL_OK) { handle_byte(ch); } // 其他任务 }

问题在于它是阻塞的。哪怕超时设成 1ms，主循环也被切得七零八落，一旦你有定时器任务、有屏幕刷新、有电机控制，时序立刻就乱。所以我只在两种情况下用它：一是刚焊好板子，验证串口通不通；二是做一个极简的调试输出口，只收单字符命令。

真要长期用，至少得把它挪到定时器中断里，但那样又引入了新的复杂度——中断里调 HAL 的阻塞函数是禁忌。

3.2 中断逐字节接收：可控但要注意节奏

用HAL_UART_Receive_IT(&huart1, &rx_byte, 1)开一个字节的中断接收，每收到一个字节进一次回调，在回调里把字节塞进缓冲区并重新开启接收。

uint8_t rx_byte; uint8_t frame_buf[64]; uint16_t frame_len = 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { if (frame_len < sizeof(frame_buf)) { frame_buf[frame_len++] = rx_byte; } HAL_UART_Receive_IT(&huart1, &rx_byte, 1); } }

这个写法的好处是每个字节的到达时刻都是确定的，你可以在回调里直接判断帧头，甚至做简单的状态机解析。缺点是中断频率高：115200 波特率下，一个字节大约 87μs，也就是说每秒可能进上千次中断。如果主频不高、中断里还干了别的事，就容易丢字节。

一个必须注意的细节是：在回调里重新调用HAL_UART_Receive_IT之前，不能有太长的耗时操作。如果你在回调里直接跑协议解析、甚至点亮屏幕，那么在解析期间到达的字节就丢了。正确做法是回调里只做"搬运"，把字节丢进环形缓冲区就立刻返回，解析放到主循环里做。

3.3 IDLE中断配合DMA：不定长数据的正解

蓝牙透传的数据天然是"一包一包"来的，中间有天然的空闲间隔。STM32 的串口有一个 IDLE 空闲中断，正好对应这个特性：总线上一段时间没有新数据，就触发一次中断，告诉你这一包结束了。

配合 DMA，可以做到 CPU 完全不参与搬运。初始化时开一次 DMA 接收，长度设成缓冲区大小，然后在 IDLE 中断里算出实际收到了多少字节。

新版本 HAL 库（F4、G0、G4、H7 等较新的固件包）提供了HAL_UARTEx_ReceiveToIdle_DMA，一行就能开启：

#define RX_BUF_SIZE 256 uint8_t rx_dma_buf[RX_BUF_SIZE]; void uart_start_rx(void) { HAL_UARTEx_ReceiveToIdle_DMA(&huart1, rx_dma_buf, RX_BUF_SIZE); __HAL_DMA_DISABLE_IT(huart1.hdmarx, DMA_IT_HT); // 关掉半传输中断，避免频繁打断 } void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart->Instance == USART1) { ringbuf_push(rx_dma_buf, Size); // 只搬运，不解析 HAL_UARTEx_ReceiveToIdle_DMA(huart, rx_dma_buf, RX_BUF_SIZE); __HAL_DMA_DISABLE_IT(huart->hdmarx, DMA_IT_HT); } }

如果是老版本 HAL（比如 F1 系列的固件包），没有这个接口，就手动开 IDLE 中断：

// 初始化时 __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE); HAL_UART_Receive_DMA(&huart1, rx_dma_buf, RX_BUF_SIZE); // 在 stm32f1xx_it.c 的 USART1_IRQHandler 里调用 void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE) != RESET) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); HAL_UART_DMAStop(&huart1); uint16_t len = RX_BUF_SIZE - __HAL_DMA_GET_COUNTER(huart1.hdmarx); if (len > 0) { ringbuf_push(rx_dma_buf, len); } HAL_UART_Receive_DMA(&huart1, rx_dma_buf, RX_BUF_SIZE); } HAL_UART_IRQHandler(&huart1); }

这段代码有两个隐形坑。第一，__HAL_UART_CLEAR_IDLEFLAG本质上要求先读 SR 再读 DR，不同系列的 HAL 宏实现不完全一样，如果你的芯片上这个宏不生效，中断会反复触发，表现为程序卡死。第二，在 IDLE 中断里HAL_UART_DMAStop之后必须重新启动 DMA，忘了这一步就只收得到第一包。我见过不少人卡在这里，现象是"第一帧正常，后面全无响应"。

3.4 环形缓冲区：把接收和解析彻底解耦

不管用中断还是 DMA，最后都应该落到一个环形缓冲区上。中断/DMA 负责"生产"，主循环负责"消费"，两边通过读写指针解耦。

#define RB_SIZE 512 // 必须是 2 的幂 static uint8_t rb[RB_SIZE]; static volatile uint16_t rb_head = 0; // 写入位置（中断里改） static volatile uint16_t rb_tail = 0; // 读出位置（主循环里改） void ringbuf_push(const uint8_t *data, uint16_t len) { for (uint16_t i = 0; i < len; i++) { uint16_t next = (rb_head + 1) & (RB_SIZE - 1); if (next == rb_tail) { rb_tail = (rb_tail + 1) & (RB_SIZE - 1); // 满了就丢最旧的 } rb[rb_head] = data[i]; rb_head = next; } } uint16_t ringbuf_pop(uint8_t *out, uint16_t max_len) { uint16_t n = 0; while (rb_tail != rb_head && n < max_len) { out[n++] = rb[rb_tail]; rb_tail = (rb_tail + 1) & (RB_SIZE - 1); } return n; }

用 2 的幂做长度，取模运算就变成位与，速度快很多。volatile不能省，否则编译器优化之后主循环可能永远看不到rb_head的变化。

注意：如果缓冲区满了选择丢弃最旧数据，那么协议层必须能容忍丢包。如果你的业务不能丢包，那缓冲区别设太小，或者加流控（让对端等 ACK 再发下一包）。

4. AT指令阶段：先让模块听话，再谈通信

模块能正常上电、串口通了，下一步是配置。这一步的目标是把模块的波特率、名称、角色、配对密码设成你想要的值，并且把配置持久化，断电重启后依然有效。

4.1 进AT模式的两种做法，以及为什么大多数失败都在这一步

这是新手翻车率最高的地方。不同模块进入 AT 命令模式的条件完全不一样，弄错了，你发什么它都不回。

经典蓝牙模块（以 HC-05 为例）：需要在上电的瞬间或者上电之前，把 EN（有的板子标 KEY）引脚拉高。具体做法是按住模块上的小按键再上电，或者用 STM32 的一个 GPIO 在模块上电前输出高电平。进入 AT 模式后，通信波特率固定为 9600，与你之前设的透传波特率无关。这一点极其关键——很多人把透传波特率改成了 115200，然后试着用 115200 进 AT 模式，当然没反应。

BLE 模块（JDY-31、AT-09 之类）：大多不需要额外的使能引脚，直接上电后用 9600 波特率发 AT 就能回。但也有例外，某些模块要求上电后 3 秒内发 AT，超时退出配置状态。

还有HC-06：它是纯从机，AT 指令集比 HC-05 少，没有设置角色的命令。进入 AT 模式的方式也因板子而异，有的是上电时按住按键。

不管哪种模块，AT 命令的结尾必须是回车换行\r\n，只发AT两个字母不发换行，模块永远不会理你。用串口助手的时候这一点尤其容易忽略，很多助手的"发送新行"选项默认是关的。

4.2 常用指令与关键参数的取舍

以经典的 SPP 模块为例，常用命令大致如下（不同固件版本会有差异，以模块手册为准）：

几个参数值得单独说。

波特率改完必须重新上电。AT+UART改的是透传模式下的波特率，AT 模式本身始终是 9600。而且改完之后如果立刻发下一条指令，很可能收不到回复，因为模块已经切成新波特率了。正确做法是：改完波特率，断电，重新上电（这次不拉 EN 引脚），再用新波特率去通信。

密码位数有约束。有些固件只接受 4 位，有些接受 4 到 16 位。设错了返回 ERROR，但很多人不看返回值，直接往下走，最后手机连不上的时候才发现密码根本没设进去。每发一条 AT 指令，都要确认返回了 OK，这是一条铁律。

恢复出厂是个好习惯。拿到模块第一件事，先发一条恢复出厂指令，把它从可能被前任用户改乱的状态里捞回来。你永远不知道买到的模块之前被怎么折腾过。

4.3 BLE模块的AT体系，别拿经典蓝牙的经验去套

BLE 模块的 AT 指令和经典蓝牙不通用的。举几个典型差异：BLE 模块设置名称往往用AT+NAME（不带等号，后跟参数），查询用AT+NAME?，返回里还会带+OK前缀；波特率命令可能是AT+BAUD；有些模块还有一个AT+RESET用于软复位。

更关键的是，BLE 模块的"连接"概念不一样。经典蓝牙是配对+连接，蓝牙串口 App 里点一下设备就能收发。BLE 则要求手机端 App 去发现服务（Service）和特征值（Characteristic），往特定的特征值里写数据才能到模块的串口。如果你的手机端用的是原生蓝牙设置，那基本连不上；必须用专门的 BLE 调试 App。

我一般会在项目文档里写清楚：模块型号、固件版本、通信波特率、AT模式波特率、手机端用的App名字。这五行信息看着不起眼，等半年后回来改代码，能救命。

// AT指令发送的一个小封装，注意结尾的 \r\n void bt_send_at(const char *cmd) { char buf[64]; int n = snprintf(buf, sizeof(buf), "%s\r\n", cmd); HAL_UART_Transmit(&huart1, (uint8_t *)buf, n, 100); HAL_Delay(200); // 给模块留出处理时间，太急会丢响应 }

HAL_Delay(200)这个延时很多人觉得粗暴，但 AT 配置阶段是上电初始化的一部分，快这 200ms 没有任何意义，稳妥优先。等进了透传模式，再谈效率。

5. 应用层协议：透传不等于可以裸奔

"蓝牙模块是透传的，发什么收什么"——这句话只对了一半。透传确实意味着模块不改你的数据，但这恰恰带来了一个问题：底层没有任何帧边界和校验，你的应用必须自己造一套。

5.1 为什么必须有帧结构

考虑一个真实场景：手机通过蓝牙发一条"前进"指令给小车。如果没有帧结构，你收到的就是一个孤零零的字节0x01。现在假设因为干扰或者上电毛刺，STM32 在不该收到数据的时候收到了一个0x01，小车就自己往前冲了。这在遥控车上可能只是撞墙，在别的场景里就不好说了。

再考虑另一个场景：一包数据应该是 5 个字节，但 DMA 恰好在中途切了一刀，你收到了 3 个字节。没有帧头帧尾的话，你根本不知道自己收全了没有。

所以协议层要解决三件事：边界识别、完整性校验、指令区分。

5.2 一套够用的帧格式

我常用的格式是这样的：

用两个字节做帧头而不是一个字节，是因为单个 0xAA 在数据域里出现的概率太高，会导致误同步。两个字节连续出现的概率就低得多。

校验用累加和就够了，不必上 CRC16。蓝牙链路本身有很强的纠错和重传机制，应用层校验主要是防"半包"和"程序自身的拼接错误"，累加和完全胜任，而且计算快，中断里也能跑。

#define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_MAX 64 typedef enum { SEEK_HEAD1 = 0, SEEK_HEAD2, WAIT_LEN, WAIT_CMD, WAIT_DATA, WAIT_SUM, } parse_state_t; static parse_state_t st = SEEK_HEAD1; static uint8_t frame_len, frame_cmd; static uint8_t data_buf[FRAME_MAX]; static uint8_t data_idx; static uint8_t calc_sum; // 每来一个字节调用一次，返回 1 表示收到完整帧 int frame_parse_byte(uint8_t b, uint8_t *cmd_out, uint8_t *data_out, uint8_t *len_out) { switch (st) { case SEEK_HEAD1: if (b == FRAME_HEAD1) st = SEEK_HEAD2; break; case SEEK_HEAD2: st = (b == FRAME_HEAD2) ? WAIT_LEN : (b == FRAME_HEAD1 ? SEEK_HEAD2 : SEEK_HEAD1); break; case WAIT_LEN: frame_len = b; calc_sum = b; if (frame_len > FRAME_MAX) { st = SEEK_HEAD1; break; } st = WAIT_CMD; break; case WAIT_CMD: frame_cmd = b; calc_sum += b; data_idx = 0; st = (frame_len > 0) ? WAIT_DATA : WAIT_SUM; break; case WAIT_DATA: data_buf[data_idx++] = b; calc_sum += b; if (data_idx >= frame_len) st = WAIT_SUM; break; case WAIT_SUM: st = SEEK_HEAD1; if (b == calc_sum) { *cmd_out = frame_cmd; *len_out = frame_len; memcpy(data_out, data_buf, frame_len); return 1; } break; default: st = SEEK_HEAD1; break; } return 0; }

这段状态机有个细节值得注意：在SEEK_HEAD2状态下收到0xAA时，我保留了SEEK_HEAD2状态而不是退回SEEK_HEAD1。因为0xAA 0xAA 0x55这种序列里，第二个 0xAA 应该被当作新的帧头起点。如果退回起点，就会漏掉这一帧。这类"帧头重叠"的边界情况，用真实数据跑一百遍也不一定能碰上，但一旦碰上就是偶发丢包，极难排查。

5.3 主循环里的消费逻辑

接收侧缓存在环形缓冲区里，主循环里一次取一些字节出来喂给解析器：

uint8_t tmp[64]; uint16_t n = ringbuf_pop(tmp, sizeof(tmp)); uint8_t cmd, data[FRAME_MAX], len; for (uint16_t i = 0; i < n; i++) { if (frame_parse_byte(tmp[i], &cmd, data, &len)) { dispatch_command(cmd, data, len); } }

注意dispatch_command里不要做耗时操作。如果某个命令需要驱动电机转两秒，应该在命令处理函数里设置一个状态和目标值，然后立刻返回，让主循环的其他部分去执行。把阻塞动作放在协议处理里，很快就会遇到"发下一条指令没反应"的问题。

6. 从"灯不亮"到"数据能通"，一条完整的排查链路

前面讲的都是正常流程，这一章还原真正卡住人的时刻。我把它整理成一个分层排查的路径，遇到问题从上往下走，不跳步。

6.1 分层定位法

我见过最典型的一个案例：一位开发者发来的截图里，串口助手收到的是成片的FF或者乱码。他一度以为是模块固件坏了。实际原因是STM32 的系统时钟没有按外部晶振配置，还在用内部 HSI 跑，导致 USART 的实际波特率和设定值差了百分之几，累积到十个位就偏了半个位宽，收到的自然全是垃圾。这个问题的特征是"偶尔能收到正确的字节"，非常有欺骗性。

波特率误差可以算一下：如果 USART 挂在 72MHz 的 APB2 上，目标 115200，分频系数是 72000000/(16×115200)=39.0625，HAL 库会自动取最接近的整数分频加小数部分，误差通常在千分之几以内，通信没问题。但如果系统时钟实际是 8MHz 的内部 RC 振荡器（还没校准），那就是几倍的偏差，必然乱码。所以第一步永远是确认 SystemClock_Config 有没有被正确调用、外部晶振有没有起振。

6.2 几个我实际踩过的坑

坑一：模块的回环测试做不了。想验证串口通路，常见做法是把模块拔掉，把 STM32 的 TX 和 RX 短接，自己发自己收。但模块插在板子上时，模块的 TX 引脚可能一直在输出（比如在广播时输出调试信息），你短接上去就是两个输出对打，读到的数据是乱的。测试前一定要把模块从插座上拔下来。

坑二：AT 指令回显造成的误判。有些固件默认开启回显，你发AT，它先原样回一个AT，再回OK。如果你的代码只看"有没有收到字符"来判断成功，就会把回显当成响应。判断成功的正确姿势是匹配OK这两个字符。

坑三：DMA 缓冲区被覆盖。用 DMA 接收时，如果主循环处理太慢，还没读走上一包数据，DMA 已经把新数据写进同一个缓冲区了。表现为"数据时好时坏，好像被截断"。解决办法是把 DMA 缓冲区设大一些，或者用双缓冲（HAL 的HAL_UARTEx_ReceiveToIdle_DMA配合半传输中断可以做到乒乓），或者干脆在回调里立刻拷走。

坑四：手机端 App 的隐藏设置。某些蓝牙串口 App 默认发送的是十六进制还是文本、有没有加换行、编码是 UTF-8 还是 GBK，这些设置会直接影响你收到的字节。调试时先用最简单的单字符测试，比如发一个0x01，在 STM32 端把收到的原始字节打印出来，确认无误后再上协议。

6.3 逻辑分析仪该看什么

如果软件层面查不出问题，就得上仪器。一个几十块的分析仪接到 TX、RX 两根线上，采样率设到 1MHz 以上，能直接看到波形。

重点看三件事：波特率对不对（量一个位宽，1/位宽就是实际波特率）、数据位是不是 8 位、有没有帧错误。如果看到起始位之后电平一直不对，那基本可以确定是波特率或者时钟问题。如果波形很干净但数据不对，那就是软件配置（比如校验位、停止位）和模块不匹配。

我自己遇到过一次"偶发丢字节"，分析仪抓了半天都没问题，最后发现是杜邦线太长加上没有共地，地线上有几百毫伏的压差。所以接线长度尽量控制在 20cm 以内，且务必保证 STM32 和模块共地，这两条比什么调试技巧都管用。

7. 让它从"能跑"变成"跑得住"

教会模块收发数据只是起点。真正用在项目里，还有几个问题必须提前处理。

7.1 连接状态机：别假设链路永远在线

蓝牙链路是会断的。手机走远了、手机锁屏了、模块供电抖了一下，都会断。如果你的代码只在初始化时配置一次模块，然后假设它一直连着，那断开之后整个系统就哑了。

我一般会加一个简单的状态机，用模块的状态指示灯引脚（很多模块有 STATE 或者 LINK 引脚，连接成功输出高电平）作为输入之一，配合超时判断：

typedef enum { BT_IDLE, // 未连接 BT_CONNECTED, // 已连接 BT_TIMEOUT, // 连接超时，准备重连 } bt_state_t; static bt_state_t bt_st = BT_IDLE; static uint32_t last_rx_tick = 0; void bt_state_poll(void) { uint8_t link = HAL_GPIO_ReadPin(BT_STATE_GPIO_Port, BT_STATE_Pin); switch (bt_st) { case BT_IDLE: if (link) { bt_st = BT_CONNECTED; last_rx_tick = HAL_GetTick(); } break; case BT_CONNECTED: if (!link) { bt_st = BT_IDLE; } else if (HAL_GetTick() - last_rx_tick > 5000) { // 5 秒没收到任何数据，链路可能已经死了但状态脚没变 bt_st = BT_TIMEOUT; } break; case BT_TIMEOUT: bt_soft_reconnect(); // 发 AT 或复位模块 bt_st = BT_IDLE; break; } }

那个 5 秒超时是我实际踩坑之后加的。有些情况下链路已经废了，但状态脚还保持高电平，光看状态脚会一直以为连着。加一个"心跳超时"能兜住这类情况。心跳可以由手机端定时发一个固定帧，也可以由 STM32 主动发查询。

7.2 功耗：BLE省电不是自动的

如果用 BLE 模块做电池供电的设备，有几个地方决定成败。

广播间隔。模块在未连接时会周期性广播，间隔越短越容易被搜到，也越费电。做产品时通常设到 100ms 到 500ms 之间，调试阶段设短一点方便发现。

从机的连接参数。BLE 连接建立后，主从双方会协商一个连接间隔。间隔越长越省电，但延迟越大。遥控场景下 20ms 到 50ms 比较合适，只上报数据的传感器可以设到几百毫秒。

STM32 自己的功耗。模块休眠了，主机还在满速跑，整体电流照样下不来。空闲时把主频降下来、关掉不用的外设、进 STOP 模式，这些收益往往比调蓝牙参数更大。只是要注意：进低功耗模式之后串口时钟可能停了，唤醒之后要重新初始化接收。

7.3 抗干扰与结构上的几个细节

写了这么多代码，最后往往败在物理层面。几条经验。

电源和天线离远点。DC-DC 开关电源的噪声对 2.4GHz 频段影响很大，模块天线尽量不要贴着电感放。用 LDO 给模块单独供一路是更稳的做法。

外壳材质要注意。金属外壳会把信号挡得死死的，如果必须用，天线位置开个塑料窗口。手握住模块天线附近时信号也会明显衰减，这是正常的，设计时留出余量就行。

数据速率别顶格用。模块标称支持某个波特率，不代表在电磁环境复杂的地方能稳定跑。我通常会把实际业务速率控制在标称值的一半以内，留出重传和重发的余量。比如每 50ms 发一包 20 字节，算下来才 4kbps，接 115200 的波特率绰绰有余。

最后说一个我认为最值得养成的习惯：把蓝牙模块当成一个独立的、可能出故障的外部设备来对待，而不是当成 STM32 的一个外设。它有自己的供电、自己的固件、自己的状态机、自己的通信协议。你的代码要对它做健康检查、要在断线时重连、要对它的数据做校验。想清楚这一点，很多"玄学问题"就不再玄学了。