HAL 源码不是不能看。DMA 模式对不对？数据位置对不对？Size 是否符合预期？回调是否真的反复进入？main 循环是否也在发送？串扰是否存在？这样看源码才有方向。这次 Bug 表面看是串口疯狂回显。中间看起来像串扰、IDLE 中断、DMA Pause/Resume、HAL 状态机的问题。代码假设：新数据在 rx_buffer [ 0 ] DMA Circular：新数据可能在任意位置两边一错

有时候调 STM32，最让人怀疑人生的不是高级外设，而是这些看起来很基础的小问题。这一篇不新增外设，也不追求做一个新的功能。这篇适合刚开始用 VSCode + Makefile + CubeMX 写 STM32 工程的同学。你不需要先把 C 语言的编译链接原理背得很熟，但读完以后，至少要知道以后遇到这类问题先往哪查。

位置在main.c很多 HAL 回调函数也会放这里。回调函数可以放这里。复杂业务不要全塞这里。复杂业务最好封装到 app_xxx.c。

位置在main.c很多 HAL 回调函数也会放这里。回调函数可以放这里。复杂业务不要全塞这里。复杂业务最好封装到 app_xxx.c。

* 定时打印（非阻塞） */你的工程里可能有两个地方定义了fputc。检查是否在多个.c文件里写了。只需要一个地方定义（app_uart.c。

两个。

很多人学 STM32，第一个门槛不是 C 语言，也不是 GPIO，而是开发环境。你用 Keil 写过几篇教程之后，应该已经感觉到：Keil 的编辑器确实不太顺手。代码补全基本没有，跳转定义经常失效，界面风格还停留在十几年前。写几十行代码还行，写几百行就开始难受了。那能不能用 VSCode 来写 STM32？能。而且不只是写代码——VSCode 可以负责编辑、编译、下载、调试一整套流程。环境配置和

C 语言里，struct// 没有结构体时，参数散落各处：uint32_tboot_count;// 有了结构体，打包成一个 "配置本" ：typedefstruct {uint32_tboot_count;打包的好处：你可以把这个结构体整体读、整体写、整体校验，不用一个一个字段处理。

如果你的 SPI Flash 接在 SPI2 上，在包含超时时间的三个宏：宏默认值含义100ms普通 SPI 收发超时500ms等待页写入完成的最大时间5000ms等待扇区擦除完成的最大时间擦除比写入慢得多（因为要擦的面积大），所以擦除超时给了 5 秒。这些就是 SPI Flash 的"暗号"。芯片收到0x06就知道你接下来要写或擦，收到0x20就知道你要擦一个扇区。要保证代码里的 SPI 句柄和

include "app_spi_flash.h" // 如果你用的是 SPI2，把下面这行改成 hspi2 #ifndef APP_SPI_FLASH_HANDLE #define APP_SPI_FLASH_HANDLE hspi1 #endif // 超时时间。