1. STM32的系统架构：先建立整体思维模型

搞嵌入式这些年，我见过太多人学STM32的方式是“点灯→花式点灯→彻底迷茫”。灯会闪了，但换个芯片、换个外设就完全不知道从哪里下手，根源就在于没有把STM32的理论骨架搭起来。STM32本质上是一台“配置驱动的微型计算机”，你写的代码不过是在摆布它内部的总线、时钟和寄存器。理解了这三件事，后面所有外设都是纸老虎。

1.1 总线架构：代码和数据到底怎么跑

STM32内部并不是一个所有外设都直接挂在CPU屁股后面的“大集市”，而是分成了好几条道路。以最经典的STM32F103为例，CPU核心通过三条主要总线对外通信：I-Bus（取指令）、D-Bus（读写数据）和S-Bus（系统总线）。I-Bus和D-Bus主要访问Flash和SRAM，速度极快；S-Bus则通过总线矩阵连接到AHB（高级高性能总线）、APB1和APB2（高级外设总线）。

这个总线矩阵是整个系统架构最精彩的地方——它允许CPU、DMA、以太网MAC等多个主设备同时访问不同的从设备，好比一座立交桥，四路车流互不打架。实际开发中，我建议你手里要常备一份芯片的“总线框图”，不用背，但看到某个外设时要能反应过来它挂在哪条总线上。比如USART1、SPI1挂在APB2（最高72MHz），而USART2、USART3、SPI2挂在APB1（最高36MHz）。这个差异直接决定了你算波特率、算定时器时钟时该用哪个频率。

很多人折腾半天定时器频率不对劲，最后发现是APB1预分频系数对定时器的影响没算进去。APB1预分频为2时，挂载其上的定时器时钟反而会自动加倍到72MHz，这属于STM32的设计惯例，想省心就把芯片参考手册（Reference Manual）那页翻出来，现场对照着算一遍。

1.2 时钟树：理解了一棵树的脉动，就理解了所有外设

所有外设的工作都离不开时钟。STM32的时钟源分为内部高速RC（HSI 8MHz）、外部高速晶振（HSE）、内部低速RC（LSI 40kHz）、外部低速晶振（LSE 32.768kHz），以及锁相环（PLL）倍频后的系统时钟。实际工程中我们通常用外部8MHz晶振接入PLL，倍频到72MHz作为SYSCLK，然后经过AHB预分频、APB1预分频、APB2预分频，再分发到各个外设。

这里有一个非常经典的坑：修改PLL倍频系数后，系统时钟变了，但串口波特率、定时器周期、延时函数全都跟着变。我见过有人在调试时把HSE换成内部HSI忘改代码，结果整个系统时钟从72MHz掉到8MHz，OLED刷新慢得像PPT。想避免这种问题，就一律在SystemInit()和时钟配置函数里把时钟树理顺，并在初始化后读出RCC_GetClocksFreq()校验一下实际频率。

还需要明白一件事：先开时钟再配寄存器。GPIO、USART、DMA这些外设的寄存器，在没开启对应RCC时钟之前，连读到的值都是默认值甚至读不到。这是初学者第一个容易忽略的理论节点，也是最常见的“为什么我的引脚没反应”的答案。

1.3 启动流程与引脚确认：代码在“上电瞬间”经历了什么

STM32上电后，CPU从复位向量处取出栈顶地址和复位Handler地址，然后执行启动文件（startup_xxx.s）中定义的中断向量表。启动文件的作用并不神秘：初始化堆栈、设置中断向量表、调用SystemInit()配置时钟，最后跳转到main()。

但有一个细节很值得注意：芯片的启动引脚BOOT0和BOOT1决定了解复位后从哪里取指。BOOT0拉低，从Flash启动；BOOT0拉高、BOOT1拉低，从系统存储器启动（通常用于ISP下载）；都拉高则从SRAM启动。不少人在自制开发板上程序下载不了，一查发现BOOT0悬空导致反复进入奇怪的启动模式。这种问题理论上一句话就能讲明白，但实操中能卡住一整晚。

说到引脚确认，我第一次拿到的芯片没有丝印，差点把第1脚和最后一个脚搞反。STM32的TQFP封装一般在左上角有圆形凹坑或小圆点，左下角有倒角，对应第1脚。以凹坑或圆点为准，逆时针方向依次为1、2、3……需要焊接时，务必先在数据手册里找到该封装的“Top View”引脚图核对一遍。芯片烧了不要紧，PCB焊盘铜皮掉了才是真麻烦。

2. 开发环境与工程模板：把地基打牢的完整套路

环境搭建是STM32学习之路上第一个劝退点，因为工具链涉及的地方实在太多：MDK版本、芯片器件包、调试器驱动、烧录算法等。我自己的经验是：环境问题最好一次性解决，不要每次项目都重新折腾一遍。记录下每一步的具体操作，做成一个“环境搭建清单”，以后换电脑、换芯片都能照着走。

2.1 Keil5如何同时兼容C51和STM32

网上经常看到有人问“Keil5能不能同时开发51和STM32”，答案是可以的，但有一个前提，就是分别安装C51和MDK两个版本的Keil。官方其实是把两者做成了安装包形式，你在安装MDK后再装C51版补全包，或者反过来都行。安装时注意不要覆盖到同一个目录，建议分别指定不同的安装路径，注册时用两个License，一个给C51、一个给MDK。

实际使用中，切换工程的本质是让IDE按工程文件指定的芯片型号自动切换工具链。如果你的Keil打开51工程时提示找不到器件，那就是C51 Device Database没装好；打开STM32工程提示芯片找不到，则是MDK的器件包（DFP）没装。还有一个细节是，Keil5默认不携带老芯片的包，需要手动从Pack Installer里下载，或者直接到芯片厂商官网下载离线包双击安装。

另外在工程配置里，Output标签页可以设置生成hex文件的路径，我习惯放到和工程同级的Objects目录下，避免默认路径嵌套太深导致找不到烧录文件。遇到“Load D:\stm32 project\...\project.axf error: Flash Download failed”这类问题时，十有八九是目标芯片Flash算法没选对。在Options for Target的Utilities标签页里，点Settings，把Flash Download标签下的Programming Algorithm改成对应芯片的型号（比如STM32F10x High-density Flash），再勾选Reset and Run，问题基本就解决了。

2.2 标准库新建工程的七步法

虽然HAL库越来越流行，但我仍然建议初学者先用标准库（Standard Peripheral Library）搭一个最小工程，因为标准库更接近寄存器，能帮你建立“每一个外设对应的寄存器结构体”这个思维。以下是创建一个标准库工程的核心步骤：

1. 准备文件：从STM32官方标准外设库中拷贝CMSIS核心文件、标准外设库固件（STM32F10x_StdPeriph_Driver）以及对应型号的启动文件。
2. 新建工程：在Keil中Project → New uVision Project，选择芯片型号。
3. 添加文件组：按User、CMSIS、Startup、StdPeriph_Driver分组管理，便于维护。
4. 配置宏定义：C/C++选项卡的Define里填写USE_STDPERIPH_DEVICE和芯片型号宏（如STM32F10X_HD）。这个宏决定标准库中哪些外设代码被编译，漏了它，很多函数会报未定义。
5. 指定头文件路径：把CMSIS、标准外设库的Include目录全部添加进入Include Paths。
6. 配置调试器：选择ST-Link Debugger，并在Settings中确认能识别到芯片IDCODE。
7. 编译烧录：先用一个最简单的main()点灯，确认工具链完整。

这套流程看起来繁琐，但一次跑通后，你的工程结构会非常清晰。以后不管是做毕业设计还是公司项目，新工程都能在一分钟内搭好。有的人喜欢用CubeMX生成HAL工程，这当然也行，但我始终觉得标准库这一步省略不得，它是理解“外设驱动是怎么写的”的窗口。

2.3 ST-LINK Utility与调试器升级那些事

ST-LINK Utility是ST官方提供的独立烧录工具，支持擦除、烧录、校验和读取Flash。用ST-LINK Utility烧录hex文件时，最常用的是整片擦除后烧录，这对于量产或恢复出厂状态特别方便。

但ST-LINK的驱动和固件时不时会掉链子。典型现象是：连接STM32时提示“Target connection failed”或者“ST-LINK firmware upgrade required”。解决方式就是使用官方工具STSW-LINK007更新ST-LINK固件。注意，升级过程中不要拔插USB线，否则ST-LINK变砖的概率很高。更新完固件后，重新插拔，Keil里就能正常识别了。如果升级失败，可以先按住ST-LINK上的复位按键再插入电脑，再执行强制升级，这样能救回来。

最让我无语的是，很多人的ST-LINK连不上压根不是固件问题，而是排线没接对。SWD接口总共就四个关键信号：SWDIO、SWCLK、GND、3.3V。接线顺序错了，调试器自然认不出芯片。这种低级错误，排查时先拿万用表量一遍杜邦线，比反复点Keil的下载按钮强一百倍。

3. 定时器：从模式理论到测频率实战

定时器是STM32中“性价比”最高的外设，没有之一。PWM输出、输入捕获、编码器模式、PWM输入模式、定时器级联，全部靠它完成。很多热词比如“stm32定时器捕获测频率”“stm32定时器模式”都属于这一范畴。要玩明白定时器，先弄懂三个寄存器：预分频器（PSC）、自动重载寄存器（ARR）和计数寄存器（CNT）。

3.1 定时器家族与PWM输出的参数计算

STM32的定时器家族分为基本定时器（TIM6、TIM7）、通用定时器（TIM2-TIM5）和高级定时器（TIM1、TIM8）。基本定时器只能计数，通用定时器加了输入捕获、输出比较和编码器接口，高级定时器又额外支持互补输出、刹车功能和死区插入，专门用来驱动电机控制类的应用。

PWM输出的本质，就是让定时器计数器CNT在一个周期内与捕获比较寄存器（CCR）比较，CNT小于CCR时输出一个电平，CNT大于CCR时翻转电平。因此频率的公式就是：PWM频率 = 定时器时钟 / ((ARR+1)(PSC+1))。以72MHz时钟为例，想要1kHz的PWM，设置ARR=999、PSC=71，代入公式就是72MHz / (100072)，也就是1000Hz。占空比则直接用CCR/(ARR+1)计算，CCR=250时占空比就是25%。

实际调试时经常遇到“PWM输出频率正确但引脚上没有波形”的情况，这时要检查复用功能是否开启。标准库中需要调用GPIO_PinRemapConfig()把定时器通道映射到指定引脚，同时把对应的GPIO模式设置为AF_PP（复用推挽输出）。还有个小细节，修改ARR和CCR时如果只改寄存器不更新影子寄存器，输出不会立刻变化，记得触发更新事件（TIM_GenerateEvent(update)）或者等待溢出。

3.2 输入捕获测频率的原理与步骤

输入捕获测频率，是利用定时器外部通道引脚检测上升沿（或下降沿），并记录当前CNT的值。两次上升沿之间的CNT之差，乘以定时器时钟周期，就是输入信号的周期，取倒数就是频率。这是测量方波频率最通用的办法，PWM输入模式本质上还是输入捕获。

实操中，我用TIM2_CH1（PA0）作为捕获通道来测量外部PWM信号频率。首先把TIM2设置为上升沿捕获，每次都读取捕获寄存器CCR1的新值，再配合计数溢出处理。这里最大的坑是：被测信号频率很低时，CNT可能发生多次溢出，只靠CCR1差值计算会出现巨大偏差。所以要开启定时器更新中断，在中断里记录溢出次数，最终频率 = 定时器时钟 / ((溢出次数*ARR+CCR差值+1) * (PSC+1))。

还有一个细节：输入捕获触发后要记得清除捕获标志位（TIM_ClearFlag(TIM2, TIM_FLAG_CC1)），否则下一次捕获会失败。如果有条件，用逻辑分析仪或示波器看一眼CH1引脚的信号质量，上升沿太缓的话可以打开输入滤波器，设置ICF（Input Capture Filter）的采样频率和采样次数，避免毛刺导致误捕获。

3.3 编码器模式与PWM输入：比你想的更有用

编码器模式是通用定时器非常高级的用法，把TIMx_CH1和CH2配置为编码器接口模式后，定时器就自动根据A、B相脉冲进行加减计数。CNT的值直接对应编码器的角度或线位移，不需要外部中断参与。电机闭环控制里，这个功能简直神级。

我把编码器模式理解成“硬件替你做鉴相”：A相超前B相90°时CNT增加，B相超前A相时CNT减少，硬件自动判向。实际项目中，我用TIM4的编码器模式读取光电编码器，分辨率从每圈几百脉直接翻了四倍（因为有四倍频检测），爽得很。配置时记得把编码器模式的映射方式选对，否则转动方向会反过来，转动一圈后角度值可能负增长。

至于PWM输入模式，其实是输入捕获的一种特殊接法：把同一路的PWM信号同时接到两个通道上，一个通道测周期，另一个通道测占空比。这个模式对遥控器信号解析、舵机测试特别方便。第一次使用这个功能时，我被RC1和RC2两个捕获寄存器配合使用的方式搞得有点晕，后来对照参考手册的时序图才明白：一个捕获上升沿记录当前值，另一个捕获下降沿记录当前值，两个值的组合就同时得到了周期和脉宽。

4. 通信外设：USART、I2C、USB虚拟串口串讲

通信是嵌入式系统存在的基础。STM32上的通信方式五花八门，但理论模型却高度一致——要么是“发一帧数据，等对方回应”，要么是“把数据放进缓冲区，硬件自动发出去”。学通信外设，最重要的不是背接口函数，而是搞清楚你要连接的那一端是什么角色、什么电平、什么时序要求。

4.1 USART串口：从轮询到中断再到DMA的进化之路

USART（通用同步异步收发器）是STM32最基础、最常用的通信接口。硬件上至少需要TX、RX两根线，双方还要约定波特率、数据位（典型8位）、停止位（典型1位）、校验位（通常无）。波特率的理论计算公式为：波特率 = fck / (16 * USARTDIV)，实际编程中直接调用标准库的USART_InitStructure即可，但前提是USART时钟源的频率必须准确。比如USART1挂在APB2（72MHz）时和USART2挂在APB1（36MHz）时，同一个波特率配置寄存器的值会不同。

初学时建议从轮询方式开始，调用USART_SendData()发送、等待TXE标志位，再用USART_ReceiveData()读取。但这种方式会阻塞CPU，不适合实时系统，所以我很快切换到中断方式：接收数据时开启RXNE中断，在中断服务函数里把数据放入环形缓冲区；主循环只管从缓冲区取数据。这样CPU就不会被低频外设拖死。再进一步就是DMA方式，串口硬件把数据从内存搬进搬出，CPU几乎零负担，这是物联网低功耗设备的标配做法。

关于串口通信的一个经典误区：两个设备的地线（GND）不共地。串口本质上是对地电平通信，如果两边参考地不一致，数据全是乱码，甚至可能烧毁IC。用USB转TTL模块调试时，模块的TXD接STM32的RXD、模块的RXD接STM32的TXD，交叉接线后还要确认二者供电逻辑电平一致（3.3V对3.3V，或者5V对3.3V需加电平转换）。

4.2 I2C与OLED显示：多个设备共享两条线

I2C是一种半双工、多主机的串行总线，只有SCL（时钟）和SDA（数据）两根线，所有设备挂在同一条总线上，通过设备地址区分。工程里最常见的例子就是0.96寸OLED（SSD1306）和温湿度传感器（如DS3231）挂在同一个I2C上。每个设备都有7位地址，SSD1306通常为0x3C，DS3231为0x68。

硬件上，I2C的SDA和SCL都是开漏输出，必须外接上拉电阻（典型4.7kΩ），否则总线无法输出高电平。软件上，标准库提供了I2C_SendByte和I2C_RecvByte等函数，但主从交互的时序（起始条件、停止条件、ACK应答）需要按照数据手册一步步来。我建议初学者先用软件模拟I2C（GPIO手动拉高拉低）跑一遍OLED驱动，这样波特率不重要了，时序也变得完全透明。

实际调试I2C时，我最常用的手段是逻辑分析仪抓取SCL和SDA波形，对照时序逐段分析。最常见的错误是应答位判断失误，导致主机停止通信。而硬件I2C虽然库函数简单，却常因时序配置不当卡死在忙状态，这时只能复位I2C外设或干脆换软件模拟。对于OLED这类显示器件，如果能闪屏或花屏，大概率是I2C速率太高（超过400kHz）或电源纹波太大，降低速率试试往往马上有效。

4.3 USB虚拟串口：不装驱动的通信方案

USB虚拟串口（USB Virtual COM Port）是STM32上的USB设备应用，是指把STM32的USB外设配置成CDC（通信设备类），电脑端不需要额外安装驱动（多数系统自带），就能识别成一个串口，实现和USART几乎一样的收发体验。其本质是USB端点通信，而不是真正的UART。

配置USB虚拟串口需要理解USB端点描述符：控制端点0用于枚举，批量端点（如端点1 IN和端点1 OUT）用于数据收发。标准库的USB例程中，usb_desc.c文件里定义了设备描述符和配置描述符，CDC类描述符包含接口关联描述符、两个接口（通信接口和数据接口）、端点描述符。很多初学者修改VID/PID后插入电脑提示“未知设备”，多半是描述符长度或端点地址配置与驱动要求不一致。

用USB虚拟串口发送数据时，要注意USB是“按包传输”的，一次调用发送函数的长度最好不超过端点最大包长（通常是64字节）。想发一长串数据，得拆分发送，或者等待上一个包发送完成后（检查端点发送状态寄存器）再发下一包。调试时我还会加一个USB转串口工具配合监视，方便区分数据到底卡在USB枚举阶段还是卡在应用层。搞定了USB虚拟串口，再去做后面的USB HID键盘、USB Mass Storage，心态会平和很多。

5. 进阶方向：FOC、LVGL、EtherCAT等综合应用

当基础外设都能熟练使用后，很多人会开始往“有技术含量”的方向走，比如无刷电机FOC控制、GUI界面移植、工业以太网通信等。这些方向没有一个是用单一外设能解决的，恰恰是检验你对整个STM32理论体系理解深度的试金石。

5.1 FOC控制：从Clark变换到SVPWM

FOC（磁场定向控制）是无刷直流电机（BLDC）和永磁同步电机（PMSM）高效控制的主流算法。它不是简单地输出六步换相方波，而是把三相电流通过Clark变换（将三相静止坐标系变换为两相静止坐标系）和Park变换（将两相静止坐标系变换为旋转坐标系）转换成d轴和q轴的直流分量，然后像控制直流电机一样控制id和iq，最后再反变换回去产生SVPWM波形。

听起来复杂，但STM32在这方面的硬件支持很到位：高级定时器TIM1自带互补PWM输出和刹车功能，内部比较器配合ADC可以同时采样两相电流。使用CubeMX生成FOC工程很方便，很多厂商甚至提供免费电机库，可以直接调好PI参数。我实际跑FOC时最大的教训是，电流采样必须在PWM中心对齐的时刻触发ADC，否则采样到的电流噪声大得离谱。

调试FOC离不开上位机曲线工具，通常把速度环、电流环的输出通过串口打印出来。转速阶跃响应、电流波形一顿观察，PID参数就有了调校方向。另外，FOC不是有了代码就能跑，电机参数的辨识（相电阻、相电感、反电动势常数）必须先做准，否则电流环带宽怎么调都振不起来。

5.2 LVGL移植：在M4上跑出流畅的UI

LVGL（Light and Versatile Graphics Library）是一款开源嵌入式图形库，支持触摸、控件丰富、资源占用相对友好。STM32F407甚至F103都可以跑，只是复杂界面和高分辨率屏对性能、内存的要求会高一些。移植LVGL最核心的三件事：底层打点函数、时基（tick）和内存分配。

先说打点函数，就是把LVGL的flush回调里传入的缓冲区内容，按像素格式写入到屏幕驱动芯片（比如ILI9341）的GRAM里。颜色格式默认是RGB565时，一个像素占两个字节，缓冲区大小至少屏宽屏高2。对于320*240的屏幕，缓冲区全量就是150KB，MCU内存根本吃不下，所以LVGL支持部分刷新，只需提供行缓冲或者框高缓冲，每次只刷新一小块区域。刷新太慢则屏幕会有明显撕裂感，解决办法是开DMA配合双缓冲，结合垂直同步信号（TE）避免撕裂。

时基用SysTick或单独一个定时器实现，每毫秒调用lv_tick_inc(1)。内存分配方面，LVGL内置了lv_mem的分配器，只需字节对齐的静态数组或直接复用C标准库malloc，但要注意堆空间必须足够大。我建议至少分配超过当前所需内存两倍的堆，否则复杂界面一次加载多张图片就会卡死白屏。移植成功后下一步就是添加输入设备驱动，把触摸屏的坐标接入lv_indev_drv，UI从此“手感”大不一样。

5.3 EtherCAT与485伺服控制：工业通信的入场券

工业自动化场景里，伺服电机通信最常用的两种方式是脉冲/方向或Modbus-RTU，更高端的就是EtherCAT。STM32本身没有EtherCAT从站控制器，通常需要外接LAN9252等专用从站芯片，通过SPI接口让STM32与EtherCAT主站交换数据。这种方案的门槛主要在协议栈：需要移植SSC（Slave Stack Code）生成的从站代码，理解对象字典（OD）、过程数据对象（PDO）、同步管理器（SM）等概念。

相比之下，用RS485控制伺服电机门槛低很多，思路也很清晰：RS485是半双工总线，用MODBUS-RTU协议发送位置、速度、扭矩指令。接线时A接A、B接B，终端电阻按情况加上，STM32侧用USART配合方向控制引脚（DE/RE）切换收发。调试期间我最常踩的坑是“发送正常、接收乱码”，原因多半是方向切换时序不对，发送完数据立刻切到接收模式，但总线还没稳定，收到的是最后一字节的回声。解决办法是发送完成后适当延时2个字符时间，再切换方向，或者干脆在RS485芯片的收发切换引脚上加小的RC延时。

6. 避坑实录：从下载失败到代码卡死

这部分是我最想写、也最有底气的章节。这些坑每一个都是我实实在在踩过的，也都对应着热搜词里高频出现的搜索问题。它们表面上是“操作错误”，实际上都源于理论理解不够透彻，所以我把它们整理成速查表，希望能帮大家省掉几个通宵的时间。

6.1 Flash下载失败与“Load project.axf”错误

Keil报错“Load D:\stm32 project\...\project.axf error: Flash Download failed”可以说是最经典的入坑错误，几乎每个用Keil下载STM32的人都会遇到一次。这句话本身在告诉你：编译生成了AXF文件，但烧录这一步失败了。烧录失败的主要原因有四个：芯片Flash算法没选对、调试器连接不稳定、芯片处于读保护状态、目标芯片型号选错。

Flash算法在Options for Target → Utilities → Settings → Flash Download里配置。标准的STM32F103C8T6对应选“STM32F10x High-density Flash”或根据容量选择Medium-density，选错容量边界后只能烧入前一部分，或者直接失败。如果芯片被意外设置了读保护（RDP），擦除和烧录都会被阻止，这时需要在Utilities设置里先执行“Full Chip Erase”，或者用ST-LINK Utility连接后在Option Bytes中解除读保护。切记解除读保护会同时擦除整个Flash，代码白写也只能认栽。

还有一个细节容易被忽略：编译器生成AXF文件的路径可能含中文或空格，老版本Keil会由于路径解析异常导致烧录失败。工程目录最好全英文，路径中不要有括号和特殊符号。我之前建过“D:\stm32 prohect\2-1 stm32工程模板”这种目录，空格和数字前缀混在一起，偶尔就会触发莫名其妙的问题，后来统一改成“Project_XXX”的命名，再没出过全局诡异问题。

6.2 延时函数delay卡死的几种原因

延时函数delay卡死，是标准库工程中高频故障。最典型的是用了SysTick做延时，但SysTick中断被其他服务函数霸占，或者中断优先级配置不当导致SysTick永远得不到响应。比如在中断服务函数里写了一个很大的delay，而该中断优先级高于SysTick时，delay内部等待标志位永远等不到，系统直接“假死”。解决办法是进入delay前关闭相关中断，或把SysTick设置为最高优先级，或尽量避免在中断里调用长延时。

另一个常见的原因是HAL库的HAL_Delay依赖SysTick中断，一旦SysTick中断被用户代码屏蔽（比如调用__disable_irq()后没有立刻重新使能），delay就卡死。这在处理临界区时尤其容易发生，我在做I2C时序模拟时有过一次惨痛经历：进入临界区屏蔽中断后调用了HAL_Delay，结果整机卡死，拔电重启才恢复。此后我形成了铁律：临界区内绝不允许出现任何延时，延时必须是可被中断打断的或完全独立于中断机制的。

如果用的不是SysTick而是定时器延时，要注意定时器是否因占空比配置或ARR设置过大而发生溢出中断未处理，导致回调标志异常。排查delay卡死，先用暂停调试的方法看代码卡在哪一行，再用寄存器窗口看TICK标志位是否清零，通常问题几秒钟就能定位。

6.3 SWD引脚被禁用与程序“锁死”问题

不少人在某个项目里复用PA13、PA14等引脚做普通GPIO，或者在初始化里调用了GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE)，结果下载器下一次就再也连不上芯片了。这不是芯片烧了，而是SWD引脚被完全禁用，调试接口物理上关闭了，ST-LINK自然无法通信。

解决办法很简单但很考验操作：把BOOT0拉高，复位后让芯片从系统存储器启动，这时用户代码不会执行，SWD接口恢复可用，即可重新烧写程序。烧完再把BOOT0拉低复位回Flash启动。为了防止这种情况再次发生，我强烈建议不要在项目初始化时彻底禁用SWJ，最多只关闭JTAG而保留SWD（GPIO_Remap_SWJ_JTAGDisable），留一条后路给自己。

还有一种“假锁死”情况是芯片进入了低功耗模式（STOP或STANDBY），调试器同样无法连接。此时唯一高效的方式就是复位或重新上电，所以设计低功耗项目时要预留一个唤醒按键或上电复位电路，否则每次调试都要扣电池拔USB，体验极差。

6.4 常用问题排查速查表

超声波测距的坑大家问得多，我也补充一句：HC-SR04模块的TRIG引脚需要10µs以上的高电平触发，ECHO引脚的高电平持续时间和距离成正比。测距公式是距离(cm) = 高电平时间(µs) / 58，这个公式由来是声速344m/s时往返1cm需要约58µs。用定时器输入捕获测量ECHO引脚高电平宽度时，记得把捕获配置为上升沿开始计时、下降沿结束计时，或者结合先等上升沿再捕获下降沿的方法。

最后再分享一个我个人的实操心得：把每个外设的理论笔记做成“参数推导表”，比如“为什么定时器ARR=999、PSC=71得到1kHz”“为什么CAN总线的位时序会配成这种采样点”。这样学STM32不再是一盘散沙，而是一张可以随时调取的知识网。遇到新项目，先从这张网里找对应外设，理论通了，代码和调试速度都会快很多。嵌入式这条路，入门容易，精通难，但每打穿一个理论节点，后面就会一通百通。