1. 调试之前先把环境与连接理顺做嵌入式开发的人几乎都绕不开Keil。不管是刚入门拿STM32点灯还是项目里调GD32、瑞萨、NXP的片子打开uVision的第一件事往往不是写代码而是把“能不能正常跑起来、能不能正常断下来”这条链路先打通。这篇笔记我按自己的实操习惯把Keil程序调试从头到尾捋一遍里面很多步骤和坑都是这些年一个个踩出来的。先说结论Keil的调试体验很大程度取决于工程配置和仿真器连接而不是代码本身。很多新手在写代码阶段没问题一进Debug模式就懵界面上一堆窗口不知道看哪个或者点了单步执行程序直接“飞了”其实多数是配置没到位。1.1 仿真器选型与Target配置调试之前首先得确定用哪种调试方式。Keil MDK支持两大类软件仿真和硬件在线调试。软件仿真适合纯逻辑层面的验证比如算法流程、状态机跳转不需要接板子直接模拟Cortex-M内核的指令执行硬件在线调试则是通过ST-Link、J-Link、DAP-Link这类调试器连目标板实时读取芯片内部寄存器、Flash和RAM内容这也是日常开发最常用的方式。在uVision5中配置入口在Options for Target快捷键AltF7里的Debug选项卡。左侧选Use Simulator就是软件仿真右侧选Use并配上调试器型号就是硬件调试。初次使用很容易忽略一个点选好调试器之后还要点旁边的Settings进入Flash Download页把编程算法Programming Algorithm加上。芯片型号不同Flash算法也不同。比如STM32F103C8T6要加的就是STM32F10x Med-density 128K Flash如果这里空的下载时会报No Algorithm found或者Failed to download程序根本烧不进去更别说调试了。另外在Utilities选项卡里记得勾选Update Target before Debugging这样每次进入调试之前会自动重新编译下载避免改了代码却忘烧录导致调试的和看的不一致。1.2 编译器版本、优化等级与调试信息的联动这个坑我吃了不少亏。Keil MDK从5.36开始把Arm Compiler 5标记为“legacy”新装的Keil默认只有AC6Arm Compiler 6。AC5和AC6对语法的宽容度差异很大尤其是一些老的工程用AC6编译直接几十个error基本都是语法兼容问题。所以拿到一个老工程先看编译日志里有没有#pragma相关的报错或者查查工程里是否用了AC5特有的关键字。如果需要AC5一个特别容易踩的坑是在安装Keil时没有勾选组件。搜索词里提到的“keil mdk541安装时如何勾选arm compiler组件”就是这个场景。安装包运行到Select Components那一步展开MDK Core下的Arm Compiler节点里面会有Arm Compiler 5和Arm Compiler 6的选项两个都勾上后面切编译器版本才能顺利。再就是调试信息与优化等级。Release模式下默认开了-O2甚至-O3变量会被优化掉断点打在某一行可能直接失效Watch窗口里看的变量显示cannot evaluate这些都是优化“搞的鬼”。所以我调程序基本固定用-O0或-O1Debug模式下别开高优化这是嵌入式调试的第一原则。要开优化等程序稳定之后再开然后重点回归测试。2. 调试窗口怎么用才算真会用进了调试模式uVision顶部会多出一排调试工具栏左侧的Project窗口也自动变成Regs寄存器页签。初学者最容易犯的毛病是只会点一个RunF8看现象断不下来、不会看变量跟没进调试没什么区别。我建议把调试功能拆成几个层次来掌握。2.1 寄存器窗口先看它再猜代码很多人一上来就盯Watch窗口看变量其实调试硬件程序最快的信息源是Regs窗口。里面分Core Registers和Peripheral Registers两部分。内核寄存器里的PC程序计数器和LR链接寄存器尤其重要。PC告诉你CPU当前执行到哪条指令LR则记录函数返回地址。程序跑飞的时候PC值直接变成0xFFFFFFFF或者一个不在Flash范围内的地址这时候第一反应不应该是看业务逻辑而是检查LR指向的调用关系看看是不是哪个函数指针被写坏了。外设寄存器窗口则可以免去翻参考手册的麻烦。比如调UART直接在Peripheral菜单下打开USART1里面的SR、DR寄存器的实时值一目了然。查波特率配置、查TXE标志位有没有置位比在代码里加Printf快多了。注意一点看外设寄存器之前必须保证外设时钟已使能否则读出来全是复位默认值容易误判。2.2 内存窗口与反汇编配合发现问题的最底层手段C语言写的逻辑跑到最后CPU执行的还是汇编。Disassembly窗口会在调试时自动弹出与源代码一一对应。高级别优化的坑、函数指针乱跳、栈被踩坏的问题光靠看C代码很难定位这种时候必须看反汇编。双击反汇编窗口中的某条指令可以打断点比在C代码行打断点更精确尤其适用于中断服务函数里的时序调优。Memory窗口快捷键CtrlAltM可以按字节、半字、字来查看指定地址的内容。定位数组越界、DMA搬运结果、协议栈接收缓冲区都是在这个窗口直接敲地址查看。比如我想看一个环形缓冲区的数据直接在Address栏输入buf[0]回车后就能看见连续内存里的原始值。配合右下角的Memory Map标识还能看出当前地址属于Flash、SRAM还是外设区心里更有底。2.3 Watch窗口与条件断点的组合玩法Watch窗口是大家用得最多的但真正用好的人不多。除了直接全选变量右键Add to Watch之外有两个高级用法非常实用。第一在Watch窗口的Name列直接输入表达式。比如想看结构体变量g_tSensor的成员temperature直接输入g_tSensor.temperature不用一层层点开树形节点。对于结构体指针输入ptr-field同样有效这比展开一棵大树效率高得多。第二格式化显示。右键某个变量可以选择按十进制、十六进制、二进制、浮点等形式显示。我调试电机电流时习惯把电流环的q轴电流变量设成浮点显示单位是安培一眼就能看出波形趋势。另外Keil从5.x版本开始Watch窗口对结构体变量支持很好像热搜词提到的“调试助手如何显示结构体变量”直接在Watch里输入结构体名下一层自动展开所有字段不用像老版本那样手动逐个添加成员。条件断点是救命的工具。比如循环10000次之后才出错普通断点要按F5按到手抽筋。在断点行右键选择Breakpoint Properties在Expression里输入条件比如i 9999再勾选Condition这样只有当i等于9999时才停下来。还可以在Command里输入调试命令比如printf(i%d\n, i)甚至设置Log输出到文件。这在分析数据变化轨迹、定位偶发故障时效率极高。2.4 堆栈窗口排查HardFault的一把钥匙热搜词里有一条“keil 调试stm32如何查看堆栈”这问题非常典型。程序跑飞或者进HardFault之后第一件事不是看代码而是看Call Stack Locals窗口快捷键CtrlF11。这个窗口会显示当前的函数调用链每一层函数的局部变量也能展开查看。如果这个窗口显示的内容明显不对比如调用链出现异常地址或者局部变量值完全不合理十有八九是栈溢出了。配合View - Stack菜单看栈的使用量可以确认是不是接近栈顶。在启动文件里Stack_Size EQU 0x00000400只是默认配置实际工程中任务栈、中断嵌套、printf的缓冲区都吃栈RTOS下还要给每个任务单独分配栈。建议在调试初期就把启动文件里栈改大一点比如0x00001000先把功能调通再优化栈的大小。另外看门狗在调试模式下也是个麻烦事Keil里可以勾选Debug选项卡里的Run main() until main还有Load Application at Startup等选项但看门狗一旦超时复位调试器会断在线程复位那一段导致你误以为代码卡死了。此时在Options里把Watchdog相关的选项临时打开如果芯片支持调试期间暂停看门狗或者直接在代码里用一个宏关闭看门狗比如#define WDT_DISABLE_DEBUG 1调试完再打开。这是一个很实用的经验。3. 调试过程中最常撞上的报错与排查调试不只是“能进调试模式”更多时间是在跟报错较劲。Keil的报错五花八门但归类下来无非几个层面编译期、烧录期、运行期。3.1 编译期错误Error L6218E与R6002几乎每个用Keil超过三个月的人都会见到L6218E: Undefined symbol这行报错意思是链接器在某个目标文件里找不到某个符号的定义。最常见的原因有三个一是写了函数声明但函数体在别的.c文件里而该文件没有被加入工程二是符号定义在别的文件里但那个文件被#if 0注释掉了三是函数名拼写不一致尤其大小写问题。排查方法很直接在工程里全局搜索CtrlShiftF这个符号看看它到底定义在哪里。如果定义在另一个.c文件里确认这个文件在Project窗口中存在且没有被排除右键文件看看Options for File里有没有勾Include in Target Build。另外一个比较冷门的报错是Error: R6002这是编译器或者调试器运行时堆栈溢出导致的常见于老版本的Keil或者系统临时目录权限异常。解决办法是先清理一下工程Project - Clean Target再重启Keil如果还不行把工程挪到纯英文路径下避免中文目录和空格造成的编译环境异常。我遇到过几次最后发现是电脑用户名是中文导致%TEMP%路径含中文编译器某些临时文件写不进去。重装到英文用户名下就正常了。3.2 烧录期错误跟Link、Flash Algorithm较劲No ULINK Device Found是个非常高频的报错。第一次见到时我心里也是一紧后来发现大多是以下几类原因ST-Link的USB驱动没装好设备管理器里显示未知设备调试器连接线太长或者接触不良目标板供电不足调试器无法稳定枚举Settings里选错了调试器型号或接口协议SW/DAP vs JTAG。按照排查的优先级我先看设备管理器里调试器有没有被识别再检查接线最后再看Keil的Settings界面。这里有一个细节如果板子支持SWD模式尽量用SWD因为它只需要4根线SWDIO、SWCLK、GND、VCC比JTAG省事也不容易接错。还有一个经常被忽略的点目标板必须在下载前处于上电状态且调试器与目标板供地必须共地。有几次我拿笔记本电脑不接地供电板子用另外的电源适配器两边地电位不一致导致调试器死活连不上接上共地线立刻就好。Error: Flash Download failed - Cortex-M4这类错误90%是Flash Download页里没有配置编程算法或者选的算法和芯片型号不匹配。比如GD32F303虽然兼容STM32F103的部分引脚但Flash算法不能直接套用要去下载对应厂商的PACK包并选择正确的算法。这也是热搜词里“gd32在keil”反复出现的原因GD32的PACK需要去GigaDevice官网下载安装包是一个.pack文件双击即可安装到Keil。安装完成后在Device选项卡里选择对应的GD32型号再重新添加Flash算法。3.3 运行时错误程序跑飞、进HardFault的排查套路程序能烧进去但一跑就死这里给一套我常用的排查流程。第一步暂停程序看PC指针跑到了哪里。如果PC值落在0x08000000的Flash范围之外基本是肯定出问题了切到Disassembly窗口看PC所在区域的汇编代码判断是从哪个函数跳过去的。第二步打开Fault Reports窗口部分版本在Peripheral菜单下看CFSR、HFSR、MMFAR、BFAR这几个寄存器。CFSR里的UNDEFINSTR位如果置1说明CPU执行了一条未定义指令通常是函数指针被写坏跳到了数据区域IBUSERR位如果置1说明总线错误访问了非法地址。根据这些状态位能精准定位问题类型。第三步如果确认是栈被踩坏导致的HardFault可以在HardFault_Handler里加一个全局断点在断点处查看MSP指针的值然后用内存窗口搜索栈区里存的返回地址。这招虽然麻烦但能找出谁把栈写穿了。还有一个高频坑是中断优先级分组混乱。Cortex-M内核里NVIC_SetPriorityGrouping的设置在工程初始化时必须统一如果一部分代码用PRIGROUP_4另一部分用PRIGROUP_2RTOS调度和中断嵌套会完全错乱表现出来就是程序莫名卡死怎么调都找不到原因。查这个问题的技巧是把每次设置中断优先级分组的语句全部搜出来确认全工程唯一且一致。4. 用第三方工具补上Keil的短板Keil自带的代码编辑体验一般格式化、静态检查都不算强。我做项目时习惯给Keil配上两件套代码格式化工具和静态分析工具。4.1 Astyle代码自动对齐统一风格团队协作时每个人写代码风格不一样缩进、大括号位置乱七八糟。Astyle是一个开源的C/C代码格式化工具命令行运行即可。我的使用姿势是下载Astyle的Windows版本后在Keil的Tools - Customize Tools Menu里添加一条命令命令行参数设置成C:\tools\AStyle\bin\AStyle.exe --styleallman -s4 -S -N -Y -p -H -U !E其中--styleallman控制大括号换行风格-s4表示缩进4个空格-S表示switch缩进-p表示操作符两侧加空格。设置好之后在Keil的菜单栏会多出一个自定义工具按钮点一下当前文件就自动格式化代码瞬间整齐。注意!E是Keil传参表示当前编辑窗口的文件路径。4.2 Cppcheck静态分析帮你找出潜在BUGCppcheck是一个开源静态分析工具能检查空指针、数组越界、资源泄漏、不必要的拷贝等问题比编译器警告严格得多。我一般在提测之前跑一遍基本能扫出一堆编译期看不出来的隐患。同样可以通过Customize Tools Menu加上命令行示例C:\tools\cppcheck\cppcheck.exe --enablewarning,style,performance,portability --stdc99 --platformwin32A --inline-suppr --suppressmissingIncludeSystem --quiet 你的工程目录跑完会输出整个工程的告警列表。看到疑似问题再回代码里逐一确认。这种做法尤其适合接手老项目时快速了解代码质量。4.3 工程目录变更引发的问题与对策热搜词里有一条“keil外面的文件夹名称更改后出了很多问题”太真实了。Keil的.uvprojx工程文件里路径信息默认是相对路径但如果你把整个工程文件夹都改了名或者移动了位置有时候Keil还是会在加载时提示找不到某个源文件。常规办法是右键工程名 -Options for Target-C/C页里检查Include Paths把里边的路径改成新路径。如果文件多一个个改太麻烦更快的办法是新建一个同配置工程把所有文件重新添加进去。其实这个问题的根因是Keil工程文件里的文件路径是当初添加文件时生成的绝对路径或半相对路径。要想工程“搬家”后还稳定建工程时就要把源码目录和工程目录保持合理的相对关系并且尽量所有源文件都通过Add Existing Files添加不要直接手写路径。我个人的习惯是保持工程在本地根目录的二级目录内比如D:\Work\Project\Firmware然后把所有驱动库放在Firmware\Drivers子目录应用层放Firmware\App所有引用都走相对路径。这样整个文件夹拷给别人路径不变基本不会出现找不到文件的问题。5. 一个典型的STM32调试图解从现象到根因聊了这么多理论最后用一个我自己最近调的STM32F103C8T6的案例把整个调试流程串一遍。这个案例在热搜词里面也有对应的词条freertos学习篇一stm32f103c8t6下的移植以及stm32 keil lvgl ili9341xpt2046之类的硬件调试场景。5.1 问题现象板子上跑了FreeRTOS其中一个任务周期性读取温度传感器并通过串口打印。现象是系统运行大概3到5分钟之后串口打印停止LED不再闪烁按键无响应。重启之后恢复过几分钟再次死机。用示波器看电源轨3.3V纹波正常排除供电问题。5.2 排查过程我并没有急着改代码而是先把调试器接上打开Keil进入Debug模式让程序全速运行。等到死机现象出现后立即点暂停按钮。这时候PC指针停在了一个奇怪的地址Call Stack Locals窗口显示调用链已经完全乱掉函数返回地址是0x08005A64和0x08003F78交叉在一起看起来极不合理。接着我打开Fault ReportsCFSR寄存器中UNDEFINSTR位被置1证明CPU执行了未定义指令。结合栈乱掉的情况判断方向基本锁定为栈溢出或数组越界写坏了函数返回地址。在FreeRTOS中每个任务都有独立的栈如果某个任务的栈配小了运行一段时间后栈深处的内容就会覆盖到相邻内存导致函数返回地址被篡改。然后我逐个检查各任务的栈配置。在FreeRTOSConfig.h里看到#define configTOTAL_HEAP_SIZE ( ( Size_t ) ( 8 * 1024 ) )再看任务创建时的栈大小其中有一个任务分配了256字节的栈里面却调用了一个比较重的JSON解析函数局部变量总和轻松超过512字节。明显这个任务的栈不够用把相邻任务的控制块或者系统堆给踩了。5.3 定位与修复我用Keil的内存窗口实时监控该任务的栈顶地址附近数据在死机前大概2分钟看到栈区地址开始出现非预期的数据覆盖进一步坐实了栈溢出的判断。修复方法也简单把那个任务的栈大小从256字节改成1024字节同时把JSON解析函数里的一个临时大数组改成动态分配或静态全局区避免每次调用都吃栈。改完之后连续拷机24小时没有再复现死机。这个案例里调试器的作用非常关键没有它光靠看代码很难想到是栈溢出因为代码里没有任何显式的数组越界操作全是“栈深了”之后才爆掉的隐性问题。5.4 调试中的另一种常见坑看门狗干扰同样的案例如果系统里开了独立看门狗IWDG或窗口看门狗WWDG调试时又会多一重麻烦。看门狗超时后直接复位MCU进调试模式后单步停在复位向量处会让人误以为代码卡死。绕过方法有两种。第一种是在调试前把看门狗的初始化代码临时注释掉第二种是如果芯片支持调试期间停止看门狗计数可以在调试器的Debug设置里把Reset and Run关掉然后在Watch窗口把看门狗控制寄存器里的WDGA位清零。针对STM32还可以在Debug设置勾上WWDG相关的调试模式选项不同芯片略有差异。我的习惯是统一用宏控制比如#ifndef DEBUG MX_IWDG_Init(); #endif这样调试时编译一次看门狗不启动发布时编译自动恢复。Clean and simple。6. 调试效率的额外心得最后再分享几个提升调试效率的小技巧都是靠时间换来的经验常规教程很少会系统讲。一是善用View - Periodic Window Update。硬件调试时默认窗口数据只在程序暂停时刷新全速运行时Watch窗口的数值是静止的尤其是在调试电机、电流环等实时控制系统时容易误导。勾选这个选项后窗口会在程序运行期间周期性刷新。但注意它也会稍微加重调试器的通信负载影响实时性关键时序调试时建议关掉只在观察缓慢变化的变量时开启。二是用Trace相关的功能。新版本Keil在View - Trace里有Data Trace、Instruction Trace等选项配合ETM或SWO引脚可以实时看变量波形替代一部分逻辑分析仪和示波器的功能。不过这个功能对芯片引脚有要求而且调试器需要带SWO接口国产的一些山寨J-Link不一定支持使用前需要确认。三是把重复执行的调试步骤写成脚本。Keil的命令行接口支持执行.ini文件在Debug选项卡的Initialization File里可以指定一个脚本。例如我想在进入调试时自动初始化一组变量、设置一组断点可以在脚本里这么写LOAD %L FUNC void Setup(void) { SP _RDWORD(0x08000000); PC _RDWORD(0x08000004); } SETUP(); BREAKSET 0x08002A34;这样每次进调试模式时环境自动搭好不用手动一条条加断点。对于需要多轮重复验证的bug调试这种方法能省下不少时间。脚本语法虽然冷门但官网文档和网友分享都够用。四是养成先看Map文件再优化的习惯。程序体积告警、定位重定义、查找未使用函数Listings目录下生成的.map文件比IDE窗口里的信息全得多。调试性能问题时也可以直接用View - Analysis Window - Performance Analyzer查看每个函数的执行时间占比这比凭感觉猜“哪段代码慢”靠谱得多。五是关于Keil的安装、激活和Pack管理。现在从Keil官网下载MDK很方便社区版、评估版都有正式商用建议通过官方正规渠道购买授权。PACK包则统一从Pack Installer窗口安装路径可以改到非系统盘避免C盘空间紧张影响编译速度。如果下载慢也可以去芯片原厂官网比如ST官网、GD官网下载对应PACK包离线导入。调试这件事说到底是一个反复验证、不断缩小问题范围的过程。工具只是加速这个过程的辅助真正重要的是你对执行流程和硬件行为的理解。我这个笔记只做了一次整理还有很多细节比如RTOS下的任务切换调试、低功耗模式的调试、多核芯片的调试方法都值得单独写。之后有机会再一篇篇补齐。希望这篇笔记对正在啃Keil的你有帮助。