企业官网建设流程全解析

1. 先搞懂 STM32 的核心理论框架

1.1 系统架构与总线矩阵

很多人一上来就点开 CubeMX 生成代码，跑通了点个灯就觉得自己入门了，结果后面做稍微复杂一点的项目，比如同时跑着 DMA 传输、ADC 采样、串口打印，一出现互相影响就完全懵了。其实 STM32 之所以能在一个低功耗、低成本的芯片上同时处理这么多任务，核心靠的是它的总线矩阵架构。我自己刚开始做的时候也没太在意这个，直到一次调试 DMA 和中断优先级冲突，翻了好几天手册才回过头来补课。

STM32 的主流型号基于 ARM Cortex-M 内核，比如 M3、M4、M7、M33 这些。内核本身只负责取指、解码和执行指令，但它要跟 Flash、SRAM、各种外设打交道，中间的通道就是总线。STM32 内部不是一根总线串到底，而是有多条总线并行工作，AHB、APB1、APB2 各管一摊。AHB 是高速主干道，CPU、DMA、Flash、SRAM 都挂在上面；APB1 和 APB2 是从 AHB 分出来的低速总线，外设挂在这里，APB2 通常频率更高，适合 TIM1、ADC、USART1 这类比较“挑剔”的外设。

理解了这层关系，再回头看外设寄存器配置里的“总线时钟使能”，就不会只是机械地调用__HAL_RCC_GPIOA_CLK_ENABLE()了。你就能明白为什么 GPIO 挂在 AHB 上，而 USART 挂在 APB 上，也能理解同一个外设在不同芯片型号上的最大工作频率差异是怎么来的。比如 APB1 上的定时器，如果 APB1 时钟没有倍频，定时器的计数频率就会跟预想不一样，这在做频率测量、PWM 输出的时候是致命的误差来源。

还有一点容易被忽略，DMA 并不是“免费”的，它也要占用总线带宽。如果同时开 DMA1 和 DMA2 做大量数据搬运，它们会跟 CPU 抢总线控制权。我见过有人用 ADC 的 DMA 连续采集几万点，又同时用 SPI DMA 刷屏，结果 SPI 刷屏周期性卡顿，原因就是总线仲裁冲突。所以做系统设计的时候，别光看 CPU 主频，总线负载也是一本账。

1.2 时钟树与启动流程

理论里第二门必修课是时钟树。STM32 不像老式 51 单片机那样上电就有一个确定的工作频率，它需要你告诉它用哪个时钟源、经过哪些分频倍频器、最终给哪些总线供电。这是很多新手的第一个坎，因为 CubeMX 里的时钟树界面第一次看确实有点晕，但它的逻辑其实非常清晰。

以常见的 STM32F103 为例，外部晶振 HSE 通常是 8MHz，通过 PLL 的 N、P、Q 三个参数倍频到 72MHz。这个 72MHz 就是 SYSCLK，然后 AHB 预分频器决定 HCLK，APB1 和 APB2 再各自分频。这里有个坑：APB1 总线时钟最大 36MHz，所以你要把 APB1 分频系数设为 2。但定时器的时钟源不是直接用 APB1 的 36MHz，而是如果 APB1 分频系数大于 1，定时器时钟会自动翻倍成 72MHz。所以很多人写延时函数，用定时器做微秒延时，发现时间总不对，十有八九就是没算清楚这一层。

启动流程方面，STM32 上电后会先从 Flash 的 0x08000000 地址读取向量表，执行启动文件里的Reset_Handler，然后初始化堆栈、调用SystemInit配置时钟，最后才跳转到main函数。这个过程是自动的，但你如果自己写链接脚本或者做 IAP 升级，就必须手动处理向量表重定向。我写过一版 Bootloader 程序，最开始忘了设置 SCB->VTOR 寄存器，导致 App 一上电就进 HardFault，排查了一下午，原因就是中断向量表还在 Bootloader 的地址上。这种问题靠仿真器都难查，只能靠懂启动流程，用内存窗口看反汇编才能定位。

2. 开发环境与工程搭建

2.1 工具链选型：Keil、VSCode 与库的选择

关于开发环境，这几年经常有人纠结到底用 Keil 还是 VSCode。我的观点很直接：做产品、进公司跟团队协作，Keil 或者 IAR 依然是主流，因为工程文件、调试器支持、中间件适配都最省心；自己玩、做开源项目、喜欢折腾，VSCode 配 ARM GCC 完全没问题，尤其用 CMake 管理多平台工程会舒服很多。两个不冲突，也不用非要站队。

很多人的电脑上装的 Keil5 里既有 C51 的包又有 STM32 的包，这就是所谓“Keil5 兼容 C51 和 STM32”的安装方式。其实只要注意两点：先安装 C51 版再安装 MDK 版，或者安装在不同目录然后分别破解；安装完 MDK 后需要在 Pack Installer 里安装对应芯片的器件支持包。不要把两个版本的安装路径混在一起，否则 CDC 驱动和编译器版本会互相干扰，我就见过有人把 C51 和 MDK 装到同一个文件夹，最后 Keil 直接打不开工程。

库的选择上，现在官方主推 HAL 库和 LL 库，标准库已经停止更新了。但我还是建议学过标准库的人不要急着否定它，标准库的寄存器映射清晰、代码直白，非常适合用来理解外设工作原理。HAL 库封装层次多，回调函数绕来绕去，新手容易“跑通了却不知道数据从哪来”。而 LL 库介于两者之间，速度接近寄存器操作，代码量又比寄存器少得多。如果你是从 51 单片机转过来的，我更推荐先用标准库或者 LL 库把基础外设过一遍，再用 HAL 库做实际项目。理论要落在“能看懂寄存器”这个底子上，否则换一个芯片平台你又得从头学。

2.2 从零创建工程：模板、LD 文件与芯片包

创建工程时，很多人直接用 CubeMX 生成一整套代码，这样当然快，但一旦生成的代码有问题，你往往不知道去哪改。我自己习惯是能自己搭模板就自己搭，哪怕麻烦一点，至少我知道每个文件在干什么。一个最基本的 STM32 裸机工程包含：启动文件startup_stm32fxxx.s、系统初始化system_stm32fxxx.c、链接脚本.ld、主程序main.c、外设驱动源文件，以及一个头文件路径配置。

这里特别说一下LD 文件。很多人不知道它有什么用，只知道编译报错的时候瞄一眼。STM32 的链接脚本里定义了 Flash 和 RAM 的起始地址和大小，决定了代码段、数据段、BSS 段怎么放。如果你做 Bootloader 和 App 分区，就必须修改 FLASH 的起始地址。比如 Bootloader 占用 0x08000000~0x08003FFF（16KB），那 App 的 FLASH 起始地址就要改成 0x08004000，长度相应减少。不改 LD 文件，就算你在代码里写了跳转函数，App 也跑不起来。我第一次做 OTA 升级时就吃了这个亏，跳转后要么死机，要么跑一段就 HardFault，最后发现是 App 工程里 Flash 地址没偏移，中断向量表直接覆盖了 Bootloader 区域。

“ST 芯片包安装”也是一个高频问题。Keil 里装不上包时，大概率是网络问题或者 Pack Installer 版本不对。可以到 Keil 官网手动下载.pack文件，然后双击安装。还有一种情况：装了新包之后旧工程打不开，提示 “Device not found”，那是因为你安装的包版本和工程里记录的器件型号不匹配。用文本编辑器打开.uvprojx文件，看里面的<Device>标签，就能知道工程当时用的是哪个型号和封装。

2.3 下载与调试：J-Link、SWD、JTAG 与报错处理

调试环境的问题更接地气。VSCode 搭建 STM32 开发环境，通常是用 ARM GCC 工具链加 OpenOCD，再加 Cortex-Debug 插件。网上教程很多，但真正卡住人的往往是launch.json的配置，尤其是要用 J-Link 的时候，需要在文件里写明"device": "STM32F103C8"或者更具体的内核类型，还要指定接口类型是swd还是jtag。

再说一个非常常见的报错：

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

这个错误翻译过来就是：调试器连上了芯片，但 Flash 算法不匹配，或者芯片读保护被开启了。解决办法分几步：检查 Debug 设置里的 Flash Download 选项，看有没有添加对应容量的编程算法；如果用了 J-Link，把连接速度从 5MHz 降到 1MHz 再试，很多时候是线太长、接触不良；如果还不行，多半是芯片被读保护锁住了，需要用STM32CubeProgrammer做一次全片擦除，把 Option Bytes 里的读保护等级改回 Level 0。

顺便提醒一句，调试烧录时如果一个工程里混合了 C51 和 STM32 的配置，可能会残留上次的芯片型号，导致下载算法匹配不上。每次新建工程时最好手动确认一下 Device 型号，别索引到别的芯片了。

3. 核心外设的“理论 + 实战”

3.1 定时器：从模式到频率测量

定时器是 STM32 里最灵活也最复杂的模块。F103 有高级定时器 TIM1/TIM8、通用定时器 TIM2~TIM5、基本定时器 TIM6/TIM7。它们的区别在于有没有 PWM 互补输出、有没有死区插入、有没有编码器接口。但理论核心都是一样的：一个计数器在一个时钟源驱动下不断加一或减一，到达设定值后触发更新事件。剩下的 PWM、输入捕获、输出比较，都是在这个基础上的变形。

做输入捕获测频率很多人会直接想到定时器的 PWM 输入模式，但要注意：这种模式只适合测量占空比相对稳定的信号，如果频率变化范围很大或者信号上有毛刺，出来的值飘得厉害。我自己做超声波测距时，最初也想用定时器输入捕获来测回波脉宽，后来发现超声波回波前端有衰减振荡，捕获到的第一个上升沿经常是假的，最后改成“先捕获一次，再开一个短窗口确认”的办法，才稳定下来。

还有个细节：捕获通道的滤波设置。定时器的捕获引脚上都有一个数字滤波器，可以在边沿检测之前滤掉小于若干个时钟周期的毛刺。Ceaser 在强干扰的电机控制环境里测转速，如果不设滤波，编码器信号一抖动，测出来转速明显偏高。设了 8 个时钟周期的滤波之后数据就平滑多了。这个参数在标准库里就是TIM_ICFilter，HAL 库里是sConfig.ICFilter，别看它不起眼，实际项目里真能救命。

3.2 ADC：中断与 DMA 的取舍

ADC 是另一个高频使用的外设。常规做法是轮询，程序一直等着转换完成，简单但浪费 CPU。中断方式适合单通道、低频采样，比如按键扫描、电池电压检测。但如果要多通道连续采样，或者采样率比较高，就必须用 DMA。

我实际做项目时的经验是：多通道采样一定要给 DMA 配上循环模式，让数据自己在 SRAM 里排队，主程序只在需要时读取数组。比如 3 个通道用扫描模式，每次转换完成 DMA 自动把结果送到数组，采样次数到了 N 次就产生一次 DMA 传输完成中断，主程序里直接取平均。这样做的好处是 CPU 几乎零开销，采样稳定性也更好。

不过 ADC DMA 有个不容易察觉的坑：如果你的数组元素类型是uint16_t，但 ADC 分辨率配成 12 位，那么 DMA 的宽度必须跟外设数据寄存器宽度一致。很多人用 HAL 库生成代码后，发现 DMA 传输的数据全是 0 或者错位，排查半天，最后发现是 CubeMX 里 DMA 的数据宽度默认配置和外设不匹配。这种问题用仿真器看内存是能看出来的，但在代码里不太容易发现。

3.3 UART 引脚定义、串口调试与 LIN、485

串口是嵌入式设备的“生命线”，几乎所有调试输出都靠它。但 UART 引脚定义很多人记不住，其实 STM32 的 USART 引脚都是可重映射的，标准库里有GPIO_PinRemapConfig，HAL 库里有HAL_GPIO_Ex之类的接口。以 F103C8T6 为例，USART1 默认是 PA9/PA10，但也可以重映射到 PB6/PB7。你要是画 PCB 的时候把引脚画错了，可以不改板子，改一下重映射就能救回来。

串口调试 PID 是运动控制的常用手段。我一般会把 PID 的三个参数、目标值、当前值、输出值打包成固定格式的字符串，用串口打印出来，再配合 matplotlib 或者匿名上位机画曲线。调试 PID 时尤其要注意打印的实时性，如果每个控制周期都打印一次，串口会成为瓶颈，导致整个控制周期被拖慢。我通常的做法是：在内存里缓存最近 500 个周期的数据，等一个运动过程跑完之后再集中打印，这样既不影响实时性，又能看到完整的状态变化。

再说485 通信。STM32 控制伺服电机走 485 总线，用的还是 UART 外设，只是物理层换成了差分信号。要注意三点：一是 RS485 是半双工，发送和接收要切换方向引脚，切换时机很讲究，发送完最后一个字节后不能立刻切回接收，否则最后一个字节可能还没发完；二是 485 总线要加终端电阻，很多小白在实验板上两三百米线不加电阻，结果通一两个字节就乱码；三是多机通信必须有明确的协议，比如 Modbus RTU，否则总线冲突处理起来非常痛苦。agile_modbus这个开源库我试用过，代码很精简，适合在 STM32 上做从机，比自己在中断里拼状态机省心很多。

3.4 SPI 与 I2C：ILI9341、BH1750、DS3231

显示类外设里，ILI9341 是入门最常见的 TFT 屏控制器。它的驱动可以用 SPI 也可以用 8080 并口，SPI 接口简单、省引脚，适合 F103C8 这种小封装。但有一个高频问题：读 ID 的时候读出来是0xA1A1。这个值其实是“芯片没有正确响应”的标志，原因可能有几种：供电电压不够、复位时序不对、SPI 模式配成 Mode 0 而屏幕需要 Mode 2，或者 MOSI/MISO 接反了。但如果你用的是四线 SPI 的屏，MISO 引脚上通常没有接实际数据线，因为 TFT 只支持写不支持读，读 ID 自然就返回垃圾值。这种情况下不要死磕读 ID，直接初始化后刷一个纯色测试画面，看屏幕有没有反应，比纠结寄存器值更实际。

I2C 方面，BH1750 是数字光照传感器，DS3231 是高精度 RTC。它们都是标准 I2C 设备，理论上很好驱动，但实际项目里最常踩的坑是：上拉电阻没接或者接得不对。I2C 是开漏结构，必须靠外部上拉把电平拉高。如果用 STM32 的 GPIO 模拟 I2C，可以开内部上拉；但如果用硬件 I2C 外设，内部上拉很弱，长线通信就会不稳。我见过有人在 Proteus 仿真里跑 I2C 没问题，一上实物就卡在 ACK 等待上，查到最后就是忘了焊接上拉电阻。仿真软件默认把 I2C 引脚理想化了，这是 Proteus 给新手挖的一个大坑。

4. 总线通信与协议栈

4.1 CAN 通信：现场排查技巧

CAN 总线在工业设备、车载电子里用得非常多，STM32F103 的 bxCAN 外设可以跑标准帧和扩展帧，支持 1Mbps 比特率。但很多人遇到 CAN 通信突然连不上，第一反应是怀疑代码，我却建议先查物理层。CAN 总线是差分信号，CANH 和 CANL 之间需要 120 欧姆的终端电阻，而且必须在总线两端各放一个。很多实验板上只焊了一个终端电阻，甚至一个都没焊，短距离调试时没感觉，一接长线或者节点数一多，通信就会间歇性失败。用示波器看 CANH 和 CANL 的差分电压，正常显性电平应该在 2V 左右，如果幅值偏低或者波形圆润，那就不要再试软件了，去查硬件。

还有一种情况是：总线上一个节点程序跑飞，持续占用总线，其他节点全部“连不上”。这种问题在工业现场很常见，排查办法是把疑似故障节点一个一个从总线上断开，看通信是否恢复。软件上还可以给 CAN 控制器配置 Bus-off 恢复机制，比如中断里检测 CAN 错误状态寄存器，在 Bus-off 后自动重新初始化。我写过一段代码，在 CAN 错误中断里记录错误代码，并做 10 次重试复位，靠这个日志定位过好几个次品节点。

4.2 USB 设备开发理论

STM32 做 USB 设备，比如模拟成键盘、鼠标、串口（CDC），或者自定义 HID，理论框架大概分三层：物理层、协议层和功能层。物理层就是 USB 收发器和 D+/D- 两根差分线；协议层由 USB 外设控制器处理，负责令牌包、数据包、握手包这些东西；功能层才是我们写代码的地方，要处理各种描述符和端点的数据交互。

很多人初次接触 STM32 的 USB 设备库会觉得代码量很大，一堆回调函数不知道从哪里入手。我的建议是：不要一开始追着代码看，先理解描述符。设备描述符告诉主机这个设备是什么，配置描述符告诉主机有几个接口、几个端点，端点描述符告诉主机数据怎么传。只要你能手动写出一份 HID 描述符，基本就掌握 USB 开发的八成了。F103 的 USB 外设最高支持全速 12Mbps，不适合做高速传输，但做 HID 键鼠、虚拟串口、简单的数据采集上报，完全够用。

做 USB 设备还有一个容易踩的坑：供电。USB 插入瞬间会有很大的浪涌电流，如果板子上的 3.3V LDO 压降大或者滤波电容不够，D+ 引脚上的 1.5k 上拉电阻可能还没拉高，主机的复位时序就已经结束了。结果就是电脑提示“无法识别的 USB 设备”。排查这种问题时，不要先怀疑枚举代码，先看看板子单独用外部 5V 供电能不能正常枚举，能的话就说明板载 USB 供电链路有问题。

5. 电机控制、运动控制与界面开发

5.1 步进电机、伺服电机与 FOC 控制

五线四相步进电机是很多入门项目的第一课。它可以用 ULN2003 驱动，控制逻辑就是一个循环给四相绕组依次通电。但“会转”不等于“会用”，步进电机有一个重要特性叫启动频率，超过这个频率直接丢步，速度没上来就开始卡顿。所以我做步进电机加减速时，一般用一个查表法或者公式法生成梯形速度曲线，先低频率启动，再逐渐加速，快到目标位置之前提前减速，这样就不会丢步。

伺服电机走 485 控制，本质上是向伺服驱动器发送位置、速度、力矩指令，并读取编码器反馈。这里最有意思的是，伺服驱动器大多支持标准 Modbus 协议或厂家自定义协议。用 STM32 控制伺服时，我强烈建议先用 PC 上的串口助手把协议的每条指令都跑通，确认 CRC 校验没错，再移植到单片机上。别一上来就写代码调驱动，否则你分不清是通讯问题还是伺服参数没调对。

如果做直流无刷电机的高性能控制，还得懂FOC（磁场定向控制）。FOC 理论的核心是把三相电流通过 Clarke 变换从三相静止坐标系转到两相静止坐标系，再通过 Park 变换转到旋转坐标系，变成一个类似于直流电机的“直轴电流 + 交轴电流”控制模型。刀绪代码网上很多，比如 ST 官方的 MC 库、SimpleFOC，但如果连Clarke和Park变换公式都看不懂，抄代码也改不动。我个人的经验：先在一个仿真环境里把变换公式跑通，再用逻辑分析仪看 PWM 输出，最后再接电机。FOC 涉及的采样时序、死区补偿和电流环带宽，任何一个不当，电机都会啸叫或者震动。

5.2 两轮差速小车与刹车

两轮差速小车是 STM32 控制里很经典的运动模型。它没有转向舵机，靠左右两个轮子的速度差实现转向。理论上的核心是运动学逆解：给定小车目标线速度和角速度，求出左轮和右轮各自的目标速度。公式不复杂，本质就是求两个轮子的平均速度加偏差。但实际调车时会发现，两个电机即使转速指令一样，实际转速也不一样，因为电池电压波动、机械阻力差异、PID 参数不完全对称。这也是为什么必须给每个轮子加编码器做闭环控制，不能开环直行。

再说“刹车”。电机驱动里所谓的刹车，对于直流电机来说就是把电机两端短路，利用反电动势来消耗动能。用 H 桥驱动时，只要把下桥臂两个 MOS 管同时导通，就能实现抱闸效果。但要注意：刹车太猛会让电流瞬间冲击 MOS 管和电源，导致电压跌落甚至复位。我做小车时在刹车前先做一段 PWM 渐变减速，等速度降到一个阈值以下再做短路刹车，效果立刻稳定了很多。如果你用的是步进电机，刹车就简单一些，因为步进电机断电后自带一定保持力矩，除非负载很大，否则不会溜坡。

5.3 显示 GUI 框架的选型

嵌入式 GUI 是很多项目里的“面子工程”。STM32 上常用的 GUI 框架有 LVGL、emWin（STemWin）、TouchGFX 和 LittlevGL 的旧版本。LGVL 是开源免费里口碑最好的，支持各种控件、动画、主题，适合做中等复杂度的界面。但 LVGL 也有一个看不见成本：它需要足够大的 RAM 和 Flash，还要有显存临时缓冲。如果你用 F103C8T6（只有 20KB RAM），最多跑一个 320x240 分辨率、16 位色的简单界面，复杂动画想都不用想。我建议先看芯片 RAM 容量再选 GUI 框架：资源紧张用 u8g2 纯绘图，RAM 比较多才上 LVGL。

还有一条经验：GUI 的帧率瓶颈通常不在屏幕刷新率，而在总线带宽和绘图算法。SPI 刷新全屏，理论上一秒钟能刷十几帧，但如果你每帧都重新绘制大量控件，CPU 根本忙不过来。用 DMA + 显存双缓冲能缓解一部分压力，但小内存芯片根本双缓冲不起来。所以做 GUI 项目时，经常需要牺牲一些视觉效果换取流畅度：减少全屏刷新，改为局部刷新；图标做成单色位图而不是带透明通道的 ARGB；动画帧率降一档。先想清楚约束，再决定界面方案，项目才能顺利交付。

6. 物联网与综合项目

6.1 巴法云与 HTTP 库

物联网项目里，STM32 上云的方案很多，巴法云是国内开发者使用较多的轻量级 IoT 平台，它不要求你烧录一堆 SDK，直接走 HTTP 请求就能上报和下发数据，对 MCU 非常友好。STM32 通过 ESP8266/ESP32 模块联网以后，其实做的事情就两件：一是用 AT 指令控制 Wi-Fi 模块连接路由器和 TCP 服务器；二是把传感器数据拼成 HTTP GET 或 POST 请求发出去。

嵌入式 HTTP 库不一定要用完整的lwIP，很多东西其实可以用简单的字符串拼接。我做过一个智能台灯项目，光照传感器和人体感应模块的数据需要上报到云端，我直接写了一个http_get()函数，把 URL 拼好之后通过串口发给 ESP8266，等它返回+IPD数据就读取响应。这种方式简单可靠，也容易排查。只有当你需要 TLS 加密、HTTPS、MQTT 长连接这些能力时，才有必要引入正式的网络协议栈和云 SDK。

6.2 智能台灯、报站程序与毕业设计

“基于 STM32 的智能台灯”是一个被做烂了但很适合练手的项目。它综合了按键输入、PWM 调光、光敏传感器、人体感应、OLED 显示和可能的蓝牙/ Wi-Fi 控制。在这个项目里能学到的不只是外设操作，还有状态机的设计——台灯的模式切换、自动模式和手动模式的互斥、PWM 渐变亮度的平滑过渡。建议你把它当一个“小微系统”来做，而不是只点个灯。

“报站程序”这类项目，本质上是一个按顺序触发的信息播报系统。它可能用语音模块播放站点名称，用显示屏显示站序，用 GPS 模块定位当前站。听起来不难，但实际做的时候要考虑“当前到站和离站怎么判定”“报站提前量怎么处理”“如果 GPS 信号丢了怎么办”。这种项目最大的价值不是语音模块本身，而是让你学会把多个外设按业务逻辑串起来，并且考虑异常情况。

如果你是在准备毕业设计，我的建议是选题尽量选“能落地、可演示、有完整硬件实物”的方向。纯粹仿真的项目答辩时很难说清楚硬件问题，而一个有实物、能现场演示、还能展示底层调试过程的项目，评委更认可。比如两轮差速小车加微信小程序遥控、智能鱼缸加温控和自动喂食、步进电机云台加视觉追踪，这些都既有理论深度又有可操作性，资源也容易找到。

7. 高频问题与排查技巧实录

7.1 延时函数卡死、ILI9341 的 0xA1A1、AXF 加载错误

延时函数卡死是一个非常经典的问题。最常见的原因是：你的延时函数用的是SysTick的循环等待，但你在某个中断服务函数里也调用了延时函数，导致中断嵌套或者 SysTick 被递归调用。另一个原因是你用了调试器的“暂停”功能，在断点停下来时，SysTick 已经跑完，重新运行后延时置位条件错过，程序就卡在死等里。还有一种隐蔽场景：如果你在低功耗模式下关闭了 SysTick，但某个外设驱动仍然调用HAL_Delay()，也会卡死。排查时先看卡在主函数的哪一行，如果是 delay 内部循环，直接检查 SysTick 配置，以及是否在中断里调用过 delay。

ILI9341 读 ID 是0xA1A1的问题，我在前面的 SPI 部分提过，这里再补充一个排查思路：先用万用表测量屏幕模块的 VCC 和逻辑电压是不是匹配，很多 3.3V 的 TFT 屏接了 5V 电源后虽然能亮，但 SPI 逻辑电平异常，读 ID 就会出错。如果用的是硬件 SPI，试着把波特率降到几百 kHz，有些模块的转换速率很低，高速 SPI 下时序跟不上，读出来的数据就是乱的。最后实在读不出 ID，跳过读 ID，直接发初始化序列，这也是很多厂家例程的做法。

再补充一下那个Load project.axf ... Flash Download failed的报错。这个问题在你用 J-Link 或者 ST-Link 下载时都可能出现。除了前面提到的 Flash 算法和读保护问题，还有一个容易被忽略的原因：芯片的复位引脚上接了电容或者调试器没有正确管理复位信号。调试器在做 Flash 编程时需要拉低复位引脚，如果外部硬件干扰了复位，编程就会失败。解决办法是在 Debug 设置里改连接方式为 “Hardware Reset” 或者 “Connect under Reset”。

7.2 CAN 连不上、芯片第一脚确认与禁用 JTAG

CAN 通信突然连不上的排查，如果你已经检查了终端电阻和波形，还是没解决，就回到代码层面：看看 CAN 是否进入了 Bus-off 状态，读一下ESR寄存器的值。如果是TEC > 255，说明发送错误太多被强制离线。这时候软件上要做“恢复策略”，不能只是重新初始化 CAN，要等待总线空闲一段时间后再恢复。还有一种情况：芯片进入了低功耗模式，CAN 的时钟被关了，恢复后没有重新配置 CAN 外设，表现也是“突然连不上”。

“芯片第一脚怎么确认”这个问题虽然基础，但做硬件时真不能搞错。不同封装的 STM32，引脚 1 的位置标识方式不同。LQFP 封装通常在芯片一角有一个圆形凹点，凹点左下方就是第一脚；QFN 封装会在第一脚位置印一个倾斜的角或者一个特殊标记；BGA 封装在 PCB 封装图上标识得更明确。如果板子已经焊上去了，最稳妥的确认方法是查看芯片表面丝印，再对照数据手册的封装图形，别靠“感觉”。我见过一次板子画错，人家把 LQFP48 的第一脚朝右，结果电源和 GND 全反，上电就冒烟。

还有个实用操作叫禁用 JTAG。有些人想把 PA13、PA14、PA15、PB3、PB4 这些引脚当普通 GPIO 用，却发现怎么配置都不生效。原因是这些引脚在默认情况下被 JTAG/SWD 调试功能占用。你需要在代码开头的初始化里调用一个特殊操作，把 JTAG 关闭而只保留 SWD。标准库做法是：

GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);

但要注意，执行完这一句之后，JTAG 调试就再也连不上了，只能用 SWD 接口。我当时第一次用串口升级程序，在 Bootloader 里禁用了 JTAG，结果调试器连不上，只能用另一个板子把程序重新烧回来。这个操作要放在非常重要的初始化位置，并且确认你还有其他下载接口可用，不然就是给自己挖坑。

写在最后的一点经验

做 STM32 这几年，我最深刻的感受是：外设再多，理论总是那几套，总线、时钟、中断、状态机，真正拉开差距的不是谁的代码写得花哨，而是谁能更快定位问题。比如遇到一个诡异的现象，懂时钟树的人会先算频率有没有配错，懂总线矩阵的人会考虑是不是 DMA 抢带宽，懂启动流程的人会直接查向量表。这些不是靠背例程能学会的，而是靠理解芯片内部的工作原理，再加上反复踩坑、反复看手册积累出来的。

如果你刚开始学，不要急着追新芯片、新工具。把 F103 或者 F407 的系统架构图、时钟树、启动文件这三样东西彻底看明白，再动手做一两个综合项目，远比你会在 CubeMX 里点鼠标值钱得多。遇到问题就记录，把当时的报错、排查步骤、最终原因写下来，慢慢你会发现，常见问题也就那几类。希望这篇能帮你少走一些弯路。