企业官网建设流程全解析

先说个现象：很多人学单片机写流水灯、按键扫描没问题，一旦程序上了规模，比如跑个 FreeRTOS、接个屏、调个通信协议栈，就明显感觉"代码不受自己控制了"。遇到 bug 第一反应是往代码里塞 printf、加延时、甚至删代码碰运气。其实 Keil 自带的调试功能远比很多人想象中强得多，但大部分人真正用到的只有两个按钮：F5 全速跑、F11 单步走。更可惜的是，还有不少人连"能进调试模式"这关都过不去，卡在各种报错上。

这篇东西我不会讲那些废话式的基础操作，而是按我实际用 Keil 调 STM32、GD32、NXP 芯片这些年走过的路，把"用 Keil 进行程序调试"这件事从配置、窗口、断点、仿真到经典坑位，完整捋一遍。内容主要基于 Keil MDK 5.37 和 ARM Compiler 6 的环境，其他版本差别不大，思路一样能复用。

1. 说句实话：很多人不是不会调试，是调试前的准备就没做对

1.1 编译器优化是调试时最大的"隐形杀手"

我接过不少"程序下载后跑飞""变量值监视不了"的咨询，最后查来查去，八成出在优化等级上。Keil MDK 基于 ARM Compiler，默认的优化等级可能是 -O0（Level 0），也可能是 -O2（Level 2），取决于你用的芯片包和工程模板。很多从网上扒下来的工程，作者为了代码跑得快，直接拉到了 -Oz 甚至 -Omax。

以 ARM Compiler 6 为例，优化选项大概这几个档位：

• -O0：不优化，所有变量保持，调试体验最好。
• -O1：中等优化，部分局部变量可能被优化掉。
• -O2：更高优化，循环展开、内联函数，变量大量丢失。
• -O3、-Oz：极端优化，为了体积或性能，调试基本告别"看变量"。

你如果在 -O2 下调试，碰到明明代码里写了个temp = 100;，Watch 窗口却显示temp = <cannot evaluate>，或者单步执行时跳来跳去不按行走，不用怀疑自己，就是优化器的锅。

所以我的习惯是：调试阶段一定把优化等级压到 -O0。具体路径：Options for Target→C/C++ (AC6)标签页 →Optimization: Level 0 (-O0)。同时确认Debug Information是勾上的。这个选项不开，调试器就没有足够的信息把汇编指令映射回 C 代码行，单步时经常提示"Source not available"。

注意：如果是正式发布版本，再改回高优化等级去编译。但发布版本做好日志输出，否则出了问题只能干瞪眼。

1.2 Debug 标签页的配置，决定了你能不能进调试模式

Keil 里"能编译"和"能调试"是两码事。很多人一按 Ctrl+F5 就弹出错误框，十有八九是 Debug 标签页没选对调试器。

打开Options for Target→Debug标签页，左上角有两个单选：

• Use Simulator：纯软件仿真，不用接开发板。
• Use Debugger：接仿真器在线调试，下拉框里选 ULINK、J-LINK、ST-Link 等。

用 ST-Link 调试 STM32 的兄弟，记得下拉框选ST-Link Debugger，然后点旁边的Settings，看SW Device里有没有识别到芯片的 IDCODE。如果这一栏是空的，说明调试器和电脑的通信没通，或者调试器和芯片之间的 SWD 线有问题。

Settings里还有Flash Download选项页，里面要保证你的芯片型号对应的 Programming Algorithm 存在。常见的情况是：换了芯片型号，但 Flash Download 算法列表还是老的，导致下载时报No Algorithm found或者Erase Failed。正确做法是点Add，选择匹配你当前芯片 Flash 的算法（比如 STM32F103 就选 STM32F10x High-density Flash 或者对应容量的），把Reset and Run勾上，这样烧录完程序会自动复位运行。

我之前遇到过一哥们儿，能进调试模式，但一按 F5 程序跑不起来，后来发现是因为Debug标签页里选了Run to main()，但程序里断点设在了 main 函数之前的系统初始化代码上，Keil 会在到达断点前先执行那部分代码，结果就"卡死"了。一般情况下，Run to main()这个选项是帮我们跳过启动文件直接停在 main 的，但如果你在 SystemInit 或启动文件里设了断点，行为就变得"诡异"，这个细节很多人不知道。

1.3 为什么程序能烧录却没法在线调试

烧录成功 ≠ 能在线调试。能烧录说明 SWD/JTAG 通信链路是通的，但调试还会失败，常见原因有：

1. 调试口被复用：代码里把 SWDIO/SWCLK 引脚配置成了普通 GPIO，程序运行后把调试口关掉了，第二次就没法连接。解决办法是烧录时按住复位键，点下载瞬间松开，或者用 ST-Link Utility 之类工具先擦除芯片。
2. 供电不足：尤其是用杜邦线连着 ST-Link 给板子供电时，一个 USB 口拖着板子、显示器、键盘，电压一掉，调试器就掉线。实测下来，给调试器单独供电或者用带外部电源的板子，稳定性完全不一样。
3. 连接模式不对：Settings 里 Connect 模式有Normal和Under Reset，对于某些芯片（比如 GD32 或者已经跑飞的芯片），用Normal连接不上时，改用Under Reset模式往往能救回来。

2. 调试窗口不是摆设：六个窗口把程序"看穿"

2.1 寄存器窗口：不要只盯着 PC 和 SP

进入调试模式后，View→Register Window打开寄存器列表。这里面除了 R0-R12、SP、LR、PC、xPSR，还能看到当前函数调用时的寄存器状态。

很多人只看 PC（程序计数器），偶尔看 SP（栈指针）。但实际排查问题时，LR（链接寄存器）的价值被严重低估。LR 在函数调用时保存了返回地址，当你的程序跑飞或进入 HardFault，LR 寄存器往往能告诉你"你是从哪个函数跳过来的"。比如你在一个函数里调用了另一个函数，后者崩了，LR 保存的就是后者的返回地址。配合反汇编窗和 map 文件，一下就能定位到崩溃前的调用关系。

另外，xPSR 里的中断标志位（比如溢出标志 V、零标志 Z）在做数据处理类 bug 排查时非常有用。我曾经调一个 PID 输出异常的问题，就是在寄存器窗口发现某个计算步骤的溢出标志置位了，才意识到是整型溢出，而不是 PID 参数的问题。

2.2 Watch 窗口的正确用法：局部变量、全局变量和结构体

View→Watch Window→Watch 1打开监视窗口。把代码里的变量直接拖进去，程序全速运行或单步时会显示当前值。这里有几个实操细节：

• 局部变量只在函数作用域内有效。你在 main 里的 Watch 窗口看一个中断服务函数里的局部变量，Keil 会直接显示"not in current scope"，这不是 bug，是变量作用域的限制。想看局部变量，先把断点停在那个函数内再看。
• 结构体变量：Keil 的 Watch 窗口支持结构体展开，点开前面的三角箭头就能逐成员查看。但有一个前提：结构体内存必须真实分配了。uint8_t ucheap[1024];这类大数组，如果在某个函数里声明为局部变量，编译器很可能会把它分配到栈上，一旦栈溢出，Watch 窗口的值就乱套。正确做法是把这种大缓冲放到全局或者静态区。
• 被优化掉的变量：-O0 下可以保证所有变量都能查看，但如果你开了优化，某个变量被优化掉了，Watch 窗口会提示<cannot evaluate>。除了改优化等级，另一种办法是把变量声明为volatile，但这不是好习惯，只能作为临时调试手段。

2.3 内存窗口：用地址和类型查看一切

View→Memory Window→Memory 1打开内存窗口。这是我最常用的窗口之一，尤其适合排查数组越界、堆栈溢出、标志位错乱这类问题。

具体用法：在 Address 栏输入0x20000000（看你芯片 RAM 的起始地址），右侧显示那个地址开始的一段内存数据。你可以右键选择按Unsigned Char、Unsigned Int、Unsigned Long等方式解析数据，也可以直接输入&变量名，Keil 会自动跳到该变量的地址处，然后以十六进制数据展示。如果你怀疑某个数组越界了，直接把整个数组的内存段拉出来看，就能发现越界的值写到了数组后面哪块内存里。

我调过一个典型问题：任务栈溢出导致 FreeRTOS 任务自动删除了，排查方法就是在内存窗口看任务栈地址段，发现栈顶之外的数据被改得面目全非，立马定位是哪个数组写越界了。

2.4 反汇编窗口：当 C 语言和汇编"打架"时看这里

View→Disassembly Window打开反汇编窗口。这个窗口适合在两种场景下用：

1. 你想确认编译器到底把 C 代码编译成了什么机器指令，尤其是在分析优化后的代码行为时。
2. 程序死机后，你通过寄存器看到 PC 跑到某个地址，需要在反汇编窗口看这个地址附近的指令，判断程序到底在干什么。

反汇编窗口里的黄色箭头是当前正在执行的指令，每一条 C 代码旁边都对应几行汇编。你可以在汇编指令上打断点，也能单步执行汇编指令。对于硬件异常（HardFault）这类问题，反汇编窗口是终极武器，后面我会详细展开。

2.5 Logic Analyzer 和 Live Watch：波形级调试技巧

严格来说，Keil 的 Logic Analyzer 不是直接显示电压波形，而是显示"变量/信号"随时间的变化曲线。在调试模式下，View→Analysis Windows→Logic Analyzer打开后，点 Setup 添加要观察的变量（比如某个 PWM 计数器的值，或者某个 IO 口的电平状态），然后全速运行程序，你能看到一条波形曲线。

这个功能在分析传感器数据变化、看变量跳变规律、确认某个状态位是否按预期翻转时非常好用。比如调试一个按键消抖逻辑，用 Logic Analyzer 直接观察按键变量和消抖计数器的变化曲线，比肉眼盯 Watch 窗口的数值有效率得多。

Live Watch（View→Live Watch Window）则可以让你在全速运行状态下实时刷新部分变量的值。这个功能不受断点停止的限制，前提是变量地址固定且没有被优化掉。实测下来，Live Watch 刷新速度有限，高频变化的变量在它上面会卡顿，但用来监视状态机状态、错误标志这类低频变量足够了。

3. 断点的高级用法：不只是暂停一下

3.1 硬件断点数量限制：为什么断点设多了 Keil 会罢工

很多人不知道，Cortex-M 内核的硬件断点数量是有限的。具体来说，Cortex-M3/M4 有 6 个硬件断点比较器，Cortex-M0 只有 4 个。Keil 的调试器直接使用这些硬件断点资源，所以你在 Keil 里超过数量限制地打断点，新增的断点会显示为灰色，不可用。

解决方法是：把不用的断点删掉，或者用软件断点（Keil 在 Flash 算法支持的情况下，能把断点指令写入 Flash，这就不占内核的硬件断点资源）。实际经验是，调试时保存一个断点集合（Debug→Breakpoints窗口里有 Save 功能），换工程时直接 Load，效率会高很多。

3.2 条件断点：只在特定条件下停下

在断点窗口（Debug→Breakpoints）里，你可以给每个断点设置条件。右键断点行 →Breakpoint Properties，在 Expression 里输入条件表达式，比如：

count >= 100 && flag == 0x01

这样程序只有在count超过 100 且flag为 1 时才会在这个断点停下。条件断点的价值在于：你不想在每一次循环都停，只想在满足某个条件的时刻停。我在调通信协议栈时经常这么干，比如想停在收到特定报文类型、特定长度时，条件断点省掉的 F5 按键次数，绝对能让你手指轻松很多。

注意：条件断点有一个代价，就是每执行到该处一次，调试器都要评估一次条件表达式。如果该行被执行得非常频繁（比如几十 kHz 的中断服务函数里有条件断点），程序会被拖慢到几乎跑不动的程度。这种情况建议改成"先全速跑，等定时器或者缓冲区满足条件后再停下来"的逻辑，或者干脆用数据观察点。

3.3 数据观察点：变量变化时自动停下

数据观察点（Watchpoint）是硬件调试里特别实用但常被忽略的功能。在 Keil 里，右键 Watch 窗口的某个变量，选择Set Watchpoint，之后只要这个变量的值发生变化，程序就会自动停下来。这个功能调试"某变量被莫名修改"特别管用。

我调过一个看门狗复位的问题：程序跑着跑着就重启了，怀疑是某个全局状态标志被异常修改。用 Watchpoint 监视这个标志，程序一旦被改动就停下，立刻看调用栈，发现是有个野指针通过数组越界写到了这个标志的地址上。没有 Watchpoint，这种问题基本只能靠运气。

3.4 全速运行时"死机"怎么查：暂停 + Call Stack + Locals 三连

程序全速运行时卡死（跑飞、死循环、HardFault），最常用的三板斧是：

1. 点调试工具栏的Stop（也就是 Halt 按钮），把正在运行的程序暂停下来。
2. 打开View→Call Stack Window，看当前调用栈。如果程序死在一个函数里，这里会列出调用链，从 main 到中断服务函数到当前函数，一目了然。
3. 打开View→Locals Window，看当前作用域里所有局部变量的值。

这套"暂停 → 看栈 → 看局部变量"的组合拳，能解决 70% 以上的"程序为什么卡死"问题。死循环不是"毫无线索"，它一定有线索：卡在哪个函数、哪个变量一直不变、哪个标志位一直等不到置位。

3.5 HardFault 处理的实战排查路径

HardFault 是嵌入式调试里最知名的"噩梦"。其实 Keil 下定位 HardFault 有一套固定套路，熟练了十分钟内能出结果。

第一步：程序 HardFault 后，在调试模式下查看Fault Status相关寄存器。Keil 的 Peripherals 菜单里直接有Core Peripherals→Fault Reports，打开就能看到CFSR（配置故障状态寄存器）、HFSR（硬故障状态寄存器）、DFSR（调试故障状态寄存器）的置位情况。比如CFSR里的MMARVALID和IACCVIOL位提示访问了非法地址，UFSR里的UNDEFINSTR提示执行了未定义指令。

第二步：查看 LR 寄存器的值。LR 在硬件异常时保存的是异常返回地址，Bit2 为 1 表示从线程模式返回，Bit3 为 1 表示使用 PSP（进程栈指针）。根据 LR 判断程序在被中断打断之前用的是 MSP 还是 PSP，再决定去看哪个栈。

第三步：查看栈内存。如果使用的是 MSP，就看 SP 指向的栈内容，函数调用压栈的 R0-R3、R12、LR、PC、xPSR 都会按顺序排列在栈上。通过 PC 的值，配合反汇编窗口和 map 文件，就能定位到崩溃前最后执行的代码。

复杂一点的项目，建议直接在工程里加一个 HardFault 处理函数，在故障发生时把 PC、LR、CFSR 等关键寄存器值存到内存里，或者通过串口发出来。这样即使不在调试模式下，也能知道程序崩在哪条指令上。

4. 软件仿真：没有开发板也能调，但前提条件要搞清

4.1 什么时候适合用 Simulator

Keil 的软件仿真（Simulator）可以在没有硬件的情况下运行程序，只要你配置正确，PC 指针照样跳、变量照样变、串口输出也能看。这不是玩具功能，在以下场景里它比硬件调试还好用：

• 纯算法验证：PID 参数、滤波算法、FFT、CRC 校验等。
• 数据结构正确性：链表操作、环形缓冲、状态机流转逻辑。
• 纯逻辑调试：不需要真实外设的模块。

我自己经常在没有拿到新硬件的时候，先用 Simulator 把通信协议解析和状态机框架调通，硬件到了之后只做寄存器层的适配。这样做能明显压缩联调时间。

4.2 Simulator 配置的关键：时钟和晶振频率

Simulator 不是随便点个 Use Simulator 就能跑的。你必须确保Options for Target→Target标签页里的Xtal (MHz)填写正确，因为这个值直接决定 Simulator 里模拟的指行速度和定时器频率。如果设置成 0，模拟器可能跑出错误的时间行为。

对于 STM32 这类芯片，Simulator 模式下还可以通过对话框模拟外部引脚电平变化，在中断里选择View→Peripherals→GPIO之类的选项，手动拉高/拉低某个引脚，观察中断是否符合预期。这对调试按键触发逻辑、外部中断响应时间、状态机切换时机，帮助非常大。

4.3 串口在 Simulator 里居然能输出，很多人不知道

在 Simulator 模式下，如果你的程序调用了标准库的 printf（重定向到 UART），Keil 会弹出一个模拟串口窗口（View→Serial Windows→UART #1），程序的串口输出会直接显示在窗口里。这个功能调试通信协议非常实用：不需要硬件、不需要示波器，直接看打印出来的字符串。但前提是你已经正确重定向了 fputc 到 UART，也就是工程里实现了类似int fputc(int ch, FILE *f) { ... }的函数。

4.4 为什么仿真时变量正常，下载到板子后就疯掉

我经常被问："为什么 Simulator 里程序跑得好好的，下到板子上就死机了？" 这个跟仿真本身的局限有关：

1. Simulator 不模拟真实时序：外设的行为在模拟器里被简化了，比如 Flash 擦写时间、ADC 采样速率、通信总线的应答时序，模拟器和真实芯片的性能天差地别。如果你的代码对时序敏感，仿真通过不代表硬件通过。
2. Simulator 不模拟引脚电气特性：外部中断的毛刺、电平抖动的干扰，Simulator 根本模拟不出来。
3. Simulator 里没有时钟树：LLI、PLL、锁相环的行为在模拟器里是很粗粒度的，你只能在"逻辑层面"验证，不能验证"时钟层面的正确性"。

所以我的建议是：Simulator 适合调试"逻辑正确性"，硬件调试适合验证"时序和电气正确性"，两者配合使用，而不是互相替代。

5. 那些年 Keil 调试图谱里的"经典坑"与完整排查链路

5.1 "No ULINK Device found"到底在说什么

这个报错几乎是每个 Keil 新手都见过的。名字看起来是"找不到 ULINK 设备"，但实际上 ULINK 只是 ARM 自家调试器的牌子，你用的是 ST-Link 或者 J-Link 也可能报这个错。核心含义是：Keil 没有识别到你选择的调试器。

完整的排查链路是这样的：

1. 先确认Options for Target→Debug标签页下拉框里选的确实是你手里的仿真器型号。插着 ST-Link 选 J-Link，绝对不会识别成功。
2. 在计算机的设备管理器里看调试器有没有被系统识别出来，如果显示黄色感叹号，说明驱动有问题，重装驱动。ST-Link 的驱动经常在换电脑之后掉。
3. 确认调试器和芯片之间的接线。SWD 只需要四根线：SWDIO、SWCLK、GND、VCC（有的板子还需要 NRST）。这四根线不能接错，SWDIO 和 SWCLK 不能接反。杜邦线接触不良是常见故障点。
4. 在Settings里看SW Device是否识别到 IDCODE。识别不到时点击Scan按钮重新扫描，还不行就考虑芯片的电源和复位电路是否正常。
5. 检查芯片是不是进入低功耗模式或者把调试口禁用掉了。这种情况最坑，解决办法是让板子在上电瞬间进入 Bootloader 模式（比如 STM32 的 BOOT0 拉高），此时 Flash 不执行用户代码，调试口自然恢复，然后用烧录器擦除 Flash 或者烧录一个禁用调试口的函数覆盖掉。

5.2 "该进程已终止，因为它无法分配更多的内存"

这个报错我见过不下十次，尤其是编译大型工程时出现。它发生在 Keil uVision 的编译进程（或调试进程）向操作系统申请内存失败的时候。主要原因和处理方案：

• Keil MDK 是 32 位应用：在 Windows 上用 32 位程序跑大型工程，会遇到 2GB/4GB 的内存上限。历史教训是：把 Keil 的安装路径改成不带空格的短路径（比如C:\Keil_v5），编译时关闭杀毒软件的实时监控，能缓解内存分配失败。
• 工程打开太多浏览信息：Browse Information和Source Browser功能会在后台生成大量索引文件。可以在Options for Target→Utilities→Browse Information里暂时关闭，编译速度和内存占用都会有改善。
• Debugger 和编译进程同时跑：在调试模式下修改代码然后编译，内存本来就紧张，更容易触发这个报错。先退出调试模式，再重新编译。
• 工程优化到 -O0 也会耗内存：-O0 生成大量调试符号，符号表在编译时全放内存。如果工程很大又必须 -O0，试着把部分模块单独编译成静态库，减少汇编阶段的符号压力。

5.3 结构体变量、看门狗、"大数组"在调试器里引起的"灵异事件"

这三个问题在热搜词里反复出现，说明踩的人相当多。

先看结构体变量。在调试助手里怎么显示结构体变量？操作其实很简单：调试时在 Watch 窗口输入结构体变量名，比如g_sensor_data，然后点前面的三角展开，就能看到每个成员的值。如果结构体显示不出来，优先检查：结构体变量是否被优化掉（换 -O0）、当前作用域是否在结构体可见范围内、结构体是否定义在一个未被编译的源文件里。另外，结构体成员如果是指针，Watch 窗口显示的是地址而不是值，要手动取*指针才能看到内容。

其次是看门狗。很多人调 STM32 的 IWDG（独立看门狗）时发现：单步调试时程序不断复位。这是因为 STM32 的 IWDG 时钟源是 LSI（低速内部时钟），它在内核被调试器暂停时依然在跑。也就是说，调试器把 CPU 暂停了，但看门狗还在倒计时，超时就把芯片复位了。解决思路有三种：

1. 调试时在软件里屏蔽喂狗逻辑，或者把 IWDG 初始化代码临时注释掉。
2. 在喂狗函数处设一个断点，让程序每次跑到这里都能被断点停下并"喂狗"，但全速跑的时候依然可能复位。
3. 有些调试器支持在芯片的调试寄存器里配置"内核暂停时外设时钟也暂停"的行为，但 IWDG 用 LSI 时钟时不保证生效，实测最可靠的办法还是调试时先关掉看门狗。

最后是大数组uint8_t ucheap[1024];这类全局数组的"神秘消失"。如果你在 Watch 窗口输入ucheap却找不到，可能的原因：

• 数组被放在未使用的段（section），链接器把它垃圾回收了。
• 数组被定义未初始化且没有被引用，编译器在优化时直接丢掉了。
• 数组定义在某个被条件编译排除的源文件里。

解法：先看 map 文件（编译后在 Listings 文件夹下），搜索ucheap，看它是否存在于最终镜像里、分配在哪个地址、大小多少。如果 map 文件里根本没有，说明链接器把它优化掉了。临时给它加一个volatile或者在某处引用它，就能保住。

5.4 生成 AXF/HEX 文件与调试符号的关系，以及"Keil 外面的文件夹改名"后的问题

先记住一个结论：Keil 里能调试、能看变量值、能在 Watch 窗口找到变量，一切都依赖一个东西——调试符号信息。调试符号信息默认打包在AXF文件里（ELF 格式，包含了程序代码、数据和全部符号表）。HEX 文件只是纯二进制代码，不包含调试符号。

所以当你想把程序拷给别人做 gdb 调试、或者用第三方工具分析崩溃现场时，一定要连 AXF 文件一起给，只给 HEX 文件对方是没法还原变量信息的。Options for Target→Output标签页里勾选Create HEX File是生成 Hex 文件的开关，Debug Information是生成 AXF 调试信息的开关，两个开关独立。

"Keil 外面的文件夹名称更改后出了很多问题"这种情况，本质上是工程文件内部保存了绝对路径。Keil 的工程文件（.uvprojx）在首次创建时会记录所有源文件的绝对路径，手动在资源管理器里改文件夹名或者移动工程目录，Keil 里原有的文件路径就失效了，编译报错找不到文件。这不是 Keil"脑子有问题"，而是路径管理设计如此。

解法：移动工程目录后，在 Keil 里打开工程的Manage Project Items（就是那个"品"字图标），逐个重新添加丢失的源文件，或者直接用文本编辑器打开.uvprojx文件全局替换旧的绝对路径字符串。更好的习惯是从一开始就用相对路径：Options for Target→C/C++→Include Paths里尽量用.\开头的相对路径，这样整个工程文件夹可以随意挪动。

5.5 代码格式化、行距调整和第三方插件的"调参"日常

调试不只是看变量和断点，代码可读性也是调试效率的一部分。Keil MDK 自带的编辑器比较简陋，但有几个小技巧能让日常调试体验提升一截：

• ASTYLE 格式化插件：ASTYLE 是开源的 C/C++ 代码格式化工具，可以在 Keil 里通过Tools→Customize Tools Menu配置成外部工具。用astyle --style=allman --indent=spaces=4 文件名.c这类命令一键整理代码，尤其适合接手别人的乱码工程。
• CPPCHECK 静态检查：把 Cppcheck 集成到 Keil 的 Tools 菜单里，编译前先做一轮静态检查，很多空指针、数组越界、未初始化变量的问题能早早就揪出来，比在调试器里折腾半天高效太多。
• Keil 编辑器的行距/字体：Edit→Configuration→Colors & Fonts里可以调字体大小和颜色。行距本身 Keil 没有直接选项，但你可以在Configuration→Editor里开启Use syntax coloring和Show line numbers，代码结构看起来清楚很多。

这些辅助工具解决的是"代码本身的问题"，而调试器解决的是"代码运行中的问题"，两者配合着用，才是完整的调试工作流。

附：我自己的调试工作流参考

干这一行时间长了，每个人都会形成一套自己的调试路径。我现在拿到一个"程序行为不对"的问题，基本按下面这个顺序走：

1. 先复现，确认触发条件。稳定复现的 bug 才是可以调的 bug，不能稳定复现的问题先加日志，记录触发前的状态。
2. 编译时 -O0 + Debug Info，保证调试顺畅。
3. 用断点观察入口和出口。在可疑模块的入口和出口各打一个断点，看进来时的参数和出去时的返回值，确定问题在模块内部还是外部。
4. 看寄存器、内存、调用栈。根据当前 PC 的位置往回推，配合 Call Stack 和 Locals 锁死调用链。
5. 必要的时候上 Watchpoint 和条件断点，监视关键变量的变化时刻。
6. 硬件时序问题用 Logic Analyzer 抓变量波形，定位时序逻辑错误。
7. 最后才是改代码。改完先跑几轮回归，确认引入新问题的概率降到最低。

这套流程看起来没什么花哨的，但每一步都有它的不可替代性。调试这件事，真正拉开差距的不是工具本身，而是你大脑里那个"从现象到原因的推理链路"的完整程度。

最后分享一个我个人经验里最值钱的体会：调试时尽量保持"每次只改一个变量"。很多人一急起来，这个函数加个判断、那个中断改个优先级、全局变量换个类型，三个改动同时下去，程序还是错的——恭喜你，你现在有三个 bug 要查了。如果你能做到一次只动一处、改动后立刻验证，退回到问题之前的状态重新观察，其实大多数嵌入式软件的 bug 都没有想象中那么难缠。Keil 给了你这么多窗口和断点，就是让你有足够的手段把问题一步步逼到死角里，剩下的就是耐心。