Keil MDK调试全攻略：从断点单步到HardFault定位

写嵌入式这几年，我越来越觉得一件事：写代码只是起点，真正拉开差距的往往是调试能力。同样一块板子、同一个工程，有人卡在看门狗复位上两三天，有人打开Keil半小时就定位到问题。Keil MDK作为最普及的ARM开发环境之一，它的调试功能其实远比大多数人用的要多。软件仿真、硬件断点、内存窗口、逻辑分析仪、HardFault定位、RTOS任务级调试——这一整套组合拳打下来，工程出问题时你是手忙脚乱还是胸有成竹，差别很大。

这篇文章我按“由浅入深”的顺序，把Keil里常用的调试方法完整过一遍。适合刚接触STM32、GD32这类ARM单片机，还在用“串口打印大法”Debug的新手，也适合裸机开发想进一步提升排错效率的同学。我会尽量把每一步的操作细节、背后的原理、我踩过的坑都讲清楚，你可以照着一步步试。

1. 开始调试前，先把这几件事做对

1.1 软件仿真和硬件调试，先分清你要用哪个

Keil MDK的调试入口主要有两个方向：一个是纯软件的Simulator（软件仿真），一个是接仿真器的硬件调试。很多人上来就点那个红色的“Start Debug Session”按钮，根本没意识到自己用的是什么模式，结果出问题时很懵。

软件仿真不需要任何真实硬件，调试器直接把你的程序当成一个虚拟的Cortex-M内核来跑。它在验证纯逻辑算法、测试数学运算、看变量变化曲线时非常好用，比如PID参数调节前的仿真、字符串处理函数的正确性检查。但它有个天然短板：外设模拟能力有限。你可以在仿真里看到GPIO寄存器变高变低，但不会有真实的电平信号去点亮LED；你可以操作UART寄存器，但不会有真实的串口数据回来。所以驱动类、时序类问题一定要用硬件调试。

硬件调试则需要ST-Link、J-Link、DAP-Link这类调试器接上目标板，程序在真实芯片上运行，断点、单步、变量查看都是实时真实的。调试器通过SWD或JTAG口访问内核的调试单元（DAP），不占用用户串口，比串口打印优雅得多。

我的习惯是：逻辑算法和基础功能验证先用软件仿真，速度快、不受硬件牵绊；一旦涉及外设时序、中断响应、低功耗唤醒这类真实行为，立刻切到硬件调试。两者各有位置，不存在谁替代谁。

1.2 Debug选项卡里的关键配置

进入“Options for Target”的Debug页，左上角就是调试模式选择。很多人软件仿真时点Debug没反应，或者仿真进去后不执行main函数，多半是这里没配置好。

选择“Use Simulator”后，注意下面那几个配置项：Dialog DLL和Parameter窗口内容一定要和你的芯片匹配。比如我常用的STM32F103，设置是DARMSTM.DLL配合-pSTM32F103C8；如果芯片不匹配，仿真可能进不去或者时钟频率全错。这组DLL是Keil用来模拟芯片寄存器和中断行为的插件，Parameter参数则标识具体器件型号，两个都必须正确。

选“Use Debugger”时，下拉列表选你实际用的调试器，比如ST-Link Debugger、J-LINK/J-Trace、CMSIS-DAP Debugger。然后进入Settings，确认调试器接口是SW还是JTAG，SWD模式下只用四根线（SWDIO、SWCLK、GND、VCC）容易接，但有些板子要留意复位线是否接好，尤其你的程序把SWD引脚复用掉的时候，硬件调试可能连不上。

右边还有个容易忽略的配置：Flash Download。这里要确保添加了正确的编程算法，比如STM32F1选“STM32F10x Med-density Flash 128K”，如果算法缺失或型号不匹配，下载会报“Flash Download failed”而不是程序本身的问题。我建议下载前勾选“Reset and Run”，烧录完自动复位运行，省得每次手动按复位键。

1.3 优化等级和工程路径，这些坑趁早避开

调试中最容易让人怀疑人生的，其实是编译器优化。很多人程序下载到板子上就是“不按代码顺序跑”，查了半天发现是优化等级太高了——局部变量被优化没了、循环被展开了、延时函数被重排了。

调试阶段建议在“Options for Target”的C/C++页，把Optimization改成-O0或者Level 0 (-O0)，同时把“One ELF Section per Function”勾上，这对调试体验非常重要。-O0下变量基本都能实时查看，断点位置也准确；发布版本再改成-O2，期间切换优化等级一定要做一次Rebuild，否则可能出现代码和断点位置错位的诡异问题。

还有两个我在项目中反复强调的习惯：

• 工程路径不要有中文、空格和特殊符号。Keil对路径的处理比较脆弱，中文路径有时编译没问题，但调试时加载符号会出错。
• 工程外面的文件夹改名后，务必打开Options for Target看看Output和Listing路径，以及Utilities里的Flash算法路径是否还正确。很多人文件夹改名后工程打不开，就是这个原因。

提示：如果换了电脑或拷工程给别人，可以把.uvprojx同级的*.uvopt文件删掉，让Keil重新生成调试选项，有时候能解决很多奇奇怪怪的状态保存问题。

2. 从断点和单步开始，掌握调试的基本盘

2.1 断点的种类与使用场景

断点是调试的基础。Keil里最常用的是普通断点：在源码行号前的灰色区域点一下，出现红色圆点，程序运行到这里就暂停。

但实际项目里，单纯“跑到某一行暂停”常常不够。比如你在一个被调用了10000次的函数里找bug，每次都停下显然不现实。这时候要用条件断点：右键断点选“Breakpoint Condition”，填上触发条件，比如count == 100，程序只在满足条件时暂停。这个功能在处理循环计次、特定状态值出现时特别有用。

还有一种叫数据断点（Data Breakpoint / Access Breakpoint），不是监控哪一行代码执行，而是监控某个地址被访问。比如怀疑某个全局变量被异常修改，可以在Watch窗口右键变量选择“Set Breakpoint on Access”，一旦变量被读或写，CPU立刻停下。这类断点依赖硬件调试资源（FBP），数量有限，一般只有几个，但是在排查内存被踩、变量被意外修改时是绝杀技。

使用断点时有几个注意点：

• Keil把断点放在内部Flash里，通过“Flash断点”或硬件断点实现。Flash断点需要在Flash中打补丁，注意对Flash保护（读保护、写保护）的芯片不可用。
• 如果断点打上后显示灰色、带个小叉，说明当前无法命中，检查是不是优化导致的代码位置失效，或者该行没有实际生成代码（比如只声明没定义的函数）。
• 程序在中断服务函数里断住时，关中断临界区不要停留太久，否则看门狗或者外部喂狗超时会导致复位。

2.2 单步执行家族：Step、Step Over、Step Out、Run to Cursor

Keil调试工具栏上有几个看着差不多的按钮，用熟了能极大提升效率：

• Step Into（F11 / 按钮带向下箭头）：单步进入。如果当前行是一个函数调用，会跳进函数内部。调试自己写的子函数时用得多。
• Step Over（F10）：单步跳过。执行完当前整行，哪怕是函数调用也一口气执行完，停在下一行。当你确认某个函数内部没问题、只想看完整体流程时用这个。
• Step Out（Ctrl+F11）：跳出。如果在某个函数里陷得太深，想直接返回调用处，单步跳出是救命键。
• Run to Cursor（Ctrl+F10）：运行到光标所在行。不需要提前设断点，非常灵活。我在定位一段逻辑时，经常把光标放到可疑代码行的下一行，然后Run to Cursor，实际上相当于临时断点。

这几个键配合熟了以后，你的调试节奏会非常快。我的习惯是：先用Run to Cursor快速推进到大循环附近，再用Step Over在主干道上逐行观察，一旦注意到某个函数返回值异常，立刻Step Into扎进去看细节。

还有一个容易被忽略的组合：Disassembly窗口配合单步。在调试模式下打开View -> Disassembly Window，能看到C语言对应的汇编指令。当C代码和源代码行对不上（比如优化下断点跑飞）时，切到反汇编窗口按F10逐条指令执行，才能看到真实情况。尤其在定位硬件异常、中断向量表错误、函数指针跳飞时，反汇编窗口比源码视图可靠得多。

2.3 寄存器与变量窗口，到底在看什么

调试视图里有几个并排的窗口，新手经常忽略：

Registers窗口展示当前内核寄存器，包括R0-R12、SP、LR、PC、xPSR等。它对你的意义不仅是“看懂了好像很厉害”，而是极具实战价值的。比如程序跑飞时看PC指针跳到哪个地址，通过Map文件能反查是哪个函数；LR寄存器里保存了函数返回地址，配合Call Stack能还原调用链。

Watch窗口（Watch 1/Watch 2）是日常调试最常用的地方。在Watch窗口里输入变量名回车，就能看到变量的当前值和类型。双击Value列可以直接修改变量值——这个功能在测试不同逻辑分支时特别高效，不用重新编译下载，直接把state改成5，看程序怎么走。

关于“调试模式下如何显示结构体变量”这个问题，答案是：在Watch窗口输入结构体变量名即可，然后点击变量左侧的三角箭头展开成员。要注意两点：一是如果结构体成员显示为<cannot evaluate>，说明当前代码上下文里编译器看不到这个变量，常见的处理办法是切到该变量作用域所在的函数并执行到那一行，或者在反汇编模式下手动输入地址查看；二是输入表达式时可以用结构体名.成员名、数组名[下标]，也支持&变量显示地址。

System Viewer / Peripherals窗口按外设分组展示寄存器状态。比如打开Peripherals -> USART1，能看到SR、DR、BRR等寄存器实时值。这个窗口在调试串口通信时的价值极大：程序卡住怀疑没发送，直接看发送数据寄存器是不是空的、TXE标志位是否拉高，真相一眼就出来了。

3. 进阶：真正高效的调试技巧

3.1 Memory窗口：直接看内存，胜过一万个打印

Memory窗口（View -> Memory Windows）是以地址为中心的查看工具。调试时在Address栏输入&变量名、0x20000000或数组名，就能看到对应内存地址的原始数据。

这个窗口的妙用在两个场景：

一是确认内存内容是否被正确写入。比如DMA搬运后怀疑数据不对，直接在Memory窗口看源地址和目标地址的原始字节，立刻能看出是数据源问题还是搬运配置问题。

二是分析栈的使用情况。在Address栏输入SP（当前栈顶指针），能看到当前栈区域的内容；如果怀疑栈溢出，可以先记录下进入函数前的SP值，再看函数执行后SP的偏移，配合栈底标记（Stack Watermark）就能大致判断函数是否把栈吃透了。

窗口下方的在下拉列表可以切换显示格式：Signed/Unsigned int、Float、ASCII等。用ASCII模式能直接看到内存中的字符串内容，对验证协议帧、JSON缓冲区调试特别直观。

3.2 用Logic Analyzer当简易示波器

Keil内置的逻辑分析仪是个被严重低估的功能。在调试模式下打开View -> Analysis Windows -> Logic Analyzer，点击右上角的Setup按钮，添加你要观察的变量或寄存器地址，启动全速运行，就能看到这些信号的实时波形。

比如你要验证PWM输出频率对不对、按键扫描时GPIO的跳变顺序、一个变量在中断里的变化规律，都可以不接示波器先看个大概。逻辑分析仪支持数字信号和模拟信号显示，变量选择为“bit”时显示高低电平，选择为“int”时显示数值曲线。

我在软件仿真阶段经常用它来调试状态机——把state变量加进去，程序跑一遍后看波形，什么时候状态跳变、每个状态持续多久，一目了然。硬件调试时能不能看到波形取决于调试器是否支持实时跟踪（如CoreSight的跟踪带宽），ST-Link V2在硬件调试下看变量波形的能力有限，软件仿真下最好用。

注意：逻辑分析仪显示的时序是经过调试器采样的，不代表真实引脚上纳秒级的时序。对严苛时序问题，最终还是要靠示波器。

3.3 串口打印：printf重定向的正确姿势

串口打印虽然听起来土，但它仍然是确认程序“在干什么”的最直观手段。Keil下让printf从串口输出的标准做法是重定向fputc：

#include <stdio.h> int fputc(int ch, FILE *f) { // 以最常用的STM32 HAL库/USART为例 while ((USART1->ISR & USART_FLAG_TXE) == 0); USART1->TDR = (uint8_t)ch; return ch; }

重点来了：使用printf的浮点格式化（比如%f）时，必须勾选MicroLIB，或者准备完整的浮点库，否则程序可能编译通过但运行到printf时进HardFault，或者串口输出乱码。这个问题在Keil里非常经典。

另一个更高级的替代方案是ITM/SWO调试通道：芯片的SWO引脚通过调试器把数据送到IDE的Debug (printf) Viewer里，完全不占用串口和CPU，在打印量大、串口资源紧张时非常爽。配置方法是在Debug选项卡里勾选“Trace Enable”，然后波特率按实际调试器支持设置；代码里直接用ITM_SendChar或者重定向fputc到ITM端口。前提是你的调试器支持SWO，ST-Link V2和J-Link都支持。

3.4 看门狗导致调试中断，这个坑一定要提前规避

“keil stm32 watchdog debug”是这个热搜词背后的典型问题：程序里开了独立看门狗IWDG，调试时在断点处停住，CPU暂停喂狗，看门狗超时后把系统复位，于是断点失效、程序反复重启，调试没法进行。

解决办法有三种：

1. 调试阶段暂时禁用看门狗初始化代码。最简单粗暴，但如果看门狗相关逻辑本身就是要调的对象，就不适用。
2. 利用STM32的调试寄存器暂停看门狗计数。在Cortex-M内核中，调试接口可以通过DBGMCU寄存器控制外设时钟：设置DBGMCU->CR |= DBGMCU_CR_DBG_IWDG_STOP;后，CPU暂停时IWDG计数器也会暂停。
3. 用调试器脚本在连接后自动修改DBGMCU寄存器。

我实际项目里常用第二种，在系统初始化早期就设置好，这样调试断点不会因为看门狗复位而失效。如果你用的是WWDG，对应的位是DBG_WWDG_STOP，注意别搞混。

3.5 Command窗口：藏在深处的命令行

Keil调试界面的底部有一个Command窗口，它可以输入很多调试命令，老版本叫Command Line，现在叫Command。这里有几个常用的：

• 查看变量值：? 变量名或print 变量名，比如? state。
• 设置变量值：SET state = 3。
• 查看表达式：? ((int)(a + b))。
• 反汇编：u 0x08001000，查看指定地址的反汇编。
• 显示内存：d 0x20000000。
• 执行脚本命令：EXEC开头的一堆Flash算法操作。

如果你需要重复进行一组操作，可以把这些命令写到一个.ini调试脚本文件里，在Debug选项卡的“Initialization File”里指定路径，调试器每次连接时自动执行。比如自动初始化调试端口、设置引脚状态、加载指定外设寄存器初值，这在批量产测固件调试时非常有用。

4. 内核崩溃与HardFault，调试最怕遇到的情况

4.1 HardFault是什么，如何快速定位

嵌入式开发避免不了和HardFault打交道。程序莫名其妙进入HardFault_Handler死循环，如果不掌握定位方法，只能一行行看代码，效率极低。

定位思路其实很机械：在HardFault_Handler里打断点——注意要在断点处暂停后才能正确读取现场。程序停住后，打开Call Stack + Locals窗口，看调用栈，找到触发异常的函数的调用关系。但很多时候Call Stack显示的信息是乱的，这时要看核心寄存器。

4.2 用异常寄存器找到肇事指令

Cortex-M3/M4内核在发生异常时，会把现场保存到栈里，同时有几个系统控制寄存器记录了异常原因：

• SCB->CFSR（0xE000ED28）：可配置故障状态寄存器，由三部分组成。低16位是MMFSR（存储器管理故障），中间是BFSR（总线故障），高8位是UFSR（用法故障）。
• SCB->HFSR（0xE000ED2C）：硬故障状态寄存器，当异常无法由内核单独处理时置位。
• SCB->MMFAR、SCB->BFAR：分别记录了触发存储器管理、总线故障的访问地址。

调试时可以打开Watch窗口，输入*(uint32_t*)0xE000ED28查看CFSR值，或者使用System Viewer里的“Cortex-M Fault Status”视图。根据置位位判断故障类型：

• 如果是总线错误（BFSR）且BFAR非零，找到访问的非法地址，就能顺着代码查是谁往非法地址写数据。
• 如果是用法错误（UFSR），常见原因是未对齐访问、除零、无效指令。
• 如果是“INVSTATE”置位，通常是函数指针跳到了Thumb/ARM状态不对的地址。

另一个关键步骤是看LR寄存器和PC寄存器。当你在HardFault断点处暂停，PC指向HardFault_Handler，不是你出错的地方。但LR里保存了异常返回链接，以及异常前的栈帧。用反汇编窗口打开异常前的PC地址，就能看到触发异常的指令。Cortex-M异常时硬件会自动压栈，栈里的PC值就是触发异常的指令地址。具体做法：记录进入HardFault前的SP（栈指针），在Memory窗口查看栈顶数据，栈帧从地址SP开始按R0、R1、R2、R3、R12、LR、PC、xPSR的顺序排列，取出第7个32位字，就是异常的返回地址。

// 在HardFault_Handler中读取异常现场并保存 void HardFault_Handler(void) { volatile uint32_t *stack = (uint32_t *)__get_MSP(); volatile uint32_t fault_pc = stack[6]; // 栈帧中PC的位置 volatile uint32_t fault_lr = stack[5]; volatile uint32_t cfsr = SCB->CFSR; volatile uint32_t hfsr = SCB->HFSR; // 在调试器中查看 fault_pc、cfsr、hfsr 的值 while (1); }

4.3 栈回溯与堆栈查看

“Keil调试STM32如何查看堆栈”也是高频问题。除了调HardFault时看栈帧，日常分析栈使用量和调用深度也需要看Stack窗口。

调试模式下打开View -> Watch，或者更直接地，在Call Stack + Locals窗口右下角可以看到栈使用量。Keil还提供了一个专门功能：在Debug选项卡里有“Stack/Heap”配置，但实际运行时的栈空间使用情况要在调试时通过“View -> Analysis Windows -> Stack Usage”查看（部分版本在仿真时支持）。

如果程序反复在同一个地方进HardFault，还可以预先在内存里放“栈填充标记”：初始化时把栈区全部填充为固定值（如0xA5），运行一段时间后查看栈区有多少字节被覆盖，就能评估栈的余量。这个方法在评估RTOS任务栈大小时非常常用。

4.4 常见崩溃原因盘点

根据我多年的排查经验，硬件调试中最频繁遇到的HardFault原因基本是这几类：

• 数组越界：最常见。C语言不做边界检查，越界写可能把相邻变量、返回地址、函数指针改掉。用数据断点监控边界地址能快速定位。
• 函数指针错误：函数指针被意外改写了，跳到了非法地址，导致INVSTATE、总线错误。
• 栈溢出：函数嵌套过深或局部变量过大，栈顶越界踩到堆或其他数据。
• 访问未使能时钟的外设：比如忘了开启GPIO时钟就直接操作该GPIO寄存器，在某些系列芯片上会触发总线错误。
• 中断优先级分组不一致：多个中断源设置了不同的优先级分组方式（比如有的用NVIC_PriorityGroup_4，有的用Group_2），一旦中断嵌套出现，可能触发硬故障。务必保证全工程统一。

排查这类问题时，我建议把CFSR的值整理成一个表，对照着看很快就能缩小范围。下面是我调试时常用的速查表：

5. 在FreeRTOS和RTOS场景下的调试

5.1 裸机调试和RTOS调试的差异

裸机程序调试相对线性，断点定位像“沿着一条主线走”。但在FreeRTOS这类RTOS里，多个任务分时复用CPU，你在调试器里暂停时，CPU可能正跑在一个完全无关的任务里，源代码窗口显示的可能是别的任务，单步执行时也可能随时被操作系统切换到其他任务，初上手时非常困惑。

RTOS调试的思路要变：不是“一直往前走”，而是“看看当前停在哪”。

调试器暂停后，第一件事是看当前正在执行哪个任务。FreeRTOS的pxCurrentTCB保存了当前任务控制块指针，在Watch窗口查看pxCurrentTCB->pcTaskName就能知道当前任务名。另一个更直观的方式是看Keil里的RTOS视图：如果使用Keil自带的RTX，调试有原生支持；如果是FreeRTOS，在较新版本的MDK增加了一些RTOS感知能力，可以添加FreeRTOS的调试插件或在System Viewer里找相关信息。

5.2 一个实用组合：任务列表打印 + 调试串口

在没有RTOS调试插件的情况下，我常用的是FreeRTOS的自带统计函数：vTaskList和vTaskGetRunTimeStats。前者列出所有任务的名称、状态、优先级、栈剩余量，后者给出每个任务的CPU使用率。只要在配置里打开相关宏：

#define configUSE_TRACE_FACILITY 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1 #define configGENERATE_RUN_TIME_STATS 1 #define configUSE_IDLE_HOOK 1

然后分配一个缓冲区，调用vTaskList或vTaskGetRunTimeStats，把内容通过串口发出来。调试时看待机状态下任务CPU占用率是否异常，或者某个任务栈余量是否逼近警戒值，能非常有效地定位任务设计问题。

5.3 STM32F103C8T6移植FreeRTOS的注意点

热词里提到“FreeRTOS学习篇一:STM32F103C8T6下的移植”，这里说几个移植和调试中的反面教材。

第一是中断优先级配置。FreeRTOS要求使用NVIC的优先级分组，一般设置NVIC_PriorityGroup_4，即全部4位都是抢占优先级，不使用子优先级。如果你用了别的分组方式，FreeRTOS的临界区保护、中断屏蔽机制会失效，到底怎么回事很难查。

第二是SysTick冲突。如果裸机代码里已有的延时函数使用SysTick，移植FreeRTOS后SysTick被FreeRTOS接管，裸机延时会失效或变得极不准确。这是一个常见复现问题。

第三是内存尺寸。STM32F103C8T6只有20K RAM，默认配置堆大小如果设置过大会直接启动不起来。建议把configTOTAL_HEAP_SIZE设为( 4 * 1024 )这种保守值起步，优先保证系统能跑起来，再逐步加大。

调试RTOS系统时还有一个很反直觉的地方：在断点处暂停时间过长，FreeRTOS的自检测机制或看门狗可能把系统复位，所以RTOS调试一定要先处理好看门狗和空闲任务钩子的问题，否则明明代码没问题，调试器一停系统就重启。

6. 现场排查实录：Keil调试中的高频问题和解决思路

下面这些问题是群里、论坛里被问烂了的，我按自己的实操经验整理成速查表，每条都是自己踩过或帮人排查过的。

这里特别展开讲一个我帮别人排查过很多次的问题：下载新版本MDK后，旧工程打开编译一堆错误，或者干脆找不到芯片。原因是新MDK默认只装ARM Compiler 6，而旧工程可能是用ARM Compiler 5建的，代码里一些语法或宏在AC6下不兼容。解决办法是在Options->Target里选择正确的ARM Compiler版本，或者将AC5、AC6都装上。这个知识点在“Keil MDK 541安装时如何勾选ARM Compiler组件”这类问题里反复出现。

关于“keil community怎么下载”这类问题，我建议只从官方渠道获取安装包，避免使用来路不明的整合包或破解工具。Keil官方提供MDK评估版，功能上除了编译镜像大小限制外，日常学习和调试完全够用。License过期的问题其实也是我最不建议碰破解的领域，实际项目里因为破解工具导致IDE不稳定、调试器识别异常的例子太多了，得不偿失。

另外聊下代码规范工具的两个常见配合：ASTYLE和Cppcheck。ASTYLE可以一键格式化Keil里的源码，统一缩进、括号风格，让代码保持整洁；Cppcheck则属于静态分析工具，能在编译前发现数组越界、空指针解引用、未初始化变量等问题。这两个工具配合Keil自带的编译器警告，能把很多低级错误挡在调试之前，从根源减少Debug工作量。Astyle的使用方式很简单，在命令行里指向源码文件即可：

astyle --style=allman --indent=spaces=4 main.c

更讲究一点的话，可以在Keil的User页面加一项“After Build”命令，编译完自动跑Astyle和Cppcheck，把检查结果输出到Build Output窗口。这种自动化流程一旦养成习惯，代码质量会明显上一个台阶。

7. 写在最后的几点体会

我从用Keil C51到现在的MDK，调试方法一直在变，但核心思路始终是那句“先缩小范围，再定位细节”。初学者最容易犯的错是拿到问题就怀疑“某个玄学原因”，然后疯狂改代码。而调试工具给我们的其实是一个“看清事实”的窗口：寄存器什么值、内存什么内容、程序停在哪一行——事实清楚了，问题往往自己就浮出了水面。

如果你想把这些调试手段变成肌肉记忆，我的建议是找一块最普通的开发板，故意写几个bug练手：一个数组越界、一个栈溢出、一个非法函数指针，然后用本章讲的方法把它们一个一个调出来。做过一遍之后，后面真正项目里遇到问题时，你会发现自己不再慌了。

最后再分享一个小技巧：当你彻底解决一个问题后，花五分钟把原因和定位过程记在工程目录下的DEBUG_NOTES.md里。别嫌麻烦，这些记录就是你一年后最宝贵的经验库。Keil的调试功能还有很多高级玩法，比如脚本化初始化、跟踪日志、性能分析器等，这篇文章讲的算是把主干走通，剩下的一步步探索，反而更有意思。