企业官网建设流程全解析

1. 下载调试那些事：从“连不上”到“乱跑飞”

玩STM32的人，十个里有八个是在Debug下载阶段被劝退的。剩下的那两个，基本都经历过“明明编译通过，一烧就废”的至暗时刻。

我刚接触STM32那会儿，用的还是Keil MDK 4的时代，芯片是STM32F103C8T6。有次给板子烧程序，突然弹出Error: Flash Download failed - "Cortex-M3"，一脸懵。后来排查到最后，原因竟然是Keil里芯片型号选成了F1系列的其它型号，导致Flash算法不匹配。这种事情现在看起来低级，但当时确实卡了一下午。

这篇文章不打算给你讲一堆流水账，就按我自己踩过、也帮别人踩过的坑来梳理，每个问题都会把“为什么会这样”说清楚，再给解决办法，尽量让你不重蹈覆辙。

1.1 Keil5兼容C51和STM32，到底怎么共存

很多新手是玩过51单片机再转STM32的，电脑上装了Keil C51，装Keil MDK的时候发现两个能共存，但SDK包却经常不对。原因很简单：这两个其实是不同的工具链产品，C51用的是A51编译器，MDK用的是ARMCC/ARMClang，安装目录也不同。但很多人在装MDK时没有注意“安装到与原C51不同的目录”，结果就出现互相覆盖的诡异问题。

我的建议是：Keil5安装路径尽量分开，比如C51装到C:\Keil_v5，MDK装到D:\Keil_MDK，装完MDK后，Pack Installer里勾选对应芯片的Pack，51单片机的项目用51的打开方式，STM32项目用MDK打开。注意打开工程文件时，确认选择的IDE是MDK而不是C51，否则会提示“Invalid target”。

另外，MDK5的Pack（芯片支持包）下载经常慢到怀疑人生。解决办法是在Pack Installer里设置代理，或者直接去Keil官网下载对应芯片Pack离线包，自己手动安装。用国内镜像或百度网盘分享的Pack包也能省事不少，但记得核对版本。

1.2 ST-LINK连接失败，SWD调试接口居然被禁用

“ST-LINK连接失败”这个报错，很多人以为是线接错了，或者ST-LINK坏了。其实还有一种非常隐蔽的情况：你在代码里把SWD引脚关了。

怎么关掉的？很多工程模板默认会开启GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE)，目的是释放PA13/PA14/PA15和PB3/PB4这五个引脚当普通IO用。但我见过有人为了多要几个IO口，把这行代码加了进去，结果烧录完第二次就再也连不上ST-LINK了。

更坑的是，有的板子BOOT0本来就是低电平，复位后还是跑用户代码，SWD口被禁用后，调试器完全识别不到芯片。

解决办法有几种：

• 如果芯片内部Flash里程序还能被擦除，用“ST-LINK Utility”连接后，选择Target -> Erase Chip全片擦除。但此时如果SWD已经被禁用，Utility一样连不上。
• 按住复位键，点击连接按钮，在连接瞬间松开复位键。利用这个时序，可以把已经关掉SWD的芯片拉回调试状态。
• 如果还不行，把BOOT0拉高，重新上电，让芯片从系统存储区启动（里面是出厂固化的Bootloader），这时SWD口会重新释放，再用ST-LINK Utility擦除即可。

这个坑的根源其实是**“引脚复用和调试功能的冲突”**。串口、USB、SPI这些外设都可以重映射引脚，但SWD不是你想关就关的，一旦关了，程序里又没有预留恢复逻辑，就会把自己锁死。我的经验是：只要不是特别缺IO口，SWD引脚都别去动。真要动，就要保证板子上有一个可恢复的方案，比如串口IAP、BOOT跳线或者外置的脱机烧录器。

1.3 FLASH下载出错：Program Algorithm和芯片ID不匹配

这个报错我当年也撞过。报错信息中有No Algorithm found for: 08000000H或Error: Flash Download failed，翻译一下就是：Keil不知道拿什么算法去烧你的Flash。

常见原因：

• Debug下拉框里没选对芯片型号。
• 芯片Pack没装全，Flash算法里没有对应型号。
• 芯片本身是“国产兼容型号”，虽然内核是Cortex-M0/M3，但Flash扇区大小、起始地址和ST原厂不一致。

尤其是第三点，用国产替代片（比如GD32、HK32、MM32）的时候，ST-LINK的算法是按ST芯片的Flash扇区划分去擦写的，一旦遇到非ST的Flash，就会出现写入校验失败。此时需要在Flash Download页面添加对应厂家的算法，或者借助原厂提供的烧录工具来解决。

另外，经常有人问“怎么知道芯片固件已经被烧过”，用ST-LINK Utility能读到Flash内容，全0x00说明是空的，全0xFF说明是擦除状态。不过对于刚接触的来说，更重要的是记住一点：先连上，再擦除，最后再编程。别一上来就点“Download”，把“Reset and Run”勾上，下载完自动复位跑。

2. 工程模板和库的选择：一个烂模板毁掉整个周末

下载问题解决后，接下来陪着你时间最长的就是工程了。STM32类热词里有一种很典型：“新建工程模板”“标准库和HAL库的区别”“报错Load axf Failed”。这些都指向同一个核心：工程结构混乱 + 库版本不匹配。

2.1 标准库和HAL库，到底选哪个

这个问题放到现在，标准库基本可以被看作是“祖宗级别”的存在了。但还有很多人执着于标准库，原因是网上教程多、历史代码多、寄存器透明适合学习。标准库现在官方已经停止支持，如果你用的是F1/F4系列老芯片，还能玩得转；但新出的G0、L4、H7系列，标准库根本没有对应版本。

HAL库对新手要友好一些，它的API抽象度高，拿HAL_UART_Transmit来说，一个函数就把串口发送的所有寄存器操作包了。缺点是这些函数比较啰嗦，经常有回调、句柄、中断回调函数，初看非常抽象。

我的选型建议很直接：

• 学习原理、研究寄存器：用标准库或直接操作寄存器；
• 毕业设计、产品开发、快速上手：用HAL库；
• 做OS级、协议栈级需求：用HAL库加DSP库加CMSIS-RTOS，配套文件多但省事。

但不管用哪个，新建工程模板一定要保证“可用、可跑、可调”。一个完整的STM32工程模板至少有：

• 启动文件startup_M35xxx.s（对应具体芯片型号）；
• 系统初始化system_stm32xxx.c；
• 时钟配置文件stm32xxx_hal_conf.h或者标准库的stm32f10x_conf.h；
• 分散加载文件.sct（MDK会自动管理，新手别乱改）；
• 主循环里至少点亮一颗LED，确保整条链路是通着的。

2.2 “Load axf Failed”到底是谁的错

报错内容一般是：

load "D:\\stm32 project\\Objects\\project.axf" Error: Flash Download failed - "Cortex-M3"

有些人是编译都没过，项目生成不了.axf文件，但Load动作还是会执行，于是报这个。有些人是链接时没有生成调试信息，或者输出路径改了，导致Keil找不到.axf。

处理办法：

1. 先看编译输出窗口有没有0 Error(s)，没有的话说明是下载问题；有的话先解决编译。
2. 在Options for Target -> Output里勾选Create HEX File，确认Select Folder for Objects路径是存在的。
3. 在Utilities -> Settings -> Flash Download里确认勾选了Reset and Run，并且选择的是“Use Debug Driver”而不是“Use External Tool”。

说实话，这种问题九成是工程配置问题，不是芯片坏了。遇到类似报错，先别急着换板子，按“路径 -> 编译输出 -> 下载算法 -> 复位方式”的顺序排查，比我当时乱按一通要高效得多。

3. 时钟系统：一切外设的心跳之源

STM32的坑里，时钟绝对是“排第一的隐藏BOSS”。很多人延时不对、串口乱码、定时器频率不对，查到最后都是时钟配置出了问题。

3.1 时钟树：从HSE到AHB/APB的层层分频

初学的时候，看STM32时钟树图，满眼都是PLL、AHB、APB1、APB2，根本分不清谁是谁。这里我用自己的话给你理顺一下：

• HSE（外部高速时钟）：芯片外部接8MHz晶振（或25MHz）进来的信号，最稳定，通常作为主时钟源；
• HSI（内部高速时钟）：芯片内部自带的8MHz RC振荡器，上电默认用它跑，精度一般；
• PLL（锁相环）：把HSE或HSI倍频，得到SYSCLK（系统时钟），比如8MHz外部晶振通过PLL×9，得到72MHz主频；
• AHB总线时钟：SYSCLK经过AHB预分频后给GPIO、Flash、DMA这些；
• APB1总线时钟：AHB再分频得到，低速外设挂在上面，最大36MHz（F1）；
• APB2总线时钟：AHB再分频，高速外设挂在上面，最大72MHz（F1）。

时钟树配错最常见的后果：主频不是72MHz而是8MHz或者36MHz，甚至系统卡死。因为外部晶振没起振时，PLL不会锁定，系统会退回HSI；但代码里如果强制等待PLL就绪，就会出现死等，看现象就是程序跑飞、仿真卡在SystemInit里。

3.2 Delay函数卡死，多半不是Delay的锅

热词里有一项叫“stm32延时函数delay卡死”，这个问题我太熟了。很多人用HAL库的HAL_Delay，发现程序卡死，第一反应是晶振坏了。但真正原因往往是SysTick中断被其他中断抢占或屏蔽了。

HAL_Delay的实现原理是：设置SysTick计数值，然后不断查询计数标志。如果这时候你恰好关了这个中断，或者SysTick的优先级设置比某些外设中断还低，在外设中断里又调用了HAL_Delay，就会死循环——因为SysTick的更新一直被外部中断打断。

另外一个卡死原因是：HAL_Delay不能用在中断回调里（尤其是需要长时间等待的）。比如串口空闲中断里调用HAL_Delay(10)，如果SysTick中断优先级比串口低，等待串口新数据进来时，音乐会一直卡住。解决方法是把SysTick中断优先级设为最低，或者用HAL_GetTick() + while轮询代替HAL_Delay，或者在中断里换个基于NOP或DWT的忙等延时。

顺便提一下DWT延时，这是很多人忽略的好工具：用CoreDebug->DEMCR使能DWT，然后读DWT->CYCCNT，这样能实现微秒级精确延时，非常适合超声波测距这种需要看回波宽度的场景。热词里“stm32超声波测距”就在这里踩坑——HC-SR04要求至少10us的TRIG高电平，很多人的10us延时不准，就是因为系统时钟没有及时更新到DWT。

3.3 主频和定时器、串口波特率的三角关系

这个问题特别体现“为什么时钟树重要”。你做串口通信，波特率要9600或者115200，STM32内部是用USART的时钟源除以波特率寄存器BRR的值得到实际波特率。如果主频变了，BRR不变，波特率就偏了。9600波特率偏100Hz可能还能收，115200偏差超过2%就乱码。

具体到F1系列，APB1的最大频率是36MHz，所以USART2/3、TIM2~7都挂在APB1上；APB2最大72MHz，USART1、TIM1/TIM8这些挂在这里。如果配置USART1时用的是RCC_APB2PeriphClockCmd，但按APB1的36MHz去算波特率，出来的结果是错的。这就是为什么一直强调“先看时钟树，再算波特率”。

我自己调试时，习惯在串口助手上先发0x55或0xAA，看回显是不是0x55或0xAA。如果收到的是0x5D之类的，基本就是波特率对不上或时钟频率不对。再用逻辑分析仪测TX引脚的电平频率，立刻能看出实际波特率跟预设差多少。

4. 定时器：不只是定时，还是测频率、解码、PWM的万能砖

STM32的定时器是外设里最能体现“模式”概念的。热词“stm32定时器模式”“stm32定时器捕获测频率”“stm32编码器程序”都指向同一个叫TIM的神奇外设。它的功能不只是“延时”，它可以：

• 定时中断；
• 输出PWM；
• 输入捕获（测脉宽、测频率）；
• 编码器接口模式（接正交编码器）；
• 霍尔传感器接口模式；
• 触发ADC采样。

4.1 输入捕获测频率：为什么低频率测不准

很多人用定时器输入捕获测方波频率，程序写完了，测1kHz没问题，测10Hz就数字乱跳。原因是：一个方波周期内，两次相邻上升沿之间的计数值可能太小，采样间隔太短，计数器分辨率根本不够。

比如你用72MHz的时钟源、不分频，计数频率就是72MHz，测1kHz信号时每个周期计72000个值，很准；测100kHz信号时只有720个数，还能看；测1MHz信号时只有72个计数值，误差自然就大了。解决办法就是根据被测频率动态调整预分频，或者使用多个通道交替捕获、取平均。

测频率更推荐的方案其实是：一个通道测一段固定时间内的上升沿个数，用另一个定时器做时间基准。这相当于把定时器当作“闸门计数器”，比单次捕获要稳。热词“stm32定时器捕获测频率”被搜得那么多，说明这条路坑多，但也是刚需。

4.2 编码器接口模式：两相正交解码的“隐藏绝活”

编码器模块大家基本都听过：AB相、Z相、计数方向、倍频系数。STM32的定时器编码器模式最大的优势是不用额外IO中断，靠硬件自动加减计数。初始化时配置为TIM_ENCODERMODE_TI1或TIM_ENCODERMODE_TI1andTI2，配合TIM_ICPolarity_Rising，就能根据两路脉冲相位关系判断方向，自动增减CNT寄存器值。

常见坑有两个：

第一个是GPIO复用没配对。TIM2的编码器通道通常接PA0/PA1，TIM3接PA6/PA7，如果你随意指定了两个IO，程序跑起来却计不了数，多半是引脚没选对。这个时候最好看一下芯片数据表的AFIO复用功能列，把引脚对到对应的定时器通道上。

第二个是读取计数器前没有锁存，导致在电机高速转动时，计数器值跳变。多字节读取有原子性问题，建议在读取前关定时器中断、或者用TIM_GetCounter连续读两次，差值大就重新读。另外，编码器Z相（零位信号）经常被忽略，但它对回原点非常关键，能省掉一整套机械限位开关。

4.3 PWM输出的一些小细节

PWM输出看似简单，但有几个容易被忽略的细节：

• 频率计算：PWM频率 = 定时器时钟 / ((PSC+1) * (ARR+1))。如果ARR设为0，整个周期就是0，极容易导致芯片的引脚输出高频抖动。
• 初始极性：如果一开始PWM极性是高，在还没做额定的占空比赋值之前，电机或者LED会直接全开。初始化时务必先设占空比0，再启动PWM。
• 互补输出和死区：驱动H桥时，如果用到TIM1的高级定时器，需要配置死区时间。死区时间太小，上下桥臂会直通短路；死区时间太大，音圈电机或开关电源会啸叫。通常设置为1~2us，先小后大，用示波器观察插入死区后的切换波形。

5. 串口通信：调试的第一入口，也是流氓问题的重灾区

串口是STM32开发者最频繁使用的通信接口，但它的坑也不少。热词里“stm32串口通信”“stm32串口调试pid”“stm32 usb虚拟串口发送数据”全都指向这里。

5.1 printf重定向的两种方式与隐藏问题

标准做法是用MicroLIB提供的fputc重定向：

int fputc(int ch, FILE *f) { while ((USART1->SR & USART_FLAG_TXE) == 0); USART1->DR = (uint8_t)ch; return ch; }

然后把编译选项里“Use MicroLIB”打上勾。如果你用HAL库，也可以这样写：

int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

这个有个坑：HAL_UART_Transmit在每发一个字符时都要检查状态标志，如果串口断线、对端不读，缓冲区满了会卡死。调试时看着没问题，一旦跑生产测试接错线，程序就死在printf里了。所以重要的代码里，尽量少在中断上下文调用printf，必须用的话加超时保护或者用DMA。

5.2 串口中断和接收不定长数据：标志位的两种流派

处理串口不定长接收，老工程师常用两种方式：

• 空闲中断（IDLE）：一帧数据结束后，硬件会触发IDLE中断，此时就知道一包数据收完了。但IDLE中断与字节中断共享同一个中断向量，要区分UART_IT_IDLE和UART_IT_RXNE，否则会反复进中断却什么也不处理。
• DMA + 空闲中断：DMA把串口数据直接搬到内存，空闲中断时读DMA剩余计数器hc->hdmarx->Instance->NDTR，得到这次收了几个字节。这个方案吞吐率高，适合大数据量传输。

我在这块踩过的一个很经典的坑是：接收缓冲区用200字节，DMA一次传完，判断接收长度时误用了HAL_UART_Receive_DMA的返回值，而不是读NDTR，导致每次收到的都是0字节。后来改成读DMA计数寄存器，一切就正常了。这个细节特别容易被人忽视，希望你别再掉进去。

5.3 USB虚拟串口：枚举失败看着像硬件问题

“STM32 USB虚拟串口”这个热词点出了一个很现实的需求：现在笔记本都没有DB9串口，用USB转串口芯片（CH340、CP2102）当然可以，但USB虚拟串口（USB CDC）更节省成本，而且能顺便做USB自定义HID。

虚拟串口的坑主要在时钟精度和D+上拉电阻。USB协议要求数据速率精度在±0.25%以内，所以强烈建议使用外部晶振，不要用内部RC振荡器。很多人在F103上用自带USB，但怕麻烦没接外部晶振，然后发现电脑一直提示“无法识别的USB设备”。一旦把晶振换成8MHz或16MHz外部晶振，基本立刻修复。另外，在USB的D+线上通常需要1.5k上拉电阻，有些芯片（比如STM32F103）内部带了这个上拉电阻，但需要软件PULLUP位开启，有些则必须板级外接。枚举失败的排查顺序是：先看原理图有没有外接上拉，再看USB时钟配置是否正确，最后查驱动是否装了ST的VCP驱动。

6. 外设驱动与常用模块：那些教科书上没教的细节

这部分汇集了大量热词：OLED、I2C、BH1750、DS3231、ESP8266、超声波、按键模块。看起来杂乱，但底层逻辑其实是同一个：外设驱动的关键不在发送指令，而在于时序和电平判断。

6.1 I2C总线和OLED的软硬件矛盾

BH1750光强传感器、OLED屏这些模块基本都是I2C接口，而STM32的硬件I2C因为芯片厂商标注和库函数实现历史上曾被诟病，很多老工程师直接放弃硬件I2C，改用软件模拟I2C。用GPIO口来模拟SCL和SDA，代码虽然“土”，但稳。

硬件I2C坑的地方在于：

• 需要配置I2C_ClockSpeed、I2C_DutyCycle、I2C_Ack、I2C_AcknowledgedAddress这几个参数，很多人漏配了ACK位，导致发送后总线挂死。
• 多主机或与不同电平外设混接时，需要外接上拉电阻。很多模块板子自带4.7k上拉，但如果你自己搭板，不加这两个电阻，I2C波形就是一团糊。

软件模拟I2C的注意事项反而好掌握：开漏模式、上拉使能、起始条件和停止条件的延时别太短。我一般把延时设在1~2us左右，然后拿逻辑分析仪看波形。OLED屏在I2C模式下还有个细节：地址引脚（通常标SA0）决定设备地址是0x78还是0x7A。很多人把地址写错，屏幕上就白屏。驱动不亮时先把I2C地址扫描一遍，看挂在总线上的设备到底回应哪个地址，比盲改代码高效。

6.2 ESP8266这类Wi-Fi模块：串口透传不是“接上就能用”

用STM32控制ESP8266做Wi-Fi透传是常见玩法。但ESP8266模块有它自己的启动时序：模块上电需要大约几百毫秒到几秒的串口响应时间，如果你在STM32上电后立刻发AT指令，大概率会丢掉模块的“ready”或者“AT”响应。

我踩过的坑还有电平问题：ESP8266的串口电平是3.3V，但有些模块套件上集成了电平转换电路，有些没有。如果你直接用5V的TTL串口去接模块，轻则通信乱码，重则烧模块。接之前一定看下模块型号和外围电路。

另外一个看着很“低级”但经常发生的坑：STM32的TX要接ESP8266的RX，ESP8266的TX要接STM32的RX，交叉连接。很多人做杜邦线连接时，习惯性两头对齐，结果RX对RX、TX对TX，直接全军覆没。每次连线前默念一遍“交叉交叉”。

6.3 按键消抖和ADC采样时间：基础中的基础，却是最多人问的

“stm32按键模块电路设计”和“stm32 ad采样时间”都在热词表里。按键消抖最朴实的方法是扫描+延时+再确认，但实际项目中更推荐用定时器中断来做“状态机消抖”，10ms扫描一次，连续两次读到同一状态再确认变化。这样不阻塞主循环，而且还带自动长按、短按判断能力。

ADC采样时间的坑在“采样时间太短导致阻抗不匹配”。STM32的ADC采样其实是开关电容结构，内部有一个采样电容，外部信号源的内阻如果太大，采样时间内电容充不满，读数就会偏低。解决方法是增大ADC_SAMPLETIME_239CYCLES_5这类采样时间，或者在ADC引脚前面加一个100nF的电容。这对于测电池电压、光敏电阻这类高阻信号非常关键。你说你是做“stm32鱼缸”的，拿ADC去测水位传感器，如果你采样时间配短了，读数飘得跟股票一样，那种挫败感我特别能体会——把采样时间调到最大试试，波形瞬间就稳了。

7. 综合项目里的“系统级”问题：从合上电到OTA

到了这个层面，你不再只调试某个外设，而是开始面对“系统能不能一起工作”这件事。热词里“基于stm32的毕业设计”“两轮差速小车stm32控制”“stm32 ota”“基于stm32 ethercat”“stm32控制伺服电机485”基本都能归结到几个系统集成的痛点上。

7.1 一个工程里多个外设，先初始化谁

很多人上来就把外设初始化写得密密麻麻，结果莫名奇妙的bug此起彼伏。我的习惯是先给系统分层：

1. 时钟树初始化（谁都不先跑，先把主频确定）；
2. GPIO基础初始化（关键引脚先设为确定状态，尤其LED和电机使能脚，防止默认电平乱输出）；
3. 中断控制器NVIC配置（把每个外设的中断优先级排好，避免嵌套混乱）；
4. 低速外设再高速外设（I2C、串口、SPI这类先测试通，再开定时器、ADC、DMA）。

比如做“两轮差速小车”，你肯定同时用到左右轮编码器、电机PWM、串口遥控、OLED显示。如果初始化顺序颠倒，比如PWM输出前没有把电机使能引脚拉低，轮子就会在系统上电瞬间猛冲一下。很多小车项目“一上电就疯跑”，根源往往不是算法问题，而是初始化顺序和电平状态的问题。

7.2 RS485控制伺服和EtherCAT这类工业总线

“stm32控制伺服电机485”现在逐渐变成热门需求。RS485是半双工总线，所以方向控制引脚DE/RE的控制时机非常重要：发送完一帧数据后，要立刻把方向切回接收，否则对方回的响应，你全收不到，或者把自己发的数据回环到自己的接收里。

我当年在485通信上踩的最深的坑是：波特率配置对了、方向也切换了、接线也是好的，但就是收不到回复。后来用示波器一看，A/B线上没有接终端电阻，或者终端电阻匹配不当，导致电平飘逸，信号反射严重。虽然短距离传输不接也能聊胜于无，但一旦距离超过几米或者是总线挂多台设备，120欧终端电阻就非常关键。

至于EtherCAT，这里不多展开，简单提一句：STM32本身不带EtherCAT从站控制器，一般是外接LAN9252这类从站芯片，然后通过SPI接口通信。调试的难点更多在“ESC配置”和“邮箱通信”，而不是STM32自身。如果你搜这个热词是想做运动控制总线从站，建议先去把LAN9252的数据手册读懂，再研究是跑官方驱动还是自己二次封装。

7.3 OTA升级，别把Bootloader和App的地址搞乱

OTA热词被搜这么频繁，说明现在很多人期待“远程升级”这个功能。但分两个程序、两个Flash区域，地址表一旦错乱，设备就会变砖。

标准方案是：Bootloader放在Flash起始地址（比如0x08000000），App放在0x08008000（偏移32KB）。App编译时要改三个地方：

• IROM1起始地址改为0x08008000，大小为剩余空间；
• 中断向量表偏移寄存器SCB->VTOR = 0x08008000；
• 如果用的是HAL库，需要把系统时钟初始化保留起来，避免App重新初始化外设时出现“时钟冲突”。

变砖后的恢复，就要靠Bootloader里的串口或USB下载功能了。所以做OTA时，我一般第一步就会写一个极其简单、打死都不会坏的串口Bootloader，确保App再怎么乱，都能回到工厂状态。这一步省了不知道多少返工成本。

8. 常见问题速查表与调试思路整理

最后把这几年遇到的典型问题整理成一张速查表，方便你直接定位问题：

调试这件事，说到底拼的是两样东西：排查顺序和耐心。排查顺序对了，一半的坑其实都能提前避开。比如遇到问题先量电压、再看波形、再查配置，而不是上来就改代码乱试。

我个人做了这么多年项目，最大的体会是：不要相信任何外设模块“默认就能工作”的说法。每个模块上电后都要验证通讯，每根线都要按信号流向检查，每个外设时钟都要按数据手册例程配置，ST的参考手册翻得再勤快也不为过。那些看起来神乎其神的“一次性点亮”，背后都是早就把坑填平了的经验。

如果你现在也被某个诡异bug折磨着，不妨把问题拆成“硬件问题”和“软件问题”两块，然后用排除法一片片切。对照上面的表先走一遍，实在走不通，再用示波器、逻辑分析仪去抓信号——工具一上手，问题往往就藏不住了。