Keil软件仿真调STM32：Use Simulator配置与逻辑验证

1. 先把话说清楚：Keil 的软件仿真到底在仿真什么

我见过太多人，Keil 装了、芯片包也装了，代码能编译能下载，但从来没点开过那个 Simulator 选项。其实 Keil 的软件仿真功能一直都在，位置也不隐蔽，就在Options for Target -> Debug里，把右上角的调试器从 J-LINK / ULINK / ST-Link 切成Use Simulator，你就进入了另一套完全不同的世界——这里没有板子、没有杜邦线、没有烧录器，代码在一个由调试器 DLL 搭建出来的虚拟内核里跑。

这件事最有价值的地方在于：它把"写代码"和"验证代码"之间的成本降到了几乎为零。板子不在手边、芯片还没到货、板子被上一个项目焊坏了、手上只有一台笔记本在高铁上，这些场景下软件仿真都能直接开工。尤其是刚开始学 STM32、C51、GD32 这类芯片的朋友，手里只有一块板子，烧一次等半天，程序跑飞了只能靠猜，这时候仿真就能把你从"盲调"里捞出来。

我自己的使用习惯是：逻辑层面的问题（算法、状态机、协议解析、数据结构）优先在仿真里解决，电气层面的问题（时序、噪声、驱动能力、通信电平）老老实实上板子。分清楚这两条边界，仿真就是利器；分不清，就会在模拟器里反复怀疑人生。

1.1 模拟器里跑的是你的代码，不是你的板子

这一点必须先讲透，不然后面全是误解。Keil 的 Simulator 本质是调试器 DLL（比如 Cortex-M 常见的是DARMSTM.DLL，8051 是DP51.DLL）配合 PC 上的一个指令级模型，它把你的机器码一条条解释执行，维护虚拟的寄存器组、内存空间、NVIC、SysTick 这些东西。你的GPIOA->ODR = 0x01;这条语句会被老老实实执行，写进一个虚拟地址里，但这个地址背后不会真的有一根引脚电压翻转。

所以判断一个功能能不能靠仿真验证，问自己一句话就够了：这个功能的结果，是由代码逻辑决定的，还是由物理世界决定的？前者比如"PID 计算出来的占空比数值对不对""CRC 校验算得对不对""状态机在第三个包的时候该不该回 ACK"，这些都在仿真里看得一清二楚。后者比如"I2C 上拉电阻够不够""SPI 时钟跑到 30MHz 波形还方不方""外部中断的抖动有没有消掉"，仿真给不了你答案。

顺带说一句，Keil 对 8051 系列的外设建模比 Cortex-M 完整得多。8051 工程里你可以直接观察P0、P1、TMOD、SBUF，甚至能模拟串口收发的时序；而 Cortex-M 这边，除了内核、NVIC、SysTick 这些"原厂自带"的模块比较靠谱，各家厂商的外设寄存器模型基本是缺的。指望在模拟器里看 STM32 的 GPIO 波形，多半会失望。

1.2 什么活适合丢给它，什么活别指望它

把场景列清楚，用起来才不纠结。我按自己的实际经验分了三类：

强烈推荐在仿真里做的：

• 纯算法验证：滤波、PID、坐标变换、编码解码、校验算法。这类代码本来就不依赖硬件，仿真里跑通了基本就等于上板通了。
• 状态机与流程逻辑：按键扫描状态机、菜单切换、通信协议的分包与重传。
• 中断与 RTOS 调度逻辑：Cortex-M 的模拟器对 NVIC 和 SysTick 是有模型的，FreeRTOS 移植完之后可以在仿真里看任务到底有没有切起来、优先级是不是配错。这个我实测过，能跑，只是节奏比真板子慢得多。
• 指针、数组越界这类内存错误：配合 Memory 窗口和 Watch 窗口，比在板子上用串口打印快十倍。

可以试，但别全信模拟器结果的：

• 定时器精确定时：模拟器的时间基准和真实时钟源不是一回事，算出来的延时只能看数量级。
• 通信外设的时序细节：UART、I2C、SPI 的波形细节仿真里看不真实。
• 低功耗相关：睡眠、停机模式的电流行为仿真不出来。

完全别在仿真里浪费时间的：

• 需要外部器件的任何交互：传感器读数、外部 ADC、屏幕。
• 硬件初始化失败类的"玄学问题"：比如某个芯片必须延时 100ms 才能配置寄存器，仿真里这个坑不会复现，上板才会爆。

1.3 仿真与在线调试的取舍对照表

我把两者的差别整理成一张表，方便你决定什么时候切换：

看完这张表，结论就很清楚了：仿真不是"低配版在线调试"，它是另一个定位的工具，主战场在代码还没上板的那段时间。

2. 开工前的环境准备：把工程配成"能仿真"的样子

大部分"仿真跑不起来"的抱怨，最后追下去都是在配置这一步欠了账。Keil 的仿真开关藏在两级菜单里，而且它跟编译选项、调试选项之间有几处强耦合，一处没配对，现象就千奇百怪。我把配置流程拆成几步，按顺序走一遍，基本不会漏。

先说版本的事。MDK 有商业版，也有官方提供的社区版本（MDK-Community），C51 也是独立的工具链。请走正规渠道获取和授权，别在这一步给自己找麻烦。版本号本身对仿真功能影响不大，MDK 5.x 系列的操作路径基本一致，只是菜单文字偶有微调。

2.1 器件选型、Xtal 与时钟基准

打开Options for Target，第一个Device选项卡里选器件。这个选择不只是为了头文件，它也决定了调试器 DLL 的默认参数。比如你选 STM32F103RC，Keil 会自动把Dialog DLL填成DARMSTM.DLL、Parameter填成-pSTM32F103RC，这串参数就是告诉模拟器"按这个型号来建模"。

然后是Target选项卡里的Xtal(MHz)。这个值在仿真模式下会影响调试器的时间换算基准，你设成 8MHz，它按 8MHz 折算；设成 72MHz，它按 72MHz 折算。所以如果你打算用仿真去观察延时函数的耗时，必须让这里的值和代码里实际配置的系统时钟保持一致，否则算出来的时间是自欺欺人。

注意：改完 Xtal 之后，建议重新编译一次并重启调试会话（先 Stop 再 Start Debug）。我在实际使用中发现，某些版本下只改 Xtal 不重启调试，逻辑分析仪的时间轴还是按旧值显示。

还有一个容易忽略的点：如果你在工程里用到了外部晶振才能跑起来的初始化代码，仿真时它会卡在while(HSE 就绪等待)里。解决办法是在调试模式下，用 Command 窗口手动把那个标志位改掉，或者干脆用宏把这段等待跳过去。

2.2 Target 选项卡里必须确认的四个参数

除了 Xtal，Target页还有几个跟仿真强相关的开关，我逐个说下我的设置习惯：

• Use MicroLIB：如果代码里用了printf，勾上它能让标准库更精简，仿真时也少踩一些半主机相关的坑。不用 printf 的话勾不勾都行。
• Read/Only Memory Areas、Read/Write Memory Areas：这两个是给链接器用的，仿真时它们决定代码被放到哪，一般保持默认的 ROM/RAM 划分即可，不用动。
• Operating system：如果你是裸机工程就保持默认；跑 FreeRTOS 的话这里可以留空，因为 RTOS 的调度器是编译进代码的，不靠这个选项。
• Output 页的 Create HEX File：仿真调试不需要 HEX，但如果你还要顺手拿去烧板子，勾上无妨。

这里我特别想提醒一句：不要为了"让仿真能跑"去乱改内存映射。曾经有同事为了绕开一个访问越权报错，把 RAM 起始地址改了，结果真板子上跑到一半就 HardFault，查了整整两天。内存布局这种东西，仿真和实物必须一致。

2.3 Debug 选项卡：把调试器切成 Simulator

这是最关键的一步，也是"跑不起来"最常见的病根。打开Options for Target -> Debug，右上角有个下拉框，列出的是你装的各家调试器。要点两件事：

第一，把下拉框切成Use Simulator。切完之后，左边的Load Application at Startup和Run to main()要勾上。前者决定调试会话启动时是否把编译产物加载进模拟器，不勾的话你进去看到的是一堆 0；后者决定是否自动跑到 main 函数停下来，不勾的话程序会停在启动文件的复位向量处，新手一看就懵。

第二，上面那排Use: XXX Debugger是给在线调试用的，跟仿真无关。所以当你看到报错No ULINK Device found的时候，十有八九是左侧选错了调试器、或者下拉框还停在硬件调试器上。这个报错的含义很直白：你现在选了硬件调试通道，但电脑上没插那个品牌的调试器。

至于Use Simulator下方的Dialog DLL和Parameter，通常 Keil 会按 Device 自动填好，不要手痒去改。只有在极少数情况下（比如你用了很冷门的芯片、自动填的参数不对），才需要手动补。改错了的典型现象是：能进调试界面，但一运行就报内存访问错误，或者外设寄存器全是 0。

2.4 编译产物的加载与 Run to main 的配合

配置完还有一个隐藏条件：工程必须先编译成功，模拟器才有东西可跑。如果Build Output里还有 Error，你点 Start Debug 会直接弹一个"程序未编译"的提示。这一点听起来废话，但我在论坛上见过不少人反复检查 Debug 设置，就是没看编译窗口里那几行红色的error: #20。

另外，如果你改了代码但没重新编译就点调试，模拟器跑的仍是上一次的旧镜像。这个坑在"我明明改了代码，为什么断点停的位置不对"这类现象里占了相当比例。我的习惯是：进入调试前先按一次F7（Build），看到0 Error(s)再按Ctrl+F5（Start/Stop Debug Session）。

3. 从零跑通第一个软件仿真（以 STM32F103 为例）

光说配置太干，我带你走一遍完整流程。这一段用 STM32F103C8T6 做个最小例子，目标是：在完全没有硬件的情况下，让一个 LED 闪烁逻辑跑起来，并且用逻辑分析仪把波形画出来。

3.1 建一个最小工程

我建议新手先用寄存器版本，别一上来就上 HAL。原因很实在：HAL 库里有大量依赖 SysTick 和硬件状态的初始化代码，仿真时会卡在等待标志位上；而寄存器版只需要几行，逻辑清晰，适合观察。

工程结构大致是：启动文件、一个main.c、一段简单的延时函数。代码核心就三个动作——开 GPIO 时钟、配 GPIO 为推挽输出、在 while(1) 里翻转电平。

#include "stm32f10x.h" static volatile uint32_t g_tick = 0; static volatile uint8_t g_led_state = 0; void delay_loop(volatile uint32_t n) { while (n--) { __NOP(); } } int main(void) { /* 使能 GPIOC 时钟 */ RCC->APB2ENR |= (1 << 4); /* PC13 推挽输出，50MHz */ GPIOC->CRH &= ~(0xF << 20); GPIOC->CRH |= (0x3 << 20); while (1) { GPIOC->ODR ^= (1 << 13); g_led_state ^= 1; g_tick++; delay_loop(2000); } }

这段代码里我特意加了两个全局变量g_led_state和g_tick，后面逻辑分析仪要用。用变量去"代表"硬件状态，是仿真调试的一个核心思路——既然模拟器看不到真实引脚，那就让变量跟着引脚一起翻，看变量就等于看引脚。

3.2 进入调试界面后的第一分钟该看什么

按下Ctrl+F5进入调试，你会看到一个跟平时不太一样的 Keil 界面：多了几排窗口，左侧是寄存器组，中间是反汇编或源码，右下角默认是 Memory 窗口。第一分钟别急着点运行，按这个顺序扫一眼：

第一，看左下角的Registers窗口。如果PC停在一个像是启动文件里的地址（通常在 0x0800_00xx 附近），说明Run to main()没生效，或者工程里没勾。手动按几次F5也能跑进来。

第二，看左上角的Disassembly窗口是不是正常显示反汇编。如果全是0x0000或者一片???，说明镜像没加载成功，回去检查Load Application at Startup有没有勾。

第三，看Command窗口（View -> Command Window）有没有报错。这个窗口是仿真调试的诊断中心，很多隐性错误只在这里显示。比如下面这类报错就很典型：

*** error 65: access violation at 0x40021000 : no 'read' permission

它的意思是：你的代码访问了 0x40021000（STM32 的 RCC 寄存器区），但模拟器的内存映射里这块地址没有读权限。这不是你代码的错，是模拟器没给这块外设地址建模型。解决办法要么是在 Memory Map 里放开权限，要么是把这段访问临时跳过，具体的放到第 5 章细说。

3.3 断点、单步与变量观察的实操

确认环境正常之后，开始干活。我一般先用两种断点：一是在main的第一行打一个，确认入口没问题；二是在while(1)循环体里打一个，方便观察每一次循环。

打断点的方法很直接：在源码左侧灰色边条上点一下，出现红点即可。然后在Watch 1窗口里输入三个表达式：g_tick、g_led_state、GPIOC->ODR。前两个是普通变量，第三个是外设寄存器表达式，Keil 的 Watch 窗口支持这种写法，能不能读到值取决于模拟器有没有这块地址的模型。

按F5（Run）之后，程序会停在断点处。此时按F10（Step Over）一行行往下走，你会看到g_tick每次循环加一、g_led_state在 0 和 1 之间翻。这就是逻辑层面上"LED 在闪烁"的证据。

提示：F11（Step Into）会进入函数内部，遇到库函数会一路跳进汇编，初学者容易被绕晕。观察循环逻辑时优先用F10。

这里有个小技巧：把delay_loop的参数从 2000 先改成 20。原因很简单——模拟器是逐条解释指令的，一条 NOP 就是一条指令，2000 次空转在 PC 上要等一小会儿，而你调试的时候要反复单步，每次都等一遍会非常痛苦。等逻辑跑通了，再把参数调回真实值。

3.4 用逻辑分析仪看波形：signal 命令与手动添加

这是软件仿真里最有"科技感"的一个功能。打开View -> Analysis Windows -> Logic Analyzer，会弹出一个波形窗口。接下来两种方式把信号加进去：

方式一，手动添加。点窗口左上角的Setup，在弹出的对话框里点New，输入你要观察的表达式，比如g_led_state，或者外设位GPIOC->ODR & 0x2000。确定之后回到主界面，按F5全速跑几秒，再按停止，波形就出来了。

方式二，用 Command 窗口的命令行。在 Command 窗口里输入：

signal g_led_state signal g_tick

较新的 MDK 版本支持这条命令，直接把信号挂到逻辑分析仪上，比点菜单快。

波形出来之后，你可以用鼠标滚轮缩放时间轴，看翻转周期。注意，这里的时间刻度是根据 Xtal 折算出来的，只能看相对关系，不能当成真实时间。我一般用它来确认三件事：周期是不是大致对称、有没有卡在某个状态不翻转、两个信号之间的先后顺序对不对。

如果你非要观察真实的外设引脚，可以试试在 Setup 里输入PORTC.13这类端口写法。但前面说过，Cortex-M 的外设模型普遍不全，输入之后很可能得到一个永远不变的低电平。遇到这种情况别怀疑代码，就是模拟器没建这个模型，回到变量观察这条路子上来。

4. 把仿真用出硬件调试的效果：几个进阶玩法

基础流程跑通之后，真正拉开效率差距的是这几个技巧。它们解决的都是"断了半天看不出来"的问题。

4.1 结构体、数组、指针在 Watch 窗口里怎么看

这是被问得最多的一个问题，我单独讲透。Watch 窗口支持三种层次的写法：

• 看整个结构体：直接输入变量名，比如g_dev。变量名前面会出现一个小加号，点开就是成员列表。注意，如果结构体里的成员是数组或者嵌套结构体，可以继续往下展开。
• 只看某个成员：输入g_dev.status、g_dev.buf[0]。这种写法在成员特别多的时候很省事，尤其是你想盯着一个状态字段看它什么时候变。
• 看指针指向的内容：输入*p_dev、p_buf[3]。指针本身的值（地址）会显示在变量名后面，展开的是它指向的内容。

如果 Watch 窗口里显示的是<not in scope>，说明这个变量的作用域不对——要么是它还没被定义（程序还没执行到声明处），要么是被编译器优化掉了。后者是新手常踩的坑：Debug 模式下务必把优化等级降到-O0，在Options for Target -> C/C++里把Optimization设成Level 0。优化等级一高，编译器会把变量塞进寄存器，甚至直接删掉，Watch 窗口自然找不到它。

数组的观察有个小限制：Watch 窗口通常只显示前若干元素。想看更多，就在 Memory 窗口里输入数组名，然后用Long或者Byte格式去看一整片内存。这里有个前提——数组在内存里得是连续的，指针数组就不好这么看了。

4.2 堆栈与调用关系：Call Stack + Locals 与 MSP/PSP 的观察

程序跑飞了，最常见的原因就是栈溢出或者野指针。仿真模式下查这类问题比在板子上方便得多，因为你能直接看到栈指针和调用链。

打开View -> Call Stack Window，这里会按层级列出当前的函数调用关系，从上到下就是从最外层到最内层。配合Locals窗口，你能看到每一层函数的局部变量值。如果某个函数的局部变量显示成一堆乱码，八成是栈被踩了。

想看栈指针，去Registers窗口里找MSP（主栈指针）和PSP（进程栈指针）。裸机程序一般用 MSP；跑 RTOS 的时候，任务里用的是 PSP，MSP 留给中断。你可以先把 MSP 的当前值记下来，然后按F10走几行，再看它的变化量，就能估算出当前函数大概用了多少栈空间。

真正有用的招数是：在栈底附近埋"哨兵值"。比如你的栈是0x2000_5000到0x2000_6000，可以在初始化时把这片内存整片填成0xDEADBEEF，然后在 Memory 窗口里观察哨兵值有没有被改写。被改写了就是栈溢出实锤。这套做法在仿真里操作起来特别顺手，因为 Memory 窗口可以直接改内存内容。

4.3 用条件断点和 Command 窗口做半自动测试

有些 bug 要循环几百上千次才出现一次，靠手动单步根本不现实。这时候条件断点就是救命的。

在断点上右键，选Breakpoint Properties（或者双击断点），能看到几个属性页：

• Condition：填一个表达式，比如g_tick == 500，只有在表达式为真的时候才会停下来。表达式里可以用变量、寄存器、甚至内存访问，非常灵活。
• Count：设置命中断点的次数，比如填 100，表示"第 100 次命中时才停"。适合抓那种"跑一阵子才出问题"的场景。
• Command：可以在命中时自动执行调试命令。

说到命令，Command 窗口其实是仿真调试里最强的一个入口，可惜大部分人从来没用过。它能干的事包括：

bs main // 在 main 函数入口设置断点 printf "tick=%d\n", g_tick // 打印表达式值，不用停下来 log g_tick // 把值写进调试日志 g // 全速运行

printf这条命令特别值得掌握。你可以在一个循环的断点处挂一条打印命令，让程序每次循环自动把变量打到 Command 窗口，然后全速跑。这样相当于给你的代码加了一套"不打乱时序的串口打印"，而且不用改一行代码。

我个人的用法是这样的：先跑一遍全速，观察大流程；发现异常之后，用条件断点把范围缩小到某一次循环；再在这一处用printf把相关变量全部打出来，一次性定位。这套流程比"单步 + 猜"效率高出一个量级。

4.4 串口和 printf：在模拟器里怎么看到输出

很多人的第一反应是"仿真里能不能看串口输出"。答案是：能，但要看你用哪条路。

对 8051 工程，Keil 的模拟器对外设建模比较完整，你在代码里往SBUF写数据，串口窗口能显示出来，甚至可以模拟波特率。这条路走得很顺。

对 Cortex-M 工程，情况就不一样了。写USART1->DR = 'A';之后，模拟器里多半什么也看不到，因为 UART 外设没有被建模。这时候有三条替代路径：

第一条，用 Command 窗口的printf。前面讲过了，不改代码，缺点是只能看表达式，不能直接看到代码里printf的输出。

第二条，把输出重定向到一块内存缓冲区。定义一个char log_buf[256]，把要打印的内容手动格式化进去，然后盯着 Memory 窗口看这块内存。这个办法笨，但特别可靠，我在验证协议解析的时候常用。

第三条，把日志变量化。不打印字符串，直接维护几个全局变量记录"最后收到了什么命令""当前状态机停在哪个状态""校验失败了几次"。Watch 窗口一挂，比看串口还直观。

我一般优先用第三条，因为变量是结构化的，不会因为打印格式写错而误导判断。

5. 报错与异常排查速查

仿真调试的报错有一大半是环境问题，一小半是代码问题。我把常见的整理出来，按现象对号入座。

5.1 access violation 与 Memory Map 的配置

最常见的报错长这样：

*** error 65: access violation at 0x40021000 : no 'read' permission *** error 65: access violation at 0x20000000 : no 'write' permission

含义很明确：代码访问的这块地址，模拟器的内存映射里没给它开权限。原因有两种，一种是你访问了外设寄存器（模拟器没建模），另一种是你访问了不存在的内存区域（代码写错了地址）。

处理方式是：进入调试模式后，打开Debug -> Memory Map菜单，能看到一个地址映射表。点New添加一段范围，把读、写、执行的权限勾上。比如 STM32 的外设区0x40000000到0x400FFFFF，直接放一行进去，勾上读写权限，这个报错就没了。

注意：放开权限只是让程序能继续跑，不意味着外设行为被正确模拟了。你读RCC->APB2ENR得到的仍然是 0，等待标志位的循环照样会死在里面。放开权限是为了让其他逻辑能跑完，而不是让你相信那些寄存器的值。

如果报错出现在 RAM 区域，那就要认真对待了——很可能是数组越界或者野指针写坏了地址，回头用 Memory 窗口查。

5.2 跑不进 main、断点不命中、找不到调试器

这三类现象看起来不同，根子往往都在配置。我列一下对应关系：

还有一类特别隐蔽的：程序确实进了 main，但很快跳到一个HardFault_Handler死循环里。仿真模式下这种情况往往是访问了空指针或者没开时钟就操作外设。你可以观察 Registers 窗口里的LR（链接寄存器）值，或者看 Call Stack 里的调用链，基本能定位到出错的那一行。

5.3 时间相关：延时不对、循环跑不动、波形采样怪

关于时间，我有三条经验：

第一，仿真里的时间是被 PC 性能绑架的。程序跑得比真板子慢是常态，一个 1 秒的延时在仿真里可能要跑十几秒甚至更久。所以别在仿真里做长时间等待的验证，把延时参数临时改小是标准操作。

第二，逻辑分析仪的采样和运行状态绑定。波形是在你按 Run 的过程中采出来的，按 Stop 就停了。如果波形只画出一小段就断了，多半是你停得太早，或者采样深度设置不够。可以在 Setup 对话框里调整采样点数。

第三，Xtal 的值影响逻辑分析仪的时间刻度。前面提过，改完记得重启调试会话。如果时间轴刻度看起来和代码里的延时严重不符，先检查这里。

还有个细节：某些版本里，如果你在调试过程中修改了 Target 页的参数，必须退出调试再重新进入才会生效。我在这一点上浪费过一个下午。

5.4 常见问题速查表

把散落的问题再汇总一遍，方便直接对号：

6. 我的实操心得：仿真验证代码的推荐流程

前面讲的是"怎么用"，这一段讲讲"怎么用得好"。这些经验是我踩了不少坑之后固化下来的习惯，不一定适合所有人，但至少能帮你少走弯路。

6.1 把硬件层隔离掉：桩函数与宏开关

想让仿真真正好用，代码结构上要配合。最有效的一招是给硬件访问加一层开关。

#ifdef SIM_MODE #define HW_WRITE_REG(addr, val) do { (void)(addr); (void)(val); } while (0) #define HW_READ_REG(addr) (sim_stub_read(addr)) #else #define HW_WRITE_REG(addr, val) (*(volatile uint32_t *)(addr) = (val)) #define HW_READ_REG(addr) (*(volatile uint32_t *)(addr)) #endif

仿真模式下，寄存器的读写打到一组桩函数上，桩函数把值存进一个全局数组，模拟器里就能通过 Watch 窗口完整地看到"我写了什么、读了什么"。这比在 Command 窗口里跟 access violation 死磕高效得多。

同样的思路还可以用在串口发送、延时函数上。延时函数在仿真模式下直接改成空操作或者极短的自减，能省下大量等待时间。这个改动只在仿真的编译配置里生效，不影响发布版本。

我通常会建两个 Target：一个叫Debug-Sim，用来做仿真；一个叫Release，用来出正式固件。两者的差异就是几个宏定义和优化等级。这样切换成本极低。

6.2 一套我固定使用的验证顺序

拿到一个新的逻辑模块，我基本按这个顺序过一遍：

先让程序能停在 main，确认环境和镜像都没问题。这一步别嫌烦，跳过它后面全是无效劳动。

然后在关键流程的几个分叉点上打断点，把状态变量挂进 Watch。跑一遍，看流程走向是不是符合预期。这一步解决的是"逻辑对不对"。

接着用条件断点，把关注点缩小到某一次循环或者某一个特定输入下，用printf把相关变量全部打出来，看数据和预期差在哪。这一步解决的是"哪里开始不对"。

最后加信号到逻辑分析仪，看时序关系。这一步解决的是"信号之间的先后顺序对不对"。

顺序不要乱。我见过太多人一上来就开波形图，结果波形一坨看不懂，因为前面的逻辑还没验证过。

6.3 几个我踩过的坑

说几个印象比较深的，都是花了时间才搞明白的：

坑一：以为仿真能跑通的代码，上板一定没问题。有一次仿真里算法跑得好好的，上板就不对，最后发现是中断优先级配错了——仿真里中断模型对优先级的敏感度没真硬件那么高，问题被掩盖了。

坑二：忘了把延时参数改回来。调试时为了方便把延时改成 20，验证完忘了改回去，直接出固件，结果上板快得像抽风。这个错误我犯过两次，后来养成了在ReleaseTarget 里加编译期断言的习惯。

坑三：在仿真里相信了外设寄存器的值。读USART1->SR得到 0，我以为是硬件没使能，折腾了半天发现是模拟器根本没建这个外设的模型，读到的 0 毫无意义。从那以后我养成了一个习惯：凡是模拟器里读到的外设寄存器值，先怀疑，再采信。

坑四：仿真会话开着的时候改代码。改了代码不重新 Build 就继续调试，看到的还是旧逻辑，越调越乱。现在我的肌肉记忆是：改代码 -> F7 -> Ctrl+F5 重进调试，三步绑定，不再多想。

这套流程用到后来，我的习惯是：新模块先在仿真里跑通逻辑，再上板调硬件。两边各司其职，整体效率比自己硬扛高不少。至于模拟器本身的能力边界，用得越久越清楚，也就越不会在不该指望它的地方纠结。