企业官网建设流程全解析

你在VS Code里把代码写完，编译窗口干干净净，没有任何error。你信心满满地把开发板插上USB，结果LED不亮、串口没输出、板子就像一块砖头。这时候你的第一反应是什么？反正我第一次遇到这种局面，足足卡了一天，把代码翻来覆去改了几十遍，最后被同事一句话点醒：你编译的是源码，板子要跑的是固件，固件根本还没进去。

这句话听起来像废话，但真的拦住了很多人。嵌入式MCU开发里，“编译”“烧录”“仿真”这三个词看似是三个按钮，实际上是三条独立的链路。任何一个环节出问题，都会对后面形成连锁反应。编译通过只证明代码语法和链接没错，跟芯片能不能跑、程序有没有进去毫无关系；烧录成功也未必代表程序逻辑正确，那才是仿真和调试该管的事。这篇文章就沿着这条主线展开：编译怎么把源码变成机器码，烧录怎么把机器码写进Flash，仿真又在“真机调试”和“模型验证”之间如何取舍。适合刚接触嵌入式的人通读一遍，也适合那些“我编译没问题但板子不工作”的卡壳朋友拿来对照排查。本文提到的很多坑，我都在STM32、Arduino、ESP32、GD32上实际踩过，处理思路可以直接抄作业。

1. 先搞清楚三件事的关系：编译、烧录、仿真各管哪一段

1.1 一条代码从“写出来”到“跑起来”要经过哪些站

嵌入式MCU和PC开发最大的区别是“目标环境不可见”。在PC上写程序，操作系统帮你把进程加载到内存，CPU立刻就能跑；在MCU上，没有操作系统、没有加载器，代码写完后要自己想办法“搬运”进芯片，还要确保芯片上电后知道从哪里开始执行。

一条完整的旅程是这样的：你在编辑器里写的.c和.h文件，先交给交叉编译器，生成目标芯片架构的机器码；这些机器码被组织成固件文件（通常是.hex或.bin）；烧录工具通过调试器或串口把固件写进芯片内部的Flash；芯片复位后，硬件自动从复位向量指向的地址取第一条指令，启动文件初始化环境，最后跳到main函数；在程序运行过程中，如果你想看变量怎么变化、某个外设寄存器到底置位了没有，就需要调试器或仿真器介入。

“编译、烧录、仿真”这三个词，正好对应这条链路里三段完全不同的工作。编译解决的是“源代码到机器码”的转换问题，烧录解决的是“机器码到非易失存储”的搬运问题，仿真解决的是“程序行为是否符合预期”的验证问题。

1.2 为什么嵌入式开发里，编译、烧录、仿真经常被混为一谈

混为一谈的主要原因是IDE把这三个动作做得“太顺滑”。你在Keil里点一下Download按钮，看起来就是“编译+烧录”一步完成；点一下Start Debug Session，程序自动下载并停在main入口。按钮越顺滑，新手越难感知背后发生了多少事。

还有一个更现实的原因：报错信息互相串门。比如你在Keil里点Download，它先编译，编译失败时报的却是链接错误；编译通过后开始烧录，烧录失败报的可能又是“Cannot access target”。在VS Code里更明显，编译是通过CMake或Makefile调用的交叉编译器，烧录是靠OpenOCD、pyOCD或厂商工具，两边是独立的配置文件。很多人被那句热搜词“vs code里编译成功，却怎么也烧录不进开发板”困住，本质就是没分清这两个环节。

把三个环节分开理解，不是为了理论上的清晰，而是为了排错时能精准定位。编译报错查语法和头文件，烧录失败查驱动和接线，程序跑飞查逻辑和中断，方向对了，解决问题的时间能缩短一大半。

1.3 三个环节的联动关系：模块化流程让排错更容易

我把这三者的关系比作水管工程：编译是制造水管，烧录是把水管接到楼里，仿真是打开水龙头看水流走向。制造的水管质量不行，后面两件事都白干；水管没接上，水流不到龙头；水管接上了但走向设计错了，楼里该用水的房间照样没水。

实际操作中，这三个环节是可以独立验证的。编译环节结束，你能看到编译器生成的map文件，确认固件大小和内存布局；烧录环节结束，你能通过调试器读回芯片的IDCODE，确认芯片真的被识别；仿真环节结束，你能在断点处看到变量和寄存器的实时值。每完成一步就做一次验证，不要等程序跑不起来再倒回去猜，那个排查成本是最高的。

2. 编译环节拆解：源码怎么变成芯片能跑的固件

2.1 交叉编译：在PC上生成MCU的机器码

嵌入式编译有一个反直觉的起点：你用的是PC，但生成的目标代码不是给PC的CPU跑的。x86架构和ARM架构的指令集完全不同，所以要用交叉编译工具链，比如ARM官方提供的arm-none-eabi-gcc。它的运行环境是PC，生成的机器码却是为Cortex-M这类MCU准备的。

一次完整的编译过程分成四个阶段。第一个是预处理，编译器把#include的头文件内容展开、把#define的宏替换掉、处理条件编译指令。第二个是真正的编译，C代码被翻译成汇编代码。第三个是汇编，汇编代码被翻译成目标文件，也就是.o文件，这时候机器码已经成型，但还没有拼成完整的程序。第四个是链接，链接器把多个.o文件、启动文件、标准库组合起来，按照内存布局放入最终的固件。

Keil这类IDE把这些阶段封装成了一个Build按钮，很多人写了几年代码也没见过中间产物。但我建议你至少手动跑一次工具链，哪怕只是用命令行敲一遍arm-none-eabi-gcc -c，亲眼看看.c文件变成.o文件的过程。理解了这四步之后，很多编译报错一看就知道是哪一步出的问题：头文件没找到是预处理阶段，语法错误是编译阶段，符号未定义是链接阶段。

2.2 链接脚本和启动文件：决定程序能不能“落地生根”

MCU的裸机程序有一道PC程序没有的门槛：内存布局必须自己定义。PC程序有操作系统负责分配内存，MCU程序上电后面对的是一个地址连续的Flash和一个独立的SRAM，代码放哪里、变量放哪里、堆栈放哪里，全部要写清楚。

这个“写清楚”的工作由链接脚本完成。STM32F103的工程里，链接脚本会把只读代码段放到0x08000000起始的Flash区域，把数据段和BSS段放到0x20000000起始的SRAM区域。Hex和bin文件里那些看似没规律的地址，其实都来自链接脚本的分布。

另一个关键组件是启动文件start.s，或者说startup文件。上电那一刻，MCU的硬件只负责把复位向量指向的地址取出来执行，之后的事全靠启动文件：初始化堆栈指针、配置中断向量表、把.data段从Flash拷贝到SRAM、把.bss段清零，最后调用系统Init和main函数。

这就像毛坯房。PC程序进驻的是精装办公室，操作系统已经帮你把水电网络都铺好了；MCU裸机程序进的是毛坯房，启动文件就是工长，先拉电拉水、打扫干净，再把钥匙交到main手里。如果你换了芯片或者改了内存布局却不改链接脚本和启动文件，程序大概率上电就跑飞，而且你很难用调试器找到原因。

2.3 编译产物速查：elf、hex、bin、map谁负责干什么

很多新手拿到编译产物一脸懵，搞不清elf、hex、bin、map文件都是干嘛的。我用一张表说清楚：

产物文件 | 格式类型 | 核心用途 | 使用场景 elf | 可执行与链接格式 | 包含完整符号表、调试信息、地址映射 | 调试器读取，用于断点、变量观察 hex | Intel HEX文本 | 按地址记录数据的纯文本格式，带校验和 | 烧录器、串口ISP下载、归档固件 bin | 纯二进制 | 没有任何地址信息，必须烧录到固定起始地址 | Flash烧录、OTA固件打包 map | 链接器输出报告 | 记录每个符号的地址、大小、占用段 | 排查内存溢出、查看Flash/RAM占用

实际使用中有一条很容易被忽略的经验：调试器用elf，量产烧录用bin或hex。有人在网上拷了一个hex文件，用ST-Link烧进去发现跑不起来，很可能就是因为hex里的地址和他的芯片Flash基地址不匹配。Keil里Output选项卡生成的hex通常是从0x08000000开始的，如果你用其他工具改了偏移，烧进去就是另一回事了。

map文件平时不起眼，但在排查“程序进不了main”“变量莫名其妙被篡改”这类问题时，它是第一工具。打开map文件搜变量名，能看到它被分配到了哪个SRAM地址；搜函数名，能看到它被链接到了哪个Flash地址。这些信息是仿真调试时定位问题的基础。

2.4 几个最常见的编译报错，和对应的操作思路

先说热搜词里挂在前面的一条：failed to create module configuration "mcu”。这个问题基本只出现在VS Code的环境里，报错含义是IDE或插件在配置项目时没有识别到MCU型号定义。解决方向很明确：检查.vscode目录下的配置文件，或者CMake/PlatformIO配置里芯片型号参数是否填对。Cortex-M型号写错、拼写多了一个字符，都会触发这个报错。

第二种高频问题是链接阶段报undefined symbol。这类错误里，_exit和_sbrk这类系统接口最迷惑人，根源通常是startup文件和标准库类型不匹配。GCC工具链换版本之后、或者Keil的ARMCC换成AC6编译器之后，这种问题非常常见。处理办法是重新生成与当前工具链匹配的启动文件，或者把标准库换成nano版（Keil里勾选Use MicroLIB，GCC加--specs=nano.specs）。

第三种是cannot find -lxxx，找不到某个静态库。不要急着改代码，先确认这个库是否已经编译、库路径是否加到了链接器搜索路径里。很多人在Windows上用VS Code配GCC工具链时，正斜杠反斜杠混用也会触发这类问题。排查优先级是：库是否存在＞库文件名是否匹配＞路径是否写对。

3. 烧录环节：编译通过却烧不进去，问题到底出在哪

3.1 烧录的本质：擦除、写入、校验三步

烧录不是“把文件复制到U盘”那么随意。Flash不能像SRAM那样按字节随便改写，它要先擦除成全1状态，然后才能写入。所以一次完整的烧录动作，本质上是擦除扇区、写入数据、回读校验三步。

以STM32F103为例，程序烧录地址从0x08000000开始。整个Flash被分成多个扇区，如果固件大小超过了当前扇区容量，烧录工具会自动扩展到后续扇区。这里就引出了两个烧录失败的高频原因：一个是芯片Flash写保护，另一个是烧录地址或算法不匹配。写保护打开后，擦除会失败，工具通常给出一个比较笼统的错误。

上电后芯片会从0x08000000读取复位向量，拿到第一条要执行的指令地址。如果烧录地址不对，或者hex文件本身不是从这个地址开始，芯片就不知道从哪里执行，表现出来就是程序“烧进去了但没反应”。

3.2 主流烧录方式与适用场景

烧录方式选对了，失败率能降一半。常见的几种在下面这张表里：

烧录方式 | 接口 | 典型工具 | 主要用途 | 注意点 SWD | 2线（SWDIO/SWCLK） | ST-Link、J-Link、DAP-Link | 日常调试、程序下载、在线仿真 | 接线少、速度快，推荐首选 JTAG | 4线（TMS/TCK/TDI/TDO） | J-Link、老式仿真器 | 调试口复用复杂时的替代方案 | 占用引脚多，新芯片少用 ISP串口 | UART串口 | 官方ISP工具 | 量产下载、无调试器时救急 | 依赖Boot模式引脚跳线 UART串口 | UART串口 | esptool等 | ESP32、51系列等ROM引导下载 | 需要手动进入下载模式 USB DFU | USB | 厂商DFU工具 | 支持USB引导的MCU | 依赖USB驱动和Boot跳线

SWD是我日常最常用的方式，两根线加上电源地和复位，五根线就能干活。ISP串口适合工厂产线，因为不需要昂贵的调试器，但需要用户先拉高Boot引脚让芯片进入系统引导模式。很多人在Arduino上给Uno板烧引导程序，用的就是ISP方式配合AVR工具链，那是另一条成熟的烧录链路。ESP32走的是UART下载模式，按住BOOT键再上电就能进入下载等待状态，esptool会负责后续的固件写入。

3.3 典型场景复现：VS Code编译成功，为什么烧录不进开发板

复现一个高频问题：VS Code里用PlatformIO或CMake编译一个STM32工程，编译输出干干净净，但“烧录”按钮一按就报错。先说结论：VS Code只是个编辑器，编译靠的是GCC工具链，烧录靠的是OpenOCD或pyOCD这类调试服务程序，两边完全是两套配置。

我遇到过一位读者，编译和烧录用的芯片型号写法不一致。编译配置里写的是STM32F103C8，烧录配置里写的是STM32F103CB，Flash容量从64KB变128KB，算法自然加载错了。OpenOCD能连上芯片，但写入时地址范围计算不对，表现就是“烧录失败”。

另外还有一个特别容易被忽视的接线问题：SWDIO和SWCLK接反了。调试工具能识别到芯片ID却没法和内核正常通信。处理办法：先单独验证连接，用调试器软件读一次芯片IDCODE，能读出来说明物理连接没问题，再去检查算法和地址配置；读不出来，优先查接线、供电、复位引脚三件事。

3.4 Keil5烧录失败：从报错信息反推根因

Keil5烧录失败，几乎每个嵌入式工程师都遇到过。最典型的报错是Flash Download failed - “Cortex-M3”，这个报错真实含义是“成品FLASH算法运行错误”。英文很唬人，实际就是三个原因轮流碰运气：一是Target页里的芯片型号选错，二是Flash Download配置里没加对应芯片的烧录算法，三是芯片Flash被读保护锁住。

逐个来看。芯片型号选错时，IDE加载的Flash算法不匹配，擦除和写入都会失败。Flash算法在Keil里叫Programming Algorithm，STM32F1系列要加载STM32F1xx Flash的算法文件，千万不能拿F4的算法去烧F1芯片。Flash读保护的问题更隐蔽，芯片默认全片擦除时不会提示你是否解除保护，直接拒绝写入。

Keil烧录失败的另一个经典报错是RDDI-DAP Error。RDDI其实就是调试口通信异常，大部分时候是SWD线松动、杜邦线太长或者调试器驱动被别的软件占用。把下载速度从5MHz降到1MHz，问题往往就消失了。还有一个“No Target Connected”的报错，我建议先检查ST-Link的驱动是否安装成功，在设备管理器里看有没有感叹号；其次检查目标板供电，很多人只用调试器供电，板子上外设一多，电流不够，芯片处于欠压状态。

3.5 国产MCU在烧录环节的特殊注意点

最近几年GD32、AT32、CW32这些国产MCU用的人越来越多，它们在引脚和代码上尽量兼容STM32，但在烧录环节有一个坑很明确：Flash算法不通用。Keil自带的STM32 Flash算法不能直接用于GD32F103系列，必须去厂商官网下载对应的PACK包或Flash算法文件，否则会在擦除阶段报错。

其次是有些国产MCU的片内RC振荡器不一定能保证和调试器通信的时序完全一致，如果你用的低速SWD时钟依然偶尔失败，可以考虑换外部晶振或者降低波特率。还有的国产芯片出厂默认打开读保护，第一次烧录前需要先全片擦除或解除保护。不要觉得国产芯片“号称兼容”就跳过官网文档，厂商的烧录手册往往才是真正的使用门槛。

另外，量产阶段用SWD口烧录时，别让测试治具的线缆太长。SWD通信很敏感，有人为了便利把调试器延长了30厘米，下载速度一快就失败。量产产线里稳妥的做法是降速到1MHz，优先保证成功率和稳定性，不要盲目追求下载速度。

4. 仿真环节：软件模型、在线平台和硬件调试点各有什么本事

4.1 “仿真”这个词被用滥了：先分清它到底指哪一层

“仿真”在嵌入式领域是个被用滥的词。有人说的仿真是Proteus画电路跑固件，有人说的仿真是Wokwi网页上看ESP32点灯，有人说的仿真是用ST-Link连真机打断点看变量，还有人说的是Maxwell电机仿真、音频放大器电路仿真、FPGA的UART接收仿真。

这些工作的共同点是“用模型替代真实环境来验证”，但层级完全不同。FPGA仿真、音频放大器仿真属于逻辑或电路级仿真，替代的是芯片行为或电路响应；MCU的在线调试属于硬件级仿真，替代的是你对程序运行过程的“观察力”。如果你看到电机仿真、Simulink联合仿真这类词，那更多是算法级和系统级验证，跟本文讨论的MCU调试不在一个层次。

理解这一点对新手很重要：当你说“我想仿真”时，先问自己到底想验证什么。如果验证LED闪烁延时的逻辑对不对，Wokwi在线仿真就够；如果验证库函数配置是否真的把寄存器写对了，必须用硬件调试器看寄存器的实际值；如果验证MOS管驱动电路的电压波形，那要考虑瞬态电路仿真。工具选错了，问题根本得不到答案。

4.2 在线仿真平台（Wokwi类）的使用价值与局限

Wokwi这类浏览器里的仿真平台，我认真用过，也推荐给过不少朋友。它支持Arduino、ESP32、树莓派Pico等主流板子，能在线搭建面包板电路、接LED、接按键、接传感器，写完代码直接点运行，串口监视器一样能打印数据。对没有硬件、只有电脑的初学者来说，这是成本最低的入门方式。

但你必须知道它的边界。Wokwi仿真的是理想电路，LED点亮电阻直接取固定值，按键按下和释放就是干净的电平跳变，模拟量输入几乎没有噪声。现实中的按键抖动、传感器输出的温漂、电源纹波对ADC采样的影响，在仿真平台上永远复现不出来。

我见过有人用Wokwi调好了一个读取热敏电阻的程序，信心满满转到真机，发现AD值跳得没法看。这不是代码问题，是仿真平台没告诉你电路需要滤波和RC去抖。所以我的建议是把这类在线平台当成“验证思路”的工具，而不是“完成产品”的测试环境。算法逻辑、状态机跳转、时序设计，用它验证效率很高；涉及真实电气特性的功能，尽早转真机调试。

4.3 硬件调试器实操：断点、变量观察、寄存器查看

硬件调试器才是嵌入式仿真的核心工具。以ST-Link加Keil为例，点击Start Debug Session后，程序会被下载并停在main函数第一行。这一时刻，芯片已经被调试器接管，你可以看到当前PC指针指向哪里、SP堆栈指针是多少、各个外设寄存器的初始状态。

第一步是打断点。在代码行号旁边单击，红色圆点出现，点击全速运行，程序会在断点处停下来。这时候右侧的Watch窗口能看到你关心的变量值。如果变量加了static限定或位于优化后的代码里，可能看不到，解决方法是把变量添加到Watch窗口并右键选择二进制显示，或者临时把优化等级调到O0。

第二步是看寄存器。仿真调试最有价值的地方在于外设寄存器窗口。你写了一句GPIOB->ODR |= (1<<1)，到底有没有把PB1拉高，仿真里直接看ODR寄存器的Bit1是0还是1。程序卡在while循环里出不来时，看SysTick控制寄存器、看RCC外设时钟使能寄存器，往往一眼就能找到问题。调试器和仿真器在这里是同一个东西，ST-Link既负责下载也负责在线仿真通信。

第三步是处理跑飞和HardFault。程序跳到了HardFault_Handler里，说明发生了非法的内存访问或者栈溢出。此时不要急着改代码，先在调试器里看栈回溯（Call Stack），它能告诉你跳进HardFault之前最后一次正常执行的函数是哪一层。顺着这个函数往上看，绝大多数时候是数组越界、指针未初始化、或者中断里访问了未使能时钟的外设。

4.4 仿真和真机之间的差距：那些仿真永远复现不了的问题

仿真工具再强大，也只是对现实行为的近似建模。在MCU开发里，有几类问题几乎无法在纯仿真环境里复现，我把它们列出来，希望你能提前有心理准备。

第一是时序误差。仿真里系统时钟是精确的，但真机的晶振有频率误差、内部RC振荡器会随温度漂移。同一个UART程序，仿真里115200波特率和真机跑出来的误差不一样，可能仿真里通信正常，真机上全是乱码。

第二是模拟量的“脏”。仿真的ADC读到的是你设定的电压值，真机读到的叠加了电源纹波、布局耦合、引脚串扰。音频放大、电机电流采样这类对噪声敏感的项目，仿真波形再漂亮，上真机都需要重新调滤波参数。

第三是外部世界的复杂性。WiFi模块的信号强度、蓝牙配对时序、按键抖动的具体毛刺长度、传感器上电时的初始化等待时间，这些在仿真平台里都被简化了。FPGA做UART接收仿真时，激励信号是自己构造的理想帧，真机面对的电平毛刺和波特率偏差范围，仿真激励根本覆盖不到。

所以我在团队里立了一个规矩：仿真只做“逻辑正确性”验证，真机调试做“参数和时序”验证，两者缺一不可。仿真过了，只说明程序思路没问题；仿真没过，也不要立刻怀疑代码——有可能是你的仿真激励自己都没搭对。

5. 一个LED例程走完全流程：从工具链安装到全链路排错

5.1 开发环境怎么选：Keil、GCC还是在线仿真

对于刚入门想跑通全流程的人，我的建议按你的目标分三条路选。第一条是STM32F103C8T6蓝色板加ST-Link V2加Keil MDK，这是最主流、资料最多的组合，你搜任何报错基本都是现成答案。第二条是Arduino UNO加Arduino IDE，完全零门槛，适合第一次接触硬件的人，先把“编译通过不等于程序跑起来”这个感觉建立起来。第三条是手头没有硬件时，用Wokwi这类在线仿真先跑程序结构，再决定要不要投资硬件。

硬件版本我特别推荐ST-Link V2而不是J-Link的仿品，因为ST-Link便宜且稳定，CMSIS-DAP类的免驱调试器也可以，但部分免驱调试器和某些IDE版本有兼容性问题。Keil虽然古老，但对STM32的工程管理、烧录算法、调试体验至今依然很顺滑。VS Code那一套适合已经理解编译和烧录流程的人去折腾，新手直接在两个环境间切换调试器配置，很容易被配置文件劝退。

5.2 LED闪烁工程全流程记录

拿一个最经典的STM32F103C8T6工程做全流程演示。代码核心逻辑是这样的：使能GPIOC外设时钟，配置PC13为推挽输出，然后在while循环里翻转电平，延时一段时间。

关键代码：

#include "stm32f1xx.h" void delay_ms(uint32_t ms) { for (volatile uint32_t i = 0; i < ms * 8000; i++); } int main(void) { RCC->APB2ENR |= RCC_APB2ENR_IOPCEN; GPIOC->CRH &= ~(GPIO_CRH_MODE13 | GPIO_CRH_CNF13); GPIOC->CRH |= GPIO_CRH_MODE13; while (1) { GPIOC->ODR ^= GPIO_ODR_ODR13; delay_ms(500); } }

编译之后打开map文件，你应该能看到Flash占用只有几千字节，SRAM占用只有几十字节，这很正常，因为还没引入重库。接着用ST-Link烧录。接线顺序：SWDIO接DIO、SWCLK接CLK、GND共地、3.3V接电源。在Keil的Flash Download设置里勾选Reset and Run，然后点击下载。如果这一路顺利，蓝色板上的LED应该开始闪烁。

整个过程中你做了三件独立的事：编译生成了目标固件，烧录把固件写进了Flash，运行验证了固件确实在芯片里执行。这三件事全部通过，才算一条完整的“可复现流程”。

5.3 全链路排错顺序：先查电源，再读芯片ID，最后怀疑代码

很多人程序不工作时的第一反应是“代码有问题”，然后花一整天翻代码，其实这是最没效率的排错顺序。正确的顺序是从最靠近硬件的地方往前查。

我先给一张常用排错表：

现象 | 优先排查方向 | 其次排查方向 编译报错 | 代码语法、头文件路径 | 编译器版本、宏定义冲突 编译通过但烧录失败 | 调试器驱动、SWD接线、芯片电源 | Flash算法、芯片型号、写保护 烧录成功但程序无反应 | 目标板供电、启动模式引脚、复位脚 | 晶振起振、.data段拷贝、链接脚本 程序能跑但行为不对 | 仿真断点看变量、寄存器 | 外设时钟、中断配置、延时精度

举例来说，芯片上电后复位引脚没拉高，程序就停在复位状态里，烧录工具能连上芯片但程序不跑。启动模式引脚如果被外部电路拉到了错误电平，芯片会从系统存储器或SRAM启动，你烧在Flash里的程序自然不会被运行。这些问题，查电源、查引脚、查复位，优先级全部高于怀疑代码。

排查时手里一定要有调试器。用调试器读芯片ID是最快判断“芯片是不是活着”的方式，ID能读到，说明供电、时钟、调试口这三件事大概率正常。ID读不到，先把精力放在接线和供电上，不要碰代码。

5.4 让流程更顺的几条小经验

最后分享几条我实际操作里的小经验，都是文档里不太会写的细节。

第一，Keil烧录设置里的Reset and Run一定要勾上。不勾的话，程序烧录完停留在调试状态，你断电再上电程序才会开始跑。很多人以为没烧进去，其实只是没跑。

第二，延时函数尽量用定时器实现，不要用for循环数空指令。仿真时这个延时准不准无所谓，但真机上编译器优化等级一变，循环次数对应的实际时间会差很多。LED闪烁还好，通信时序和电机控制里这种误差极其致命。

第三，调试器的SWD时钟不要贪快。STM32支持很高频率的SWD下载，但杜邦线一长、线材质量差一点，高速下载就失败。把时钟降到1MHz，成功率非常高，下载慢那么一两秒，但一整天心情都顺畅。

第四，遇到HardFault不要慌，先在调试器里看栈回溯，再查中断向量表和外设时钟使能。绝大多数现场崩溃问题，根源不是逻辑写得绕，而是某个外设时钟没打开或者某个中断优先级配置越界。我见过一个看起来很隐蔽的数组越界问题，排查到最后就是定时器中断里访问了一个尚未使能时钟的USART寄存器，行为诡异，但每一步都有迹可循。