去年在客户现场遇到一件事一台已经稳定运行了三个多月的控制板突然偶发死机上电一小时后面板卡死但串口还在输出整机也没掉电。客户要求不能断电复现因为触发条件和现场一个外部传感器时序强相关一复位就要再等很久。那会儿我才真正体会到Keil调试器最大的隐藏技能不是“复位从头跑”而是连到一个还在运行的程序上把现场原封不动地抓住。这篇文章就把这套方法论完整写出来为什么需要热调试、Keil里要怎么配置、实操时怎么看现场、以及我在真实事故里的一次完整复盘。1. 为什么非要连正在跑的现场三类典型场景与调试器的默认行为1.1 那些不能断电复现的故障现场很多人习惯的调试方式是程序跑挂了按一下复位重新开始加日志重现问题。这个思路对付确定性BUG没问题但有三类场景必须直接连到运行中的程序上否则你永远抓不到真相。第一类是偶发性故障。程序可能跑几十个小时才崩一次崩溃条件和外部模拟量、通信报文的特定序列、某个外设的中断抢占时序强相关。一旦复位这些条件全部清零你可能再等一个星期也复现不了。第二类是设备一旦停机就有经济损失的现场比如产线设备、医疗仪器或者带载运行的电机控制板你不能为了调试把整个流程停掉。第三类是程序“半死”状态——不是完全复位而是陷入死循环、HardFault或者某个中断里出不来系统还在供电外设还在运行RAM里的现场数据还在这时候只要你不断电、不复位就有机会把它抓住。这些场景有一个共同点你需要在不中断系统供电、不复位CPU的前提下让调试器介入进去暂停、观察、分析。这就是“调试正在运行的程序”的核心价值。Keil MDK完全具备这个能力只是它不像GDB那样有一个独立的“attach”按钮很多工程师压根不知道原有的启动调试流程已经默认做了太多破坏性动作。1.2 按下调试按钮后Keil到底做了多少“破坏性”动作默认情况下你在Keil里按CtrlF5启动调试会话它会执行一套相当重的动作链初始化调试器、连接目标芯片、复位内核、擦除并下载程序到Flash、然后执行到main函数暂停。整个过程对一块正在运行的板子来说就是一次彻底的“暴力打断”。这里有个根因Keil MDK的设计初衷是“从开发阶段陪伴你调试固件”它默认假设你要从头开始运行这个程序所以帮你把复位、下载、运行到main这些脏活都干了。对开发板调试这当然舒服但你要是把同一套配置用在现场维护上一按调试按钮芯片被复位、Flash被重写、RAM清零所有现场证据灰飞烟灭。更隐蔽的是“Update Target before Debugging”这个选项在Options for Target - Utilities页面里默认是勾上的。它的作用是每次启动调试前自动调用Flash Download算法哪怕你的代码根本没改动也会触发擦写流程。很多人在现场“热调试”失败不是不会操作而是程序刚被调试器偷偷复位了。还有个选项叫“Run to main”勾选后调试器会在复位后执行到main入口暂停这会绕过程序初始化逻辑把问题现场直接冲掉。1.3 热连接的本质连接、暂停、不丢失现场所谓“调试正在运行的程序”在Keil的语境里本质就一句话启动调试会话但不复位、不下载由调试器接管目标并暂停然后你可以在当前现场做任何常规调试操作。它的原理是调试器通过SWD/JTAG接口的调试访问端口DAP访问内核。DAP本身是独立于CPU运行的调试基础设施只要CPU还在供电、时钟还在跑、调试接口没有被禁用调试器就能直接发指令让内核暂停Halt。暂停后CPU的寄存器、栈、外设寄存器、内存全部保持原样你看到的PC指针就是故障发生时的真实位置。看完之后你还可以让程序继续跑或者单步甚至修改内存和寄存器值来“临场挽救”。这里要澄清一个常见误解热连接不是“不用接线”也不是“无线调试”而是“不打断系统运行的前提下建立调试会话”。它和GDB的attach操作是一个思路只是Keil把它藏在了一系列启动配置后面。2. 把Keil的调试启动行为“掰正”三个关键配置开关2.1 Debugger Settings里的Connect与Reset两个下拉框决定生死打开Project - Options for Target - Debug在右侧勾选你实际使用的调试器然后点旁边的Settings按钮以J-Link为例进入调试器设置对话框。在Debug页面里你会看到两个决定热调试成败的下拉选框Connect和Reset。Connect选项有三个常见值Normal、Under Reset、Pre-reset。Normal表示调试器直接通过SWD/JTAG连接目标如果目标正在运行调试器会把它暂停下来不做任何复位。Under Reset表示在复位引脚拉低期间建立连接用于目标已经死机、时钟异常或者SWD引脚被复用导致无法正常连接的情况这种方式通常会破坏现场不推荐用于热调试。Pre-reset则是在连接前先触发一次复位这是最破坏现场的一个选项热调试千万要避开。Reset选项里Normal表示连接后不执行任何复位动作这是热调试的核心。Core Reset表示只复位内核不复位外设Reset and Run则是复位后全速运行这两种在故障现场都会把现场冲掉。只要你想连一个正在运行的程序Connect选NormalReset选Normal这两个选择缺一不可。2.2 关掉自动下载Update Target before Debugging和Flash Download很多人在Settings里改对了Connect和Reset结果一启动调试程序还是被重新烧录了问题就出在Utilities页面。打开Options for Target - Utilities你会看到一个勾选框叫Update Target before Debugging。把它取消掉。这个选项的作用是每次启动调试会话前自动调用Flash Download工具把当前工程编译出的固件下载到目标Flash。取消之后调试器启动会话时就不会再碰Flash。顺手检查一下Flash Download配置点击右边的Settings按钮如果Configure Flash Menu Command是激活状态会看到Programming Algorithm、Erase Full Chip、Erase Sectors等选项。这里你要确保没有任何“启动调试即擦除”的配置尤其是Erase Full Chip一旦触发整个程序区被抹掉现场只剩一个空芯片。虽然取消Update Target before Debugging后一般不会再触发但我见过老版本工程在调试启动时仍然执行烧录流程所以最好把Flash Download里的“Erase Full Chip”改为“Erase Sectors”或干脆不勾选。2.3 Run to main与Load Application at Startup的正确选择回到Options for Target - Debug页面除了调试器选择还有两个和启动行为强相关的勾选框Load Application at Startup和Run to main。Load Application at Startup建议保留勾选。它的作用是在启动调试会话时把当前工程的.axf文件加载到调试器的符号表里这样你才能在Watch窗口输入变量名、在源码窗口看到行号对应关系。它加载的是符号信息不是烧录代码对Flash没有任何影响所以热调试时勾上它是有利的。Run to main则必须取消勾选。这个选项的含义是调试器连接并暂停目标后再执行一次复位并全速运行到main函数入口。热调试时你希望停在当前PC位置而不是回到main所以这个选项一定要关掉。如果你是从零开始调试代码保留它很方便但现场抓BUG时它就是你最大的敌人。2.4 需要更精细控制时Initialization File脚本有些场景光靠配置还不够。比如你希望连接后程序不要暂停太久想让它继续全速运行只等某个断点触发或者你想在连接后自动拉高/拉低某个GPIO来喂外部看门狗又或者你要预先设置好数据观察点。这时候可以在Debug页面的Initialization File框里指定一个调试脚本。初始化脚本实际上是一系列Keil调试命令的文本文件启动会话时会逐行执行。举个例子如果我想让调试器连接后自动加载符号、不停在当前位置、继续运行可以写LOAD %L GLOAD命令加载当前工程的.axf符号文件%L是Keil的内置占位符代表当前输出文件。G命令让程序恢复全速运行。这样启动调试会话后程序保持在原有运行状态等你之后按下停止按钮或者某个断点命中再暂停。脚本里还能设置断点和观察点比如BS 0x08001234 WD 0x20001234, 0x00000002, 0x00000000BS设置地址断点WD设置数据观察点。启动后一旦满足条件调试器会自动暂停。我通常在需要长时间监视某个变量写操作时用这个脚本比手动设置更可靠也不会因为启动过程中的短暂暂停错过关键时序。注意脚本别加RESET或LOAD带烧录参数的命令否则前功尽弃。3. 挂载到运行中程序的完整实操流程3.1 硬件层面的准备调试器、供电、线缆和固件版本配置在软件里但成败往往在硬件。热调试前先确认四件事。第一目标板必须独立供电调试器不要充当供电来源。很多调试器尤其是ST-Link能从板子取电或反向供电但热调试时电流波动和地电位差容易导致连接不稳最好让板子用自己的电源调试器只走SWD信号线。第二SWD线尽量短。现场情况下板子可能在机箱里调试器到板子之间的杜邦线如果超过20厘米高速SWD信号容易受干扰连接时会频繁报错。我的经验是SWD在不超过1MHz的情况下线长控制在30厘米内问题不大但速度越高越关键2MHz以上尽量用屏蔽线或排线。第三确认板子上SWD引脚SWDIO/PA13、SWCLK/PA14没有被程序在运行过程中重新配置成普通GPIO。如果产品量产时把这几个引脚复用为按键或LED程序一跑起来调试口可能直接物理断开这时候任何连接方式都白搭。第四也是很容易忽略的一点确保工程当前编译的固件版本和现场Flash里跑的固件版本一致。如果现场固件是三个月前烧的你手里是加了新功能的代码连接后Watch里的变量地址、结构体布局全是对不的你看到的数值没有意义。我在现场干过这种蠢事连接成功但所有变量都像垃圾数据排查半天才发现工程版本和现场固件对不上。3.2 启动调试会话从按键到看见现场硬件就绪、配置改好之后操作路径很简单按CtrlF5或者点击Debug菜单下的Start/Stop Debug Session。这时你会注意到和平时调试不一样Command窗口的输出里不会出现下载进度条也不会看到复位日志取而代之的是一系列调试器连接信息最后一行通常会显示Program stopped或类似提示告诉你目标已经被暂停在当前指令位置。停顿的位置就是程序“临终现场”的PC指针。我建议你先把PC寄存器的地址记下来趁热在Disassembly窗口按这个地址回车看看停在什么指令上。这一步能快速判断程序死在哪一类代码里如果停在某个外设中断处理函数的某条访存指令基本是总线错误或未对齐访问如果停在0xFFFFFFxx区域往往是栈溢出后PC彻底跑飞如果停在一个while(1)死循环里问题可能是某个标志位永远等不到置位。启动时有几个常见报错值得提前了解。“Cannot access target”表示调试器根本连不上先查SWD接线、供电、复位线是否被拉死再检查RDP读保护。“Target not halted”说明连接建立了但无法暂停内核常见原因是时钟异常或芯片进入了STOP模式这种时候可以切换Under Reset方式尝试但要做好现场丢失的准备。3.3 暂停之后的现场勘察寄存器、调用栈和内存程序停在现场之后重点从“怎么连上”切换成“怎么看懂”。调试窗口的用法和平时一样但顺序有讲究。先看Registers窗口。重点关注PC、LR、SP和xPSR四个寄存器。PC是当前指令地址前面说过要看。LR的意义在热调试时更特殊如果LR的值是0xFFFFFFF9或0xFFFFFFFD说明当前处于中断/异常上下文这个LR叫EXC_RETURN不是真实的返回地址它的值告诉你发生异常时用的是MSP还是PSP。如果LR是一个普通RAM地址说明程序是在普通函数调用链上被暂停的这时候Call Stack窗口比较可信。再看Call Stack Locals窗口。裸机调试时这个窗口能显示函数调用链但HardFault场景下经常显示不出来因为栈已经被异常压栈搞乱了。这时候要手动翻内存。打开Memory窗口输入SP寄存器指向的地址你会看到Cortex-M硬件自动压栈的8个字顺序依次是R0、R1、R2、R3、R12、LR、PC、xPSR。也就是说从SP地址往上第8个uint32就是触发异常那一刻的PC第9个是异常前的LR。把这两条数据拿出来去Disassembly窗口一看异常源头基本就锁定了。Watch窗口也不要浪费。在暂停状态下添加一个结构体变量展开成员查看当前值能快速判断业务逻辑是否已经跑偏。但要小心如果变量被编译器优化到了寄存器里暂停在非当前执行点可能读不到值显示 这时候去Registers窗口看对应的寄存器或者干脆把优化等级调低重新编译一版专门用于诊断。3.4 看完之后怎么恢复续跑与断开会话现场勘察完毕有两种收场方式。如果你判断问题是偶发的当前现场不足以确定根因想让设备回到运行状态继续观察直接按F8或点击Run按钮让程序全速运行即可。它会从暂停的指令继续执行不会重启、不会复位设备和恢复运行前唯一的区别是被暂停了一小段时间。如果你的程序里有外部看门狗这个暂停时间可能已经导致看门狗超时复位——所以我说热调试前最好先确认看门狗形态或者用调试脚本在暂停瞬间先喂狗。如果你已经定位了问题想改代码修复那就正常停止调试会话改代码重新编译烧录。但如果你是现场临时救急不想改代码重新烧录毕竟重新烧录意味着设备重启可以尝试在调试会话里直接修改内存或寄存器来绕过故障点。比如把某个状态变量在Memory窗口里强制改成正确值或者把PC寄存器改成某个恢复函数的入口地址再按F8继续运行。这种操作风险很高程序各模块的状态可能不一致但紧急情况下我确实用它救回过产线让设备撑到了下一次维护窗口。4. 一次HardFault事故的热调试复盘从异常现场挖到空指针4.1 事故现象与“必须现场抓”的理由这是我自己项目里的教训。设备是一台带触摸屏的控制板MCU是STM32F407跑裸机程序通过UART和上位机通信数据处理在DMA中断里完成。故障很诡异机器上电后有时几小时、有时一天才死一次死亡前画面卡住串口停止输出但面板背光还亮着系统没有完全断电。一开始按照老思路加串口日志、复位重现结果在实验室里跑了两周一次没复现。后来去现场看才发现故障可能和上位机一个很特殊的发送时序有关上位机每隔10分钟会发一包长报文如果恰好在另一个外部信号触发的中断响应窗口内到达UART DMA描述符更新就会和用户程序的缓冲区清理逻辑撞上。这种时序在实验室完全模拟不出来必须拿到现场正在运行的程序最终停在哪里。幸好设备没有锁机运行中SWD接口还能访问。我用前面说到的配置方式Connect Normal、Reset Normal、取消自动下载把调试器挂到了正在跑的程序上耐心等它再次死机。故障出现后切换到程序里对应的调试会话直接看现场。4.2 热连接后的第一眼HardFault_Handler连上之后Command窗口提示停在HardFault_Handler。这在热调试里最常见不过MCU遇到非法访存、未定义指令、总线错误都会跳到这里。但HardFault_Handler本身不告诉你是哪里触发的它只是个终点真正的起点要靠寄存器反推。打开Fault Reports窗口在Peripherals - Core Peripherals里我看到的故障状态是CFSRConfigurable Fault Status Register的PRECISERR位被置位BFARVALID也是1BFARBus Fault Address Register指向了一个外设地址附近。这说明是一次精确的数据总线错误——CPU执行了一条访存指令访问的地址非法在指令执行时立刻触发异常。这一步明确了两件事第一问题出在数据访问而不是指令错误第二出错的地址是某个外设寄存器区域大概率是UART或DMA相关的地址空间。接下来就是要找是哪条指令、哪个函数动了这个非法地址。4.3 异常压栈顺序还原真正的PC与LRHardFault_Handler里常规的Call Stack窗口是没用的因为栈已经被硬件压栈打乱。这时手动栈回溯打开Registers窗口记下当前SP的值。我的现场中MCU使用的是MSP因为LR是0xFFFFFFF9说明异常发生在线程模式且用的是主栈指针。如果LR是0xFFFFFFFD就得去读PSP再按PSP回溯。在Memory窗口输入SP的地址往上数8个字。硬件压栈顺序固定偏移0x00是R00x04是R10x08是R20x0C是R30x10是R120x14是异常前的LR0x18是异常前的PC0x1C是xPSR。我把0x18位置的数据复制到Disassembly窗口按回车跳转看到的那条指令就是触发异常的指令。现场那条指令是一条对有偏移的地址进行写操作STR指令目标地址计算后在BFAR给出的区域内。再回到0x14位置的LR这个值能告诉我触发异常前CPU正在哪个函数里执行。PRECISERR场景下这个LR通常是故障函数的上一层调用者结合源码窗口能把整个调用链拼起来。最终锁定的位置在UART接收的DMA处理回调里一个指向缓冲区结构体的指针在某条状态路径下被置空但DMA完成中断仍然通过另一个全局句柄调用了这个回调回调里直接对指针成员做写操作踏进了非法地址。4.4 修复方案与48小时验证修复其实很简单在DMA中断处理函数入口对回调指针做空判断并且修改状态机切换逻辑确保缓冲区清理操作和DMA描述符更新在临界区内完成。具体到代码就是增加一个开关中断的保护区间把原来的“先清标记再判断”改成“先确认DMA空闲再清缓冲区”。重新编译烧录后我在实验室模拟了“长报文恰好撞上外部中断”的时序连续跑48小时没有死机。现场设备保持原网络拓扑又跑了三个多月再也没出现面板卡死的现象。这次复盘最有价值的点不在于“修了个BUG”而在于整个定位过程几乎全程没有打断过系统运行客户设备没有断电、没有复位程序在运行中被我们抓了个正着。如果按老办法复位重跑这种偶发时序问题靠日志基本不可能定位。5. 运行态调试的边界与组合拳别等死机了才开调试器5.1 三个随时会让调试器掉线的元凶看门狗、低功耗、时钟异常热调试不是万能的有几类情况会让调试器在连接后立刻掉线我在项目里都踩过。第一是看门狗。内部IWDG一旦启动除非硬件复位否则无法关闭。调试器Halt暂停程序后看门狗计数器可不管你照样倒数几百毫秒后直接把芯片复位调试会话随之断开。要命的是你刚看到的现场瞬间没了。应对办法如果量产板有看门狗使能跳线调试前先断开没有跳线的话在调试脚本里可以考虑不支持因为IWDG没法软件关闭只能用硬件手段。外部看门狗同理暂停期间没人喂狗就会复位。我的经验是热调试前先查原理图看有没有办法临时拉高/拉低喂狗信号哪怕用一根飞线搭到某个GPIO上写个脚本自动喂狗也行。第二是低功耗模式。MCU进入STOP或STANDBY模式后内核时钟停止SWD接口可能在大部分芯片上仍然可以唤醒并访问但连接的可靠性差很多而且部分型号在STOP模式下调试口根本不响应热连接。有些STM32系列提供了DBGMCU寄存器可以在进入低功耗前设置DBG_STOP位让调试时钟在暂停时保持运行。如果在设计阶段就知道以后可能要热调试这部分一定要提前做。第三是时钟异常。程序跑飞后如果外部晶振停了或者PLL配置被意外改写内核完全没有时钟SWD连接会表现为“能识别IDCODE但无法Halt”。这种时候你用Under Reset方式连接可以建立会话但目标是复位状态不是运行现场只能算是“死机救援”而不是“现场调试”。我建议面对这种场景时放弃热调试幻想直接断电后查启动时序或者靠硬件复位把芯片拉回到可连接状态再分析。5.2 不打断运行也能拿数据ITM/SWO日志、RTT和数据观察点热调试能解决“事后抓现场”但更高级的姿势是“事中不打扰系统”也能拿到数据。Keil生态里我最常用的三招是ITM/SWO、J-Link RTT和数据观察点。ITMInstrumentation Trace Macrocell是Cortex-M内核自带的追踪单元配合SWO引脚和调试器可以实现运行时的printf输出。用Keil的方式是开启Debug (printf) Viewer窗口重定向fputc到ITM端口0在调试器设置里把SWO/Trace功能打开。程序全速运行时printf的输出实时显示在Debug (printf) Viewer里不占用UART、不打断程序、对时序影响极小。不过这个功能需要调试器的SWO引脚连接到MCU的SWO/Trace引脚ST-Link的部分型号、J-Link的SWO模式都可以纯CMSIS-DAP一般不行。RTT是SEGGER J-Link提供的另一种运行时通信手段本质是通过SWD接口周期性轮询目标RAM里的一个控制块来实现高速双向数据传输。它不依赖SWO引脚把日志输出重定向到SEGGER_RTT_printf之后运行中也能看到数据而且支持在运行时修改参数。这块在Keil里集成稍微麻烦一点要添加SEGGER的RTT源码但一旦跑通热调试时比串口日志舒服太多。数据观察点Data Watchpoint则是真正的“内存哨兵”。在调试会话里你可以在Watch窗口的右键菜单或Debug - Breakpoints里设置某个内存地址的读写条件比如“地址0x20001234被写入时暂停”。程序全速运行时只要那块内存被任何代码写入调试器立刻触发暂停然后你就能看到是谁在动它。这个功能对数组越界、变量被意外篡改这类问题极其有效我甚至用它查过一次莫名其妙的全局结构体被改写最终定位到是别的数组溢出踩了它的内存。5.3 不同调试器的热连接行为差异不是所有调试器在Keil里的热连接表现都一样我做了一个对照表方便你按手里的硬件选择策略。调试器热连接表现SWO/ITM支持RTT支持Keil中Connect选项J-Link连接后自动Halt目标可续跑配合Ozone可做更完善的attach完整支持完整支持Normal / Under Reset / Pre-resetST-Link连接后自动Halt目标可续跑SWO需要V2及以上版本部分支持V2支持ISO 7816? 实际看型号官方不支持可借助第三方Normal / Under ResetCMSIS-DAP连接后Halt目标基本热连接可用一般无无官方方案Normal / Under Reset实际体验差别最大的是SWOJ-Link在500kHz到几MHz的SWO速度下很稳定ST-Link虽然能开Trace但引脚占用和频率兼容性经常要折腾。如果你常年要在运行态调试中打日志我建议直接用J-Link省心很多。另外还有一点Keil本身在热连接后会默认打开一个“Load”动作如果目标Flash里的程序和你当前axf不一致它会提示校验失败或直接忽略符号。所以再次强调现场连接前务必确认固件版本对应关系最好在工程里保留每个发布版本的.axf和.map文件按软件版本号分目录存好。这比调试器选型更加重要。5.4 把调试能力做进产品预留接口和诊断信息说了这么多操作层面的东西最后说点设计层面的经验。我在新项目里会主动做三件事保证以后现场出问题时有路可退。第一SWD信号尽量引出到独立的调试座不和其它功能复用。即便被迫复用也要保证启动后的前500ms内不改变引脚功能给调试器一个窗口期完成连接。第二程序里内置一个“运行状态快照”机制把任务状态、关键变量、最近的中断触发次数、通信错误计数打包存储到RAM的固定区域通过调试器的Memory窗口随时可读。这个快照不需要UART也不需要额外硬件只需要你在代码里维护一个结构体把调试信息写进去。第三如果产品允许做一个“故障不变重启”的选项——发生致命错误时先把现场数据保存到Flash再进入低功耗或等待调试器而不是直接看门狗复位。这一条在工业设备上尤其重要很多时候“死机”本身就是最重要的信息。我自己现在的做法是代码里预留一个编译开关开发阶段打开调试钩子量产固件默认关闭。但就算关闭RAM里的快照结构体也始终保留地址固定不会因为编译器优化被挪走。这样到了现场无论程序是否还在运行只要接上Keil就能在几秒钟内知道系统在哪个状态、最后一次通信是什么时候、有没有异常中断。这套做法让我把“看命式查BUG”变成了“有据可查的例行排障”比任何调试技巧都值钱。