1. 先把话说清楚：Keil软件仿真到底能干什么
很多人第一次接触 Keil 的时候，都是奔着"把程序烧进板子跑起来"去的，结果板子还没到、仿真器还没买，工程就卡在那儿了。其实 Keil uVision5 自带一个很多人忽略的功能：软件仿真。它不需要任何硬件，不需要 ST-Link、J-Link 或者 ULINK，直接在 PC 上把 Cortex-M 内核、存储器、部分外设"虚拟"出来，让程序在电脑里跑。你可以在里面打断点、单步、看寄存器、看变量、看内存、算代码执行时间。对于刚入门的朋友、手上没板子的朋友，或者在写纯算法逻辑还没到硬件联调阶段的朋友，这个功能的价值非常高。
我这些年带过不少新人，发现一个共性：大家把 Keil 当成"下载器"用，编译完直接点下载，中间调试环节基本靠printf和点灯。一旦遇到指针跑飞、结构体成员对不上、堆栈被踩、浮点输出乱码这类问题，就开始盲目改代码。而 Keil 的软件仿真恰好能在这些地方帮上大忙，因为它把 CPU 的每一步状态都摊开给你看。这篇文章就把我平时用 Keil 软件仿真的一套流程完整写下来，从工程配置、进入调试、常用窗口，到结构体变量怎么看、堆栈怎么查、error R6002这类报错怎么处理，都会讲到。适合刚上手 STM32、GD32 这类 Cortex-M 芯片的朋友，也适合那些想在不插板子的情况下验证逻辑的老手。
1.1 软件仿真和硬件在线调试的本质区别
要理解软件仿真，得先搞清楚它和硬件调试差在哪。硬件在线调试是真实的芯片在跑，调试器通过 SWD 或 JTAG 接口读写芯片内部寄存器、Flash 和 RAM，你看到的是硅片里真实发生的状态；而软件仿真是在你的电脑内存里，由 Keil 的仿真内核（Simulator）用软件模型来模拟 CPU 取指、译码、执行，模拟存储器读写，甚至模拟一部分外设寄存器。这个差别直接决定了两件事：速度和覆盖范围。
速度上，软件仿真跑得慢，因为它每条指令都要由 PC 上的程序去解释执行，全速跑起来可能只有真实芯片几分之一甚至更慢。所以看那种跑几百毫秒延时的代码，软件仿真会让人等到怀疑人生。覆盖范围上，软件仿真只能模拟 Keil 器件包里定义了仿真模型的那部分外设，通常内核、系统时钟、SysTick、NVIC、常见的 USART、定时器、GPIO 寄存器都有模型，但像某些厂商特有的外设、DMA 的复杂交互、USB、以太网这些，仿真模型往往不完整甚至没有。这就解释了为什么很多人仿真时GPIOA->ODR写得进去、读得出来，但一连上真实外设就出问题——仿真只认寄存器，不认外面的电路。
理解了这一点，你就知道软件仿真该用在什么位置：它是用来验证逻辑和算法的，不是用来验证硬件时序和电气特性的。
1.2 哪些场景值得开软件仿真
并不是所有项目都值得开仿真，我一般在这几种情况下会切到软件仿真。
第一种是纯逻辑验证，比如你在写一个 CRC 校验、一个环形缓冲区、一个状态机、一段协议解析（像 Modbus RTU 的帧拆解），这些东西的输入输出完全由代码决定，跟外部电路无关，用软件仿真逐步跑一遍，比插着板子点灯高效得多。第二种是排查内存类问题，指针越界、数组溢出、堆栈踩踏，这类问题在仿真里可以通过 Memory 窗口和 Call Stack 窗口看得一清二楚。第三种是新手学习阶段，比如你在啃 FreeRTOS 在 STM32F103C8T6 上的移植，想搞清楚任务切换时栈指针怎么变、PendSV 怎么触发，仿真里单步跟一遍，比看十篇博客都直观。第四种是没硬件的时候先干活，板子还在路上，工程先跑起来，逻辑先调通。
反过来，涉及 ADC 采样精度、PWM 波形边沿、外部中断响应时间、通信误码率这类问题，就别指望软件仿真了，老老实实上硬件。把这个边界划清楚，能省下大量无效折腾。
2. 动手之前：工程配置里三个决定仿真成败的开关
软件仿真跑不起来，十有八九不是代码问题，而是配置没选对。我在帮人排查时，第一个看的就是 Options for Target 里的设置，因为这里的每一个选项都会直接影响仿真会话能不能正常进入、变量能不能看到、时钟准不准。
2.1 Target 选项卡里必须确认的几项
打开Project → Options for Target（快捷键 Alt+F7），切到Target页。这一页里跟仿真关系最大的是右上角那块调试方式选择：Use Simulator和Use: ULINK/J-LINK/ST-Link二选一。软件仿真必须选Use Simulator，只要你选的是某个硬件调试器，点 Debug 的时候 Keil 就会去枚举 USB 设备，找不到就弹No ULINK Device found之类的错误——这也是热词里那个keil 5 报 no ulink devivc found最常见的成因，其实根本不是少了驱动，而是你压根想软件仿真却选错了调试方式。
紧接着往下看Dialog DLL和Parameter这两栏，它们默认会跟着你选的器件自动填好，比如 Cortex-M3 通常是DARMSTM.DLL配-pSTM32F103C8。这两项不要乱改，它决定了仿真内核知道你用的是哪颗芯片、外设模型挂在哪里。如果你手动把器件换成了别的型号，但这里没跟着变，仿真时外设寄存器就会对不上号。
还有一个容易被忽略的是Xtal（MHz）这个输入框。它填的是仿真世界里主晶振的频率，默认 12MHz，而绝大多数 STM32 板子用的是 8MHz 外部晶振。这个值直接决定了SystemCoreClock和所有基于 SysTick 的延时函数的计算结果。填错了，你的delay_ms(1000)在仿真里可能跑成 600ms 或者 1.5s，然后你开始怀疑代码，其实只是这里没改。
注意：Xtal 填的是外部晶振频率，不是芯片最终运行频率。如果你用了 PLL 倍频到 72MHz，这里仍然填 8，倍频逻辑由你的时钟初始化代码负责。
2.2 C/C++ 选项卡：优化等级和调试信息
切到C/C++页，这里有两个选项对调试体验影响极大，但新手基本不会去动。
第一个是Optimization优化等级。默认可能是-O0，也可能是别人工程里留下的-O3。一旦开了较高的优化，编译器会把局部变量塞进寄存器、把没用的变量直接删掉、把循环展开、把函数内联。结果就是你打断点想看某个变量，Watch 窗口里显示cannot read或者干脆找不到符号。这不是 Keil 坏了，是那个变量在优化后根本不存在于内存里了。所以调试阶段我强烈建议把优化降到-O0，等逻辑跑通、要评估体积和速度时再往上调。
第二个是Debug Information（有的版本叫-g），必须勾选，不勾的话调试器没有符号表，你只能看机器码，源码级断点、变量名、函数名全都没了。这个选项一般是默认勾上的，但如果你接手的是别人精简过的工程模板，就要留意一下。
顺便说一句，如果你在调试过程中频繁遇到"变量值显示不对"，除了优化，还要检查变量有没有加volatile。被中断或硬件修改的变量不加volatile，编译器可能把它缓存在寄存器里，你看到的永远是旧值，这类问题在仿真里尤其明显，因为仿真不会像真实硬件那样产生副作用帮你"碰巧"刷新。
2.3 时钟频率、启动文件与器件选型
器件选型这件事，很多人是从别人工程里拷贝过来的，器件包可能压根没装。Keil MDK 从 5 开始采用Pack机制，芯片支持包（DFP）要单独下载安装。如果 Pack 没装或者版本对不上，仿真时轻则外设窗口是空的，重则启动就报cannot load ... .axf之外的各种诡异错误。
启动文件这块，仿真时最需要注意的是Stack_Size和Heap_Size这两个宏。它们在startup_xxx.s里定义，默认栈大小通常只有0x400也就是 1KB。对于裸机小程序够用，但你要是跑 FreeRTOS、开了几层函数调用、或者在栈上放了比较大的局部数组，1KB 很快就不够。软件仿真里栈溢出不会像真机那样随机死机，往往表现为返回到一个莫名其妙的地址，或者 SP 跑到一个非法值，这种反而更容易定位，后面堆栈那一节我会详细说。
另外，如果你在工程里用了 STC、GD32、C251 这类非 ARM 内核的器件，配置方式会有差异，仿真能力也不一样。我个人经验是，Cortex-M 系列的软件仿真支持最完整，8051 次之，其他内核就得看厂家愿不愿意提供仿真模型了。
3. 从编译到跑起来：一次完整的Keil软件仿真流程
配置检查完，就可以走流程了。下面这些步骤看起来基础，但每一步都有它的用意，我会把"为什么要这么点"说清楚。
3.1 编译、进入调试会话与复位
第一步，Build（F7）。必须保证 0 Error、0 Warning 地过一遍，因为仿真调试需要一个完整的.axf可执行文件。如果编译都过不去，Debug 按钮点下去会直接报错，或者进去之后没有源码显示。
第二步，Start/Stop Debug Session（Ctrl+F5）。这时候 Keil 会启动仿真内核，加载你的程序到虚拟 Flash 里，界面会从编辑模式切到调试模式，左侧出现寄存器窗口，右侧代码区域出现灰色的断点边栏。很多人第一次进来会觉得界面"变了个样"，其实只是切换了视图，菜单栏里多出了 Peripherals、Debug 等菜单。
第三步，复位（Ctrl+F5 再按一次，或者点工具栏那个带红色箭头的 Reset）。复位之后 PC 指针回到Reset_Handler，SP 被设置为栈顶地址。这一步很重要，因为 Keil 进入调试时会停在某个位置，不复位就运行，起始状态可能是脏的。
第四步，全速运行（F5）。程序开始跑，遇到断点停下。如果你没设断点，它会一直跑下去，仿真里看起来就像"卡住了"，其实是在正常执行——因为软件仿真慢，一个长延时循环会让你感觉程序没动。
提示：仿真时如果感觉"程序不响应"，先看左下角状态栏有没有在刷新的运行指示，或者临时按 Stop 看看 PC 到哪了，不要急着认定代码死了。
3.2 断点、单步、全速运行与时间统计
断点是调试的核心手段，Keil 里在代码行左侧灰色区域点一下就能下断点，右键可以设置条件断点。条件断点在仿真里特别好用，比如你怀疑某个数组在循环第 500 次时越界，直接设i==500作为条件，程序跑到那儿才停，省去你按 499 次 F10。
单步有三个键要区分清楚：F11是 Step Into，会进入被调用的函数内部；F10是 Step Over，把函数调用当成一步执行完，不进去；Shift+F11是 Step Out，从当前函数里跳出来回到调用处。新手常见的误区是一路 F11 深入标准库函数，进去之后十几个文件跳来跳去，最后连自己在哪都不知道了。我的建议是，调试自己的逻辑用 F11，进标准库或 HAL 层用 F10，快速掠过。
还有一个非常实用的功能是执行时间统计。Keil 调试状态下底部状态栏会显示sec，表示从运行开始到现在经过的仿真时间，单位是秒。你可以用它在不插示波器的情况下粗略验证延时函数写得对不对。比如你写了个 1 秒的软件延时（不用 SysTick，纯 for 循环空转），全速跑一段，看这一秒的计数是不是对得上。如果误差超过 20%，大概率是 Xtal 频率填错了，或者编译器优化把你的空循环优化没了。这也是为什么我前面说要关注优化等级和 Xtal 这两项。
3.3 四个必开窗口：Watch、Memory、Registers、Call Stack
进入调试后，通过View菜单可以打开各种观察窗口。下面这四个是我基本每次都开的。
Watch 窗口（View → Watch Windows → Watch 1）用来监视变量。你可以在里面输入变量名、数组名、结构体名，甚至输入表达式比如arr[3]+temp*2，它会实时求值。注意，Watch 窗口对局部变量的可见性依赖于当前是否在该变量的作用域内，如果你已经 Stepped Out 出了那个函数，它就变成不可读取状态了，这很正常。
Memory 窗口（View → Memory Windows → Memory 1）用来直接看内存。输入一个地址，比如0x20000000，就能看到 RAM 从起始位置开始的原始字节。这个窗口在排查指针问题、看栈内容、验证结构体内存布局时是无可替代的。你可以设置显示格式，按 4 字节一组看比较直观。
Registers 窗口在调试视图左侧默认就有，显示 R0-R15、xPSR、SP、LR、PC 以及 MSP、PSP。看 PC 能判断程序跑到哪了，看 SP 能判断栈用得深不深，看 LR 能判断函数返回地址对不对。
Call Stack + Locals 窗口（View → Call Stack Window）显示当前的函数调用链，从main一路到你停下的位置，每一层还能展开看该层的局部变量。这个窗口在查死循环、查递归层数、查堆栈用量时特别有用，后面会详细讲。
这四个窗口打开之后，你的调试界面才算完整。我见过不少人仿真时只开着 Watch，出了问题就抓瞎，其实工具早就给你留好口子了。
4. 进阶：结构体、堆栈、外设与逻辑分析仪
基础流程走顺之后，可以上点进阶的了。这部分是我觉得软件仿真真正拉开差距的地方。
4.1 Debug模式下查看结构体变量的三种可行做法
热词里有人问keil调试助手里面的debug模式如何显示结构体变量，这确实是个高频问题。结构体不像 int 那样一行就能看完，但 Keil 其实支持得挺好，只是方法要对。
第一种，直接在 Watch 窗口输入结构体变量名。比如UART_HandleTypeDef huart1;，你在 Watch 里敲huart1回车，它左侧会出现一个+号，展开就能看到Instance、Init这些成员，继续展开Init能看到BaudRate、WordLength等字段。这是最标准的方式，前提是这个变量当前在作用域内、没有被编译器优化掉。
第二种，用强制类型转换的表达式。如果结构体变量是局部的、出了作用域就没了，而你手上有它的地址，可以在 Watch 里输入*(MyStruct_Type *)0x20000100，直接按指定的内存地址解释成结构体来看。这个技巧在处理 DMA 缓冲区、链表节点、动态申请的内存时特别好用。
第三种，把变量挪到文件作用域或加 static。这是笨办法但最稳：把你想看的局部结构体临时改成static或者提到函数外面当全局变量，编译后它就有了固定的内存地址，无论程序跑到哪，Watch 里都能看。调完记得改回去，别留在正式版本里。
注意：如果结构体展开后某个成员显示成
optimized out或者乱值，先怀疑两件事——优化等级太高，或者你编译用的头文件和实际定义不一致（比如结构体在不同文件里定义不同，典型的"一物两表"问题）。
4.2 查看堆栈用量与判断栈溢出的实操
堆栈问题是嵌入式里最阴的一类 bug，因为它的表现是随机的。软件仿真给了我们一个相对可控的观察环境。
先在 Registers 窗口里看SP的当前值，然后在启动文件里找到Stack_Size的定义，计算出栈底地址。以 STM32F103C8T6 为例，RAM 从0x20000000开始，栈通常在 RAM 的高地址端往下增长。假设栈大小0x400，栈顶在0x20000400（具体看链接后的 map 文件），那么 SP 一旦低于0x20000000就说明溢出了。
更直观的做法是在栈底附近填一段"标记值"。你可以在程序最开始，往栈区最低的一段地址写一串固定数据，比如0x5A5A5A5A，跑完一段业务逻辑后再回来检查这段数据有没有被覆盖。如果被改了，说明栈已经长到那儿了。这个技巧在仿真里非常好验证，因为 Memory 窗口可以实时看。
另外，Call Stack 窗口能直接告诉你当前有多少层函数嵌套。如果发现调用链莫名其妙地深，或者出现了不应该存在的递归，那就是栈用量失控的信号。我处理过一个案例，一个递归解析 JSON 的函数，正常数据没问题，一遇到嵌套特别深的报文就崩，仿真里一开 Call Stack 就看到了几十层递归，问题一目了然。
4.3 Peripherals 菜单与 Logic Analyzer 的配合
Keil 调试模式下菜单栏有个Peripherals，里面列的是当前器件支持仿真的外设，比如 GPIO、USART、TIM、NVIC、SysTick。点进去可以看到对应的寄存器状态，甚至可以勾选某些位来模拟外部输入。比如你把某个 GPIO 引脚配置成输入，在 Peripherals 里勾一下，就相当于外面给了个高电平，代码里的读取逻辑立刻能验证。
Logic Analyzer（View → Analysis Windows → Logic Analyzer）是个被严重低估的功能。你可以把某个变量或者某个 GPIO 输出寄存器的位加进去，它会画出一条随时间变化的波形。比如你想验证软件 PWM 的占空比对不对，把对应的变量加进去，全速跑一会儿，波形就出来了。它当然比不上真实示波器，但用来验证"逻辑上高低电平切换的时机对不对"完全够用，还不用接线。
提示：Logic Analyzer 抓的是变量值的变化，所以被加进去的变量最好是全局或有稳定地址的，局部变量出了作用域就抓不到了。
4.4 串口仿真与 printf 重定向
很多人喜欢用printf打日志调试，在真实板子上通过 USART 输出到串口助手看。在软件仿真里，这条路也能走通，但走法不一样。
由于仿真里的 USART 是虚拟的，你没法接到电脑的串口助手，所以要重定向到 Keil 自己的输出窗口。做法是重写fputc，在里面把字符写进ITM或者直接用调试器的输出机制。Keil 的View → Serial Windows → UART #1会显示仿真 USART 的输出内容，前提是你在代码里正确地把数据写进了 USART 的 DR 寄存器。这样你调用printf，字符就会出现在这个窗口里，效果和真实串口几乎一致。
需要注意的是，用printf输出浮点数在 Keil 里是有坑的，这正好引出下面那个经典报错。
5. 报错与坑：软件仿真常见的几类问题排查
软件仿真遇到的问题，翻来覆去就那么几类。我把最常见的一一列出来，附上我的处理思路。
5.1 error R6002 的成因与处理
error R6002这个报错，全称是floating point support not loaded，翻译过来就是"浮点支持没有被加载"。它最典型的触发场景是这样的：你的代码里写了printf("%f", value)，但链接器发现整个工程里没有任何地方真正用到浮点运算，于是就没把浮点库链进来；结果运行时格式化输出需要一个浮点格式化例程，找不到，就报这个错。
处理方式有几种，按推荐程度排序。第一，勾选 Use MicroLIB（Options for Target → Target 页底部），MicroLIB 是 Keil 提供的精简 C 库，对浮点格式化的支持更"自动"一些，很多情况下能直接解决。第二，手动触发浮点库链接，在代码里加一句volatile float dummy_float = 1.0f;，只要它参与一次实际运算（比如dummy_float *= 2.0f;），链接器就会把浮点支持带进来。第三，改掉 printf 的用法，把printf("%f", v)换成整数拆分的写法，比如先把浮点乘以 1000 转成整数，再用%d输出，最后自己加小数点。这种做法在资源紧张的 MCU 上其实更常见。
我个人的建议是，调试阶段用 MicroLIB 图省事，正式发布时如果代码体积敏感，就把浮点输出改掉，能省下不少 Flash。
5.2 找不到 ULINK、变量看不到、延时不准
这三个问题在热词里全出现了，本质上是三个不同的坑。
No ULINK Device found：前面说过了，八成是调试方式选错了。有人装了 ULINK 驱动之后，Options 里默认就被改成了硬件调试，你想软件仿真就得手动切回 Use Simulator。还有一种可能是你同时装了多个调试器，Keil 认错了设备，这时候去 Debug 页里确认端口和协议设置。
变量看不到或者值不对：依次检查优化等级是不是-O0、变量是不是被优化掉了、有没有加volatile、当前是不是在该变量的作用域内、头文件定义和实际是否一致。这五个点按顺序排一遍，基本能解决九成。
延时不准：检查 Xtal 频率、检查你的延时函数是不是被优化掉了、检查是不是用了 SysTick 但仿真里 SysTick 时钟源配置不对。软件延时循环最容易在-O2以上被优化成一条空指令，看起来延时直接消失。
5.3 一张速查表
为了让你排查时有个抓手，我把常见现象和对应原因整理成一张表：
| 现象 | 最可能的原因 | 处理方式 |
|---|---|---|
| 进不了调试，提示找不到设备 | 调试方式选成了硬件调试器 | Target 页改回 Use Simulator |
| 外设窗口空白、寄存器读不到 | Pack 没装或器件型号不匹配 | 安装对应 DFP，核对 Dialog DLL 参数 |
| 变量显示 optimized out | 优化等级过高 | 降到 -O0，必要时加 volatile |
| printf 浮点报 R6002 | 浮点库未链接 | 勾选 MicroLIB 或手动触发浮点链接 |
| 延时明显偏长或偏短 | Xtal 频率填错 | 改成实际晶振频率 |
| 程序跑着跑着返回乱地址 | 栈溢出 | 加大 Stack_Size，查递归和局部大数组 |
| 断点打不上、显示为空心 | 代码未编译或不在有效行 | 重新 Build，断点下在可执行语句上 |
| 全速运行像卡死 | 仿真速度慢，长循环耗时 | 用条件断点跳过，或缩短循环次数 |
这张表我基本是踩一遍坑总结一条，贴在工作台边上，比翻文档快。
6. 我自己的使用心得与边界认知
讲了这么多操作，最后说点体会层面的东西。
6.1 软件仿真能替代硬件调试吗
不能，而且永远不能。软件仿真的强项在逻辑层，它把 CPU 的状态透明化，让你能"看见"每一步发生了什么。但真实的嵌入式系统里，绝大多数诡异问题都出在仿真看不到的地方：电源纹波、信号完整性、外设时序偏差、中断延迟、DMA 与 CPU 的总线竞争。这些只有上真板子、上示波器、上逻辑分析仪才能定位。
我的习惯是分两段用：写代码和验证算法阶段，能仿真就仿真，因为它快、可复现、能反复重来；进入硬件联调阶段，就果断换回真实调试器。两者不是替代关系，是接力关系。很多新手想跳过硬件直接靠仿真交付，最后一定会在联调阶段加倍还回来。
6.2 几个容易忽略的细节
第一个细节是仿真之前先清理工程。Keil 的增量编译有时候会留下旧的.o文件，导致你改了代码，仿真里跑的却是老逻辑。我一般在大改之后会 Rebuild All 一次，图个心安。
第二个细节是别在仿真里验证时序敏感代码。前面说过，仿真速度是变动的，跟你的 PC 负载有关，所以任何依赖精确时间的东西，在仿真里测出来的值只能当参考。SysTick的计数在仿真里是准的（因为按指令数折算），但基于外部事件的时序就不准了。
第三个细节是保存一份"调试专用"的工程配置。我通常会为每个项目留一份把优化关掉、调试信息全开、Xtal 填对的配置，平时开发用这份，出正式版本时再切到发布配置。这样做的好处是不会在紧张发布的时候忘了把优化加回来，也不会因为调试配置混进正式版本导致代码体积暴涨。
第四个细节是注意正版授权。Keil MDK 是商业软件，社区版对代码体积有限制，商用需要正规授权。网上流传的各种变通做法我从来不碰，一方面合规上有风险，另一方面那些来路不明的工具经常把安装目录搞乱，最后连正常编译都成问题，得不偿失。用官方渠道装、按规矩用，反而省心。
最后一个建议：把软件仿真当成一个"随身的实验台"。你在地铁上、在咖啡馆里、在没有硬件的任何场合，只要有 Keil 和一台电脑，就能验证你的逻辑、观察你的变量、追踪你的堆栈。这个能力用熟了，你对代码的理解会从"写完烧进去看结果"变成"每一步我心里都有数"，这两种状态的差距，在真正遇到复杂 bug 的时候会体现得非常明显。
