STM32仿真这件事，我一直觉得被营销号讲得太玄了：好像不买一块开发板、不接几根杜邦线、不忍受几次烧板，就永远摸不到嵌入式的门槛。但我实际把整个入门流程拆了一遍之后发现，一个纯软件版本的STM32仿真环境，足够把 GPIO、UART、定时器这些最核心的外设一样样跑通。不花钱买板子，不焊电路，不担心接错电源，唯一需要的就是一台电脑和一个能沉下来的下午。下面这篇就是把我在这个过程中踩过的坑、选过的工具、写过的代码、验证过的方法全部摊开讲。

学之前我也怀疑过，仿真软件是不是只能跑个效果，根本练不到寄存器层面。后来实测下来，至少对于入门阶段要掌握的几类外设，仿真环境能把指令执行、中断响应、外设寄存器都真实模拟出来，区别只是没有真实电压和波形。这篇文章特别适合还在犹豫要不要花钱买板子的学生、想转嵌入式但不想一上来就买一堆硬件的朋友，以及已经买了板子但经常把板子烧坏的动手派。文章里出现的代码和操作步骤，我尽量都整理成可以直接复制运行的版本，方便你跟着做。

1. 为什么我建议先用“纯软件”路线入门 STM32

1.1 一个纯软件版本真正解决了什么

传统入门STM32，第一道门槛不是C语言，而是硬件准备。开发板要选型号、调试器要认接口、面包板要分清引脚、杜邦线要一条条插对。我见过太多人死在第一步：板子到手发现下载器不识别，折腾驱动就花了两天；又或者把3.3V接到5V引脚上，板子直接冒烟，几百块打水漂。这些成本不是人人都愿意刚开始就承担的。

纯软件仿真路线把这些问题全部滤掉了。你不需要知道BOOT0怎么拨，不需要区分ST-LINK和J-LINK，也不需要担心驱动冲突。打开工具，写代码，编译，运行，看结果，从头到尾只需要电脑和编译器。这条路径真正解决的是“试错成本归零”这件事——你可以反复修改代码，跑一万次仿真，烧不了任何芯片，也花不了任何额外费用。

更重要的一点是，它让你把注意力放到知识本身。搞懂STM32外设，本质上是搞懂三件事：寄存器列表里每一位的含义、时钟树里各级总线的开关顺序、中断系统的触发和响应流程。这些知识跟你在真板上学到的没有区别。仿真器替你省去的是接线和焊接，不是替你跳过原理。

1.2 仿真和真板之间的差异，提前知道心里有数

我并不是说仿真能百分之百替代真实开发板。入门阶段能做到七八成替代，已经足够让你建立完整的知识框架。差异主要集中在以下方面：

仿真环境里没有真实电流、电压和波形，所以ADC采集精度、通信波形质量、引脚的驱动能力这些电气特性，你体验不到。这意味着涉及模拟信号、电机控制、传感器精确采样的项目，最终还是需要真板验证。

GPIO在仿真里通常只能看逻辑高低电平，真实GPIO的翻转速度、上下拉电阻影响、开漏和推挽的实际区别，虽然初始化代码还是那几行，但你感知不到物理层表现。定时器的计数逻辑通常能正确仿真，但完整的PWM输出到真实电机上的效果无法复现。

库函数层面也有一个隐蔽问题：如果你用的是HAL库，部分HAL代码里包含延时、去抖、校准相关的循环，在仿真器里运行速度跟真实芯片并不完全一致，可能会出现奇怪的时序偏差。这也是我在后面实验里选择直接用寄存器操作的原因之一，除非你对HAL库本身已经足够熟悉。

把心态摆正了再往下走，你就不会因为某个外设在仿真里看不到理想表现而怀疑自己学错了，也不会因为仿真顺利就觉得真板一定没问题。

2. 仿真工具选型：横向对比五种常见方案

2.1 QEMU：最接近 CPU 级指令模拟的方案

QEMU是我对这类问题脑子里最先蹦出来的名字。它是开源的全系统模拟器，支持多种架构，ARM体系里也包含了STM32F4Discovery这种板级模型。它的CPU执行是精确到指令级别的，这意味着你在真板上跑的程序，除了跟物理电气相关的部分，逻辑行为在上面的表现和真芯片基本一致。

用QEMU跑STM32有个非常明显的好处：它不挑宿主操作系统。Linux、macOS、Windows都可以运行，Windows还经常配合WSL使用。加上它默认就是命令行工具，很容易写脚本批量跑测试，非常适合自动化验证固件行为。

坏处也有，它对使用者有一定要求。你得会交叉编译、知道Makefile怎么写、明白链接脚本的作用，还要能理解ELF文件和Binary文件的区别。这些问题后面都会遇到，但如果你本来就是来学STM32的，这些恰恰是迟早要补的基础知识。

2.2 Wokwi：浏览器里即开即用

Wokwi是我后来发现的“低门槛选手”。它做成了网页版，打开浏览器就能选芯片、画电路、写代码、看串口输出，甚至还有逻辑分析仪视图。它支持STM32F103C6这个非常经典的型号，对于学习STM32F1系列的人特别友好。

它的特点是可视化程度极高：芯片引脚旁边可以拖上LED、电阻、按钮，外设状态看得一清二楚。串口监视器可以实时显示发送内容，还能手动输入字符来测试回显逻辑。如果你是第一次接触STM32，用这个工具作为第一步，几乎不会有任何环境安装层面的挫败感。

它还有一点对新手很有帮助：项目可以通过链接直接分享。遇到问题时把链接丢给朋友，对方打开浏览器就能看你的代码和电路，不需要复现环境。这在社区提问场景下非常实用。

2.3 Proteus、Renode 和其他方案的取舍

Proteus是很多老教程里出现过的仿真软件，它主打电路级仿真，可以在原理图里放一颗STM32芯片，周围接上LED、数码管、液晶屏，看起来非常直观。我在早期也尝试过，但最终放弃了。最主要的原因是它的仿真重点在电路拓扑和元器件行为，对芯片外设寄存器模型的覆盖远不如QEMU细致，尤其是中断和串口这类需要时序敏感的功能，表现不稳定。再加上正式版需要付费，安装包也比较臃肿，对于“纯软件学外设”这个目标来说性价比不高。

Renode是一个专注于嵌入式系统仿真的开源工具，它对多芯片系统、传感器网络、自动化测试支持很好，很多做CI测试的团队用它来跑固件回归测试。但单论入门阶段的单芯片外设练习，它的配置成本偏高，文档面向的用户也更偏测试工程师而不是初学者。

另外还有一些厂商自带的模拟器或在线开发平台，功能参差不齐，适合某个特定项目，不太适合作为通用入门工具。我测试下来的结论是：如果只能选两个工具，一个选浏览器里能跑LED和串口的Wokwi，一个选能够精细化验证固件逻辑的QEMU。这两个配合使用，覆盖入门阶段足够。

2.4 我的最终选型组合

我的实际组合是这样的：可视化验证和快速体验用Wokwi，严谨的代码逻辑和自动化验证用QEMU。这样搭配的好处是，新手先用Wokwi把GPIO和UART跑通，建立“原来代码真的能控制硬件”的信心；然后再用QEMU把工程构建、编译、链接、固件加载这一整条更严肃的技术链路补齐。

至于有人问“那我真板还买吗”，我的态度也很明确：如果你能坚持把仿真里的GPIO、UART、定时器、中断这四样东西完整跑通，并且理解了每一条初始化代码的意义，那么你买真板后上手成本极低。反过来，如果你连仿真的基础都过不了，真板只会更劝退。

3. 搭建最小仿真工程：交叉工具链与启动流程

3.1 安装 ARM 交叉编译工具链

STM32的核心是ARM Cortex-M处理器，所以需要在PC上安装针对ARM的交叉编译器。以Ubuntu系统为例，打开终端执行以下命令：

sudo apt update sudo apt install gcc-arm-none-eabi qemu-system-arm make

这套工具里包含了编译、链接、调试所需的完整工具链，qemu-system-arm则是运行ARM系统模拟器的入口。macOS可以用brew安装，Windows建议通过WSL使用Linux环境，或者直接使用ARM官方发布的Windows工具链，并在系统变量里配置好路径。

装完以后，用下面命令验证编译器是否正常：

arm-none-eabi-gcc --version

如果能看到类似“gcc version xxx (Arm GNU Toolchain)”的输出，就说明交叉编译环境已经就绪。注意这里看到的版本和x86桌面编译器不同，因为我们编译出的程序最终是跑在ARM内核上的，不是你电脑的CPU上。

3.2 最小工程需要哪些文件

一个能在QEMU里运行的STM32工程，至少要有三个文件：启动文件、链接脚本、C源码。启动文件负责定义中断向量表、设置栈指针、调用用户main函数，它通常用汇编写成，不同芯片型号的向量表内容稍有差异。链接脚本负责把编译产物放到芯片对应内存地址上，比如Flash从0x08000000开始，RAM从0x20000000开始。

我一开始以为这些文件是STM32初学者不需要碰的东西，直接用集成开发环境点一下就生成好了。但当你切换到纯软件命令行环境后，这些细节反而暴露了出来，而这恰恰是理解芯片启动过程的最佳机会。

一个简化版的启动文件大概长这样：

.syntax unified .cpu cortex-m4 .thumb .section .isr_vector .word 0x20020000 .word Reset_Handler .text .thumb_func .global Reset_Handler Reset_Handler: ldr r0, =0x20000000 mov r1, #1024 mov r2, #0 clear_loop: str r2, [r0], #4 subs r1, r1, #1 bne clear_loop bl main 1: b 1b

对应的最小链接脚本：

ENTRY(Reset_Handler) MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1M RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } SECTIONS { .text : { *(.isr_vector) *(.text*) *(.rodata*) } > FLASH .data : { *(.data*) } > RAM AT> FLASH .bss : { *(.bss*) } > RAM }

如果你的C程序里声明了全局变量，还需要在启动代码里把Flash中的.data数据拷贝到RAM，并清零.bss段。为了保持示例可读性，我在实验代码里尽量避免依赖全局变量，这样最小链路也能正常运行。

3.3 用 QEMU 启动固件的命令

编译完成后，得到的是ELF格式的文件，用QEMU把它加载到模拟的STM32F4Discovery开发板里，执行命令如下：

qemu-system-arm -machine stm32f4discovery -cpu cortex-m4 -nographic -serial mon:stdio -kernel app.elf

参数含义拆开讲：-machine stm32f4discovery指定用哪块板级模型，-cpu cortex-m4指定核心类型，-nographic让QEMU不启动图形窗口，-serial mon:stdio把模拟串口映射到当前终端的标准输入输出，也就是说串口打印会出现在你的终端里，键盘输入也能作为串口输入发给模拟芯片，-kernel app.elf告诉QEMU把哪个固件加载进Flash。

如果运气好，你会在终端里看到程序运行后的输出，或者至少程序不会崩溃。如果没有任何反应，不代表程序没跑，有可能只是代码里没做可见输出。下一节我们会从一个一定能看到现象的GPIO实验说起。

3.4 确认“芯片真的在跑”的三个现象

纯软件环境最让人不安的一点，就是你无法像真板一样靠指示灯判断程序是否活着。我在前三十分钟里也反复怀疑“它到底跑没跑”。后来我总结出三个判定现象：

第一，终端能收到串口输出。这是最可靠的证据，说明CPU执行到了你的初始化代码和打印语句。第二，程序能响应终端输入。如果你写了回显代码，按一个字符能弹回一个字符，说明UART收发链路和中断逻辑都在工作。第三，QEMU窗口里能看到板载LED变化。STM32F4Discovery的模型会显示模拟开发板的运行状态，部分版本的QEMU可通过图形界面观察引脚电平驱动的LED状态。

如果这三种现象都没有，优先检查编译阶段是不是出了问题，比如入口符号没定义、链接脚本指定的地址越界、代码段没有正确放在0x08000000开头。

4. 外设实操：GPIO 点灯实验

4.1 Wokwi 上快速点灯实操流程

GPIO点灯是嵌入式领域里的“Hello World”，我用它来验证第一套完整流程：时钟使能、引脚模式配置、输出电平控制。在Wokwi上新建项目时选择STM32F103C6芯片，然后在芯片的PC13引脚上接一个LED，LED负极接GND，正极通过一个220欧姆电阻连接到PC13即可。有些Wokwi模板里会预置好LED接法，可以直接复用。

Wokwi的好处是所见即所得。在芯片引脚旁边拖拽元器件，连线会自动适配网格，LED正负极也能通过引脚颜色区分。画好电路后，在代码区写入C代码，点击运行，右侧芯片模型的引脚就会以高低电平颜色显示，LED也会变亮和熄灭。

这个过程的体验跟Arduino有点类似，但代码又完全是STM32寄存器操作，对于熟悉了开发环境的同学来说，能够更直观地看到每行代码对应的硬件变化。

PC13的实验代码：

#include <stdint.h> #define RCC_APB2ENR (*(volatile uint32_t *)0x40021018) #define GPIOC_CRH (*(volatile uint32_t *)0x40011004) #define GPIOC_ODR (*(volatile uint32_t *)0x4001100C) static void delay(void) { volatile int i; for (i = 0; i < 200000; i++); } int main(void) { RCC_APB2ENR |= (1 << 4); GPIOC_CRH &= ~(0xF << 20); GPIOC_CRH |= (0x2 << 20); GPIOC_ODR |= (1 << 13); while (1) { GPIOC_ODR ^= (1 << 13); delay(); } }

4.2 GPIO 关键寄存器逐一拆解

这段代码看起来只有几行，背后涉及的知识点却非常密集。第一行RCC_APB2ENR |= (1 << 4)，作用是把GPIOC端口的时钟打开。STM32为了省电，所有外设默认是关闭时钟的，你不开时钟就去改GPIO寄存器，操作无效，这是新手最容易忽略的一步。

第二和第三行配置PC13引脚的工作模式。STM32F103的引脚模式寄存器分为CRL和CRH，CRL管PA0到PA15，CRH管PB和PC的高八位。PC13对应CRH里第20到23位。这里清零四位后设置为0x2，也就是输出模式、推挽输出、最大速度2MHz。不用HAL库时，每一位的作用都必须自己去查手册，这也是纯寄存器操作天然的学习价值所在。

第四行通过ODR寄存器把PC13设为高电平。ODR是输出数据寄存器，写1让引脚输出高，写0让引脚输出低。循环里用异或操作翻转这一位，LED就会交替亮灭。

4.3 把点灯实验延伸到按键输入思路

GPIO除了输出，更重要的是输入。仿真环境里同样可以接一个按钮到某个引脚，然后通过IDR寄存器读取按键电平。按钮一端接引脚，另一端接GND或3.3V，根据你需要按下为高还是按下为低来决定。

输入模式需要配置方向为输入，通常还需要打开内部上拉或下拉电阻，这时候就要用PUPDR寄存器。我建议初学者把输入实验放在点灯之后，因为按键输入设计到滤波、消抖、上下拉这些在真实硬件中很常见的概念。仿真环境虽然没有物理抖动，但你仍然可以通过代码逻辑模拟处理过程，把这个基本功练扎实。

我实际练习时采用的做法是：PA0接按键，PC13接LED，按下按键点亮LED，松开熄灭。整段代码可以基于上面的GPIO操作扩展，多配置一个输入引脚即可。

4.4 无板条件下怎么确认实验成功

由于仿真器不向你显示物理电压，确认实验结果主要看两个信号：芯片模型引脚的颜色变化，以及串口打印的状态信息。在Wokwi里，每个引脚旁边会显示当前电平颜色，你可以很清晰看到PC13在高低电平间翻转。

更好的做法是在切换LED状态的同时，通过UART打印一条日志，比如“LED ON”或者“LED OFF”。这样就把GPIO和UART两个实验串联起来了，也为下一步串口实战做了铺垫。在纯软件环境下，这种“外设联动”的思路非常重要，它让你对芯片内部工作的理解更立体。

5. 外设实操：UART 串口通信

5.1 为什么把 UART 作为第二个必学外设

UART是单片机通信的基石，调试代码时往串口打印数据，是嵌入式开发里最常用的调试手段。很多同学在真板上调试时，会对串口初始化里的各种参数感到头大，因为一旦配置错误，屏幕上要么没有输出，要么输出乱码。在仿真环境里测试UART，避开了硬件电平匹配和USB转串口驱动的问题，能更快聚焦到寄存器配置本身。

更重要的是，串口是一个“双向”外设。它既能发送，也能接收。你能在Wokwi的串口监视器里主动输入文字，观察芯片如何响应。这个交互过程非常直观，可以帮助建立嵌入式系统里“CPU与外设之间数据收发”的直觉。

5.2 串口初始化参数与波特率计算

初始化UART之前，第一步还是开时钟，这里用到的是RCC_APB2ENR里的USART1使能位。然后要设置波特率寄存器BRR。BRR的取值取决于芯片时钟频率和目标波特率，公式是USARTDIV = 时钟频率 / (16 * 波特率)，写入BRR时还要处理小数部分。

Wokwi的STM32F103默认系统时钟是8MHz，我设置的目标波特率是115200，那么计算结果是8000000 / (16 * 115200) ≈ 4.34，整数部分写入BRR的低16位，小数部分再按二进制规则转换。实际写入时可以简化为直接取整数部分再稍作调整。为方便示例，代码里我使用USART_BRR = 69，对应整数分频值，此时实际波特率会比115200略有偏差，但在8位数据帧下通信仍然可靠。

串口控制寄存器CR1里有三个关键位：UE位使能串口，TE位使能发送，RE位使能接收。因此初始化的最后一步就是把这些位全部置1，串口便处于可收发状态。

5.3 串口回显示例代码

在Wokwi中，USART1已经连接到串口监视器。代码实现一个简单的回显逻辑：芯片把收到的每一个字符原样返回。这样做的好处是，你可以在串口监视器输入一个字符，立刻看到它被返回，从而确认真个收发链路是通的。

#include <stdint.h> #define RCC_APB2ENR (*(volatile uint32_t *)0x40021018) #define USART1_BASE 0x40013800 #define USART_SR (*(volatile uint32_t *)(USART1_BASE + 0x00)) #define USART_DR (*(volatile uint32_t *)(USART1_BASE + 0x04)) #define USART_BRR (*(volatile uint32_t *)(USART1_BASE + 0x08)) #define USART_CR1 (*(volatile uint32_t *)(USART1_BASE + 0x0C)) void usart_putc(char c) { while (!(USART_SR & (1 << 7))); USART_DR = c; } void usart_puts(const char *s) { while (*s) { usart_putc(*s++); } } char usart_getc(void) { while (!(USART_SR & (1 << 5))); return (char)USART_DR; } int main(void) { RCC_APB2ENR |= (1 << 14); USART_BRR = 69; USART_CR1 = (1 << 13) | (1 << 3) | (1 << 2); usart_puts("STM32 UART Echo Ready\r\n"); while (1) { usart_putc(usart_getc()); } }

发送时等待的状态标志位是TXE，收发数据寄存器空标志，对应USART_SR的bit7；接收时等待的是RXNE，数据寄存器非空标志，对应bit5。理解这两个标志的等待过程，比背代码重要得多，因为后续所有轮询式外设通信都是这个套路。

5.4 无板条件下的通信调试技巧

在纯软件环境下调试串口，我通常会先做一个最小测试：只发送固定字符串，不接收任何输入。如果终端能看到字符串，说明时钟配置、BRR设置、发送路径都是对的。然后再加入接收逻辑。

如果你用QEMU做串口实验，这个最小测试更有价值。QEMU的-serial mon:stdio可以把串口映射到终端，程序里打印一句Hello，终端就能直接看到。我建议把这一步作为QEMU环境是否跑通冒烟测试标准，比任何LED闪烁都有说服力。

仿真环境里，你还可以用类似-serial telnet:localhost:1234,server,nowait的参数把串口映射成一个Telnet端口，这样不止当前终端，其它终端工具也能连接进去收发数据，对于模拟“客户端连接设备”的场景非常方便。后来我用这个特性做过一次简单的远程交互测试，体验跟真板接USB-TTL很接近。

6. 外设实操：定时器与中断

6.1 定时器外设的要点

定时器是STM32外设体系里非常核心的部分。它的本质是一个计数器，在时钟脉冲的驱动下不断递增或递减，当计数值达到预设值时产生溢出事件。定时器还可以级联分频器，把输入的系统时钟先分频再计数，从而实现对毫秒甚至微秒级时间的控制。

我练习时用的是TIM2，因为它挂在APB1总线上，在STM32F103上地址是0x40000000附近，非常规律。要让它工作，第一步是打开RCC_APB1ENR里对应的时钟位，然后设置预分频器寄存器PSC和自动重转载寄存器ARR。PSC决定计数频率，ARR决定计数周期，两者组合起来就得到了所需的时间基准。

比如系统时钟8MHz，设置PSC为999，实际计数频率变为8kHz，每个计数周期是0.125毫秒。再把ARR设为7999，计数到8000次后溢出，溢出周期正好是1秒。这样配置的方式非常灵活，这种“分频加大周期”的思路，理解之后整个定时器章节都通了大半。

6.2 定时器轮询实验代码

仿真环境下我做了这样一个实验：用TIM2控制一个变量在串口里输出计数值，每秒钟打印一次。这样可以非常直观地验证定时器是否按照预期溢出。

#include <stdint.h> #define RCC_APB1ENR (*(volatile uint32_t *)0x4002101C) #define TIM2_BASE 0x40000000 #define TIM2_CR1 (*(volatile uint32_t *)(TIM2_BASE + 0x00)) #define TIM2_SR (*(volatile uint32_t *)(TIM2_BASE + 0x10)) #define TIM2_PSC (*(volatile uint32_t *)(TIM2_BASE + 0x28)) #define TIM2_ARR (*(volatile uint32_t *)(TIM2_BASE + 0x2C)) extern void usart_puts(const char *s); extern char buffer[32]; int main(void) { RCC_APB1ENR |= 1; TIM2_PSC = 999; TIM2_ARR = 7999; TIM2_CR1 = 1; while (1) { if (TIM2_SR & 1) { TIM2_SR &= ~1; usart_puts("1 second elapsed.\r\n"); } } }

这里用轮询方式检查TIM2_SR里的UIF更新标志位。每次溢出该位会被硬件置1，软件读取后必须手动清零，否则会一直触发，这也是一个典型的嵌入式坑：状态标志位读完之后要主动清理。代码里的usart_puts沿用上一节UART实验里的函数，把定时器实验和串口实验巧妙地结合在了一起。

6.3 从轮询走向中断：向量表与启动文件注意事项

轮询方式虽然简单，但主程序要一直等待，很多事情没法同时做。实际工程里更常用的是定时器中断：溢出时自动跳转到中断服务函数，执行完再返回主循环。要在仿真里做定时器中断，关键在于中断向量表。

STM32向量表是Flash起始位置存放的一张函数指针表，每个外设中断对应一个固定偏移。TIM2的中断编号是28，如果你自己写启动文件，需要在启动汇编里把对应的.word占位符替换成TIM2_IRQHandler的地址。如果向量表里没有这个入口，中断一触发，CPU就会跳到随机地址，常常直接HardFault。

这个问题的排查特别折磨人，因为启动汇编是别人模板里的，很少有人会逐行检查里面是否有28号中断的项。我在第一次做定时器中断实验时就卡在这里，现象表现为：程序能编译、能运行、定时器也初始化了，但中断服务函数就是不执行。最后对照数据手册看了一遍向量表才发现问题。

推荐的做法是：如果不想从头写汇编，直接使用标准CMSIS启动文件，在这个文件基础上通过宏定义声明中断函数，然后在C代码里定义同名函数，链接器会自动填入正确地址。这种方式既省心又保留了对向量表机制的理解空间。

6.4 在仿真里验证中断行为的具体步骤

即便向量表配置正确，你也很难通过肉眼确认中断到底有没有响应。我通常的做法是在中断服务函数里翻转一个GPIO或打印一条串口日志，然后在主循环里做另一件事，观察两者是否互不影响。

比如主循环不断发送“Main Loop Running”，TIM2中断每秒钟插入一条“IRQ Triggered”。如果串口输出里两条消息交替出现，就说明中断嵌套和主循环切换都正常。这个实验在纯软件环境里做尤其有价值，因为中断现场保护、栈帧压栈这些底层行为，仿真器能真实执行，你会看到和理解得更透彻。

如果中断一直不触发，除了向量表，还要检查NVIC里对应中断源是否被使能。STM32里即使外设中断标记置了位，NVIC没有使能该中断通道，中断也不会送达CPU。这一步也是初学者最容易漏掉的一环。真板和仿真里这一行为完全一致，所以在仿真中解决了，真板上大概率也不会再踩。

7. 常见问题与排查清单

7.1 程序编译通过但运行没现象

这个问题排在遇到频率榜第一名。现象明明是代码编译没有报错，QEMU或Wokwi却没有打印任何东西。先检查链接脚本是不是把Flash地址设置成了0，而不是0x08000000。很多裸机程序的启动路径第一步就是去取向量表，地址错误直接导致无法启动。

然后再检查代码里有没有开外设时钟。STM32外设默认是不供电的，不开时钟直接初始化外设寄存器，程序能“跑”，但外设完全不动。最后确认输出外设是否真的连接到了对应引脚或串口通道。仿真环境里画了LED却不接引脚，代码再对也不会有点灯效果。

7.2 编译链接阶段反复报错

最常见错误是找不到Reset_Handler或重复定义。如果你用了我上面的启动汇编，同时又在C代码里写了一个同名入口函数，就会重复。解决方法是明确只保留一个入口。另一个错误是来自链接脚本的region FLASH overflowed，说明代码或数据超过了Flash容量。这是芯片选型时最容易忽视的问题，真板上Flash不足也会这样。

第三方库移植时如果报错undefined reference to _exit或者system_init，通常是库文件里包含了一些依赖操作系统或标准库的符号。裸机环境下加入-nostdlib编译选项，一般能屏蔽大多数无关符号。

7.3 串口收到乱码或没有回应

先说乱码：基本是波特率不匹配，检查BRR值和你的终端工具设置是否一致。在Wokwi里默认串口监视器会自动使用代码初始化时设置的波特率，但在QEMU里你通常需要手动确认终端参数，比如stty -F /dev/ttyS0 115200。

没有回应则要分两步查：先用TXE标志轮询发送固定字符串，确认发送方向没问题；再检查接收引脚是否配置正确，中断环境下还要确认RXNE中断有没有在NVIC里开启。

7.4 仿真结果和真实板子的差异对照

这些差异不是错误，是你将来切换到真板前的心理准备。仿真环境的时间基准通常基于软件模拟，循环延时的实际时长与真板不同，所以以毫秒为单位的延时，在真板上要重新校准。

GPIO的IO翻转速度在仿真中不受负载影响，但在真板上接电容性负载时，翻转过快可能导致输出波形劣化。ADC的转换结果在仿真中完全符合理论值，真实采集存在噪声和参考电压偏差。学会把这些差异纳入考虑，你就真正具备了嵌入式工程师的调试思维。

我个人的体会是，STM32仿真这条路的最大收益不是“省下买板子的钱”，而是它逼着我在没有任何辅助提示的情况下，把寄存器、时钟、中断、向量表这些最底层的东西一个个查明白。以前用IDE点几下生成的工程模板，我从来不去看启动文件和链接脚本，现在反过来，反而把之前最含糊的认识全部补上了。

最后再分享一个小技巧：每个外设实验跑通后，不要急着往下走，先把代码回编译成release版本，然后再把优化级别从-O0改成-O2，看看行为会不会变。很多在真板上才会暴露的未定义行为问题，提前能在仿真里暴露，这对以后写工程级固件非常有帮助。后续如果你想扩展这套纯软件方案，还可以把编写好的固件接到自动化测试脚本里，用QEMU做每次提交后的冒烟测试，那又是另一层玩法了。