1. 问题现象下载窗口一片绿板子却一点反应都没有1.1 我踩到的现场最近在帮同事迁移 STM32 工程的时候遇到一个很典型的 STM32 问题Keil 下载窗口显示完全正常进度条走到最后一步 Verify OK但板子就是不动。这种问题最磨人因为 Keil 没给你任何红色报错很容易让人怀疑芯片、怀疑板子甚至怀疑人生。同事手里是一块 STM32F103C8T6 的核心板点灯程序新装好的 Keil MDK 5.40ST-Link V2 下载。烧录的时候 Output 窗口干干净净大概就是这几行Erase Done.Programming Done.Verify OK.看起来没有任何问题但板上 LED 死活不亮。按复位不亮拔掉 ST-Link 重新上电还是不亮。同事的第一反应是“新版 Keil 是不是不兼容 STM32F103”然后开始折腾驱动、换烧录器、换芯片其实最后发现根本不是硬件或者芯片兼容性的问题只是一个默认配置的坑。后来我把这个现象发到几个嵌入式交流群里发现遇到的同行不少。很多人都是“旧版 Keil 用得好好的升级新版本之后突然出现烧录后不运行”这绝对不是个例。如果你也正好踩到这篇文章应该能把你拉出来。1.2 “烧录成功”和“程序真的跑起来”是两件事先说一个很多人忽略的基本常识Keil 的 Download 操作本质上是把编译出来的固件通过调试器写进芯片的 Flash然后做一次校验。Verify OK 只表示 Flash 里的内容和 axf 文件一致CPU 到底有没有跑起来Keil 并没有帮你保证。也就是说烧录成功只是“数据进到 Flash 了”运行是另一条链路CPU 要能从 Flash 正确取指、初始化堆栈、跳转 Reset_Handler、最后进入 main。这两件事中间的任何一个环节断了都会出现“明明烧录成功却不动”的现象。新版 Keil 里最容易被忽略的恰好就是“数据进 Flash 之后要不要自动复位并运行”这个开关。新版工程的默认设置和旧版不完全一样导致很多旧工程迁移过去之后一烧录就“假成功”程序压根没有被启动。很多人这时候会去查代码、查板子绕了很大一圈其实改一个勾选就行。2. 排查思路先别急着换芯片按这几个顺序查2.1 最基础的电源、BOOT0 和复位电路先排除遇到烧录后不运行第一件事不是重装 Keil而是先把硬件上的三个基础点确认掉。首先是电源尤其是不用开发板、自己画 PCB 的情况。STM32 工作电压是 2.0V 到 3.6V很多最小系统板用的 AMS1117-3.3 稳压如果输入电压不够或者 LDO 虚焊芯片能连上 SWD 但内部 LDO 和时钟可能工作异常。实测中遇到过 5V 输入接错到 3.3V 引脚上SWD 能识别到芯片但烧完程序完全不正常的情况。然后是 BOOT0。STM32 的 BOOT0 如果拉高上电会从系统存储器启动而不是从用户 Flash 启动。有的最小系统板出厂时 BOOT0 跳线帽没拔或者引脚悬空干扰环境下电平飘了就会出现“烧录时候好好的跑起来完全不是自己程序”的情况。做裸板开发BOOT0 一定用 10k 电阻下拉不要直接悬空。最后是复位电路。NRST 引脚上一般接 100nF 左右的电容如果电容取值太大复位释放时间过长第一次上电可能来不及正常启动。还有的调试器没接 NRST 线导致 Keil 在做“复位运行”时只能靠软件复位对某些芯片和固件来说并不可靠。2.2 从 Keil 输出窗口找隐藏警告硬件基础查完没有问题就要把注意力拉回 Keil。很多人只看最后那几行 “Programming Done、Verify OK”觉得没问题其实中间夹杂的警告信息才是关键。比如 Flash Download 界面里如果没有正确选择 STM32 对应的 Programming AlgorithmKeil 可能会在 Output 窗口里提示找不到 flm 文件或者提示 “No Algorithm found for: 08000000H - 08000FFFH”。一旦出现这类信息说明程序根本没有写对位置或者烧写的地址和芯片型号不匹配。你看到 Verify OK 可能是因为某些烧录器在校验时用的是恒定回读读出来的和写进去的刚好一致但 CPU 实际并不能从那里启动。还有一类是编译阶段的警告。新的 Keil 版本默认用的是 ARM Compiler 6老工程如果是在 ARM Compiler 5 环境下写的升级后经常会出现一类警告某个启动文件里的栈大小、堆大小定义不被 AC6 认可或者 startup 文件使用的语法过时。这类警告不会直接导致编译失败但生成的目标文件可能和预期行为不一致最典型的就是上电后不是从 Reset_Handler 进 main而是跑到 HardFault 里。所以在排查“烧录后不运行”的时候我一般会把 Output 窗口从头拉到最后不放过任何一个黄色 Warning。很多问题不是烧录环节出的而是编译期间就已经埋下了。2.3 用调试模式看 PC 指针停在哪里硬件没问题、编译警告也清理干净还是找不到原因这时候别盲目试错直接用 Keil 的调试模式去看 CPU 到底停在哪。操作很简单Options for Target - Debug 里选对调试器ST-Link 就选 ST-Link DebuggerDAPLink 就选 CMSIS-DAP然后点 Start Debug Session进入调试界面后再点一次全速运行看板子有没有反应。关键就是看 PC 寄存器的值。打开 View - Register Window找到 PC程序计数器看它停在哪个地址如果 PC 停在 0x08000000 附近说明 CPU 读到的向量表是空的或者不对程序压根没有从 Flash 启动。如果 PC 停在 HardFault_Handler 里说明启动有问题或者中断向量配置错误。如果 PC 能在 main 和各个子函数之间正常跳转但硬件没反应那就是设备初始化、时钟配置、GPIO 复用这类代码问题。这一步能把“程序没跑”和“程序跑了但行为不对”彻底分开。很多时候我们在网上看到别人说“Keil 新版不运行”真正的问题其实不是 Keil而是代码在 AC6 编译器下运行时序变了。用调试器一查就知道。我自己的习惯是凡是遇到“烧录成功不运行”的问题一定先按“硬件基础检查 - Output 窗口排查 - PC 指针定位”这个顺序来整个过程不超过五分钟。这样做的好处是避免被表面现象带着走最后才发现问题在完全没想到的地方。3. 新版 Keil 的隐藏小坑一个勾选框决定“烧完跑不跑”3.1 为什么新版本更容易踩中前面铺垫了那么多现在说核心问题。这个“新版 Keil 的小坑”其实就是 Flash Download 界面里的 Reset and Run 选项。在新版 Keil MDK 里新建工程默认的 Download 配置里Reset and Run 往往是没有勾上的。你们看到这里可能会问我没勾它按一下板子上的复位键不就能跑了吗理论上是的但在实际调试场景里会有两个干扰因素。第一当 ST-Link 还连着 SWD 接口时调试器可能一直占用芯片的复位控制你在板子上按复位CPU 并没有真正脱离调试状态程序自然没起来。第二很多 ST-Link V2 的接线只接了 SWDIO、SWCLK、GND 三个脚根本没有接 NRST 复位脚这时候即使你选了 Reset and RunKeil 也可能没办法产生一次可靠的硬件复位。所以这个勾选项的意义不只是省掉你按复位那一下更是让整个烧录流程以“CPU 从 Flash 重新启动”的方式结束。新版 Keil 把默认值改了以后烧录过程结束就是结束不会自动把 CPU 拉起来运行于是“烧录成功板子没反应”的现象就变得特别常见。旧版 Keil 为什么少见一方面是旧工程从很久以前就勾好了这个选项设置被保留在工程文件里另一方面旧版本在部分调试器环境下对复位处理的逻辑不太一样就算没勾也可能触发复位。升级新版本后工程文件迁移过去界面变化又大很多人根本不会想到去翻这个老选项。3.2 三步改正把 Reset and Run 找出来勾上搞清楚原因之后解决其实非常快三步第一步打开 Options for Target。你可以点上方的魔术棒图标也可以直接按 AltF7。第二步切到 Utilities 选项卡点击 Settings 按钮。注意如果你用的是默认的 Use Debug Driver这里点开的 Settings 就是下载算法的设置界面如果你用的是第三方烧录工具那就需要看对应工具的设置入口。第三步在 Flash Download 对话框里找到 Reset and Run 复选框勾上它。同时确认下方 Programming Algorithm 列表里有和你芯片型号匹配的 flm 文件。一般使用 STM32F103 系列就选 STM32F10x High-density 或 Med-density 对应的文件。勾完之后点 OK保存工程再重新编译下载一次。正常情况下烧录结束后芯片会自动复位并运行LED 该亮的就亮了。如果你用的是 Keil 的社区版或者离线包版本界面英文是 Flash Download关键词就找 Reset and Run。不要被新界面里那些花里胡哨的新功能带偏这个选项的位置几十年来基本没挪过窝。3.3 勾上了还是不跑怎么办勾选 Reset and Run 后还出现“不运行”优先检查三件事。第一个是 ST-Link 的接线。如果手里的 ST-Link V2 是山寨版很多根本没法在不接 NRST 的情况下可靠复位目标板。建议把 SWD 的 4 线接全SWDIO、SWCLK、GND、NRST 全部连上。NRST 不是烧录必需但“烧录后自动复位运行”这个功能很多实现方式都依赖硬件复位这根线没接勾了也白勾。第二个是 Debug 状态残留。有时候 Keil 上一次调试会话没有正常退出芯片还停在调试状态里这时候你再按 Download即使配置正确复位也可能被调试器接管。遇到这种情况把 ST-Link 从板子上拔掉给板子重新上电然后再接回去用 Keil 重新下载一次。第三个是芯片的读保护或 Option Bytes 设置。如果芯片之前被设置了 RDP读保护Keil 在烧录时虽然能正常擦写但运行状态可能被锁定。这种问题用 ST-Link Utility 或者 STM32CubeProgrammer 看一眼 Option Bytes 就能发现把 Level 0 打开再重新烧录。如果这三项都正常问题大概率就不在 Keil 配置上而是代码或硬件层面了那就继续往下走。4. 其他常见“烧录后不运行”原因速查4.1 典型原因对照表把这类问题的常见原因统一整理了一张表大家可以对照自己的现象排查现象可能原因排查方法解决方法烧录显示 Verify OK但程序不启动Reset and Run 未勾选检查 Flash Download 选项勾选 Reset and Run调试模式下跑退出调试不跑调试器占用复位或 SWD 引脚拔掉调试器重新上电断电重试必要时接 NRST上电偶尔跑经常不跑电源不稳、BOOT0 悬空、复位电容异常万用表量电压检查 BOOT0 电阻修正硬件设计程序一运行就进 HardFault中断向量表偏移不对、外部晶振失效单步调试看 HardFault 位置检查 VTOR 和时钟配置从 Bootloader 跳转到 App 后不运行跳转前没重新设置 MSP 和 PC反汇编查看跳转代码先读取 App 首 8 字节再赋值 SP/PC烧录异常但显示成功下载算法选错或芯片型号选错看 Output 是否有 Algorithm 警告重新匹配 flm 算法代码有硬件看门狗复位后被咬住初始化阶段喂狗太慢或没喂单步执行到看门狗复位启动阶段提前初始化并喂狗这张表并不全面但覆盖了我实际遇到过的绝大多数“烧录后不运行”场景。最重要的一点是先确认复位、时钟、启动文件这些“地基”再去怀疑代码逻辑。4.2 编译器和启动文件相关注意点新版本 Keil 的小坑不只在烧录设置上编译器默认配置变化也容易让人头晕。新版 Keil 默认使用 ARM Compiler 6而很多老工程是在 ARM Compiler 5 下正常工作的。AC6 对 C 语言标准的支持更严格对启动文件的语法要求也和 AC5 不完全一致。尤其是 startup_stm32f10x_hd.s 这类老启动文件里面会有堆栈大小的 EQU 定义、向量表导出、SystemInit 调用等汇编指令。AC6 的汇编器在某些版本里对这些语法的警告特别多但不一定会阻止编译成功。可一旦链接器生成的镜像里堆栈指针初始值不对芯片上电后第一条指令就可能跑飞。所以我的建议是如果是旧工程迁移到新 Keil先固定编译器版本再谈运行问题。Options for Target - Target 里把 ARM Compiler 改成和旧工程一致的版本比如 Use default compiler version 5.06 或者指定 AC6 的某个版本然后再编译下载。不要一上来就用默认编译器硬扛那样很容易把“编译兼容问题”当成“烧录问题”排查。另外如果程序里没有直接配置 VTOR但是用了 IAP 或 Bootloader跳转到 App 前必须把 MSP 和 PC 重新设置。我见过不少例程直接在 main 最后用函数指针跳转结果跳过去就跑飞。正确做法是先读取 App 起始地址处的前 8 字节前 4 字节作为主栈指针写入 MSP后 4 字节作为复位入口写入 PC再关中断、清流水线。4.3 交叉验证用 ST-Link Utility 和 J-Flash 排除调试器干扰如果你不想完全依赖 Keil 的下载流程或者想快速判断问题到底在 Keil 还是板子最简单的办法是用另一套工具做交叉验证。ST-Link Utility 是老牌工具界面朴素但很可靠。它可以读回 Flash 内容、擦除整片、单独烧录 hex而且它的烧录过程不会像 Keil 那样受工程配置影响。把 Keil 编译生成的 hex 文件用 ST-Link Utility 烧进去如果它能跑说明固件和板子都没问题问题基本锁定在 Keil 的下载配置上如果它也不能跑那大概率是固件本身或者硬件启动链路出了问题。J-Flash 也能做类似的事前提是用 J-Link 调试器。操作上会多一步目标芯片型号的选择但 J-Flash 对复位和连接的处理方式比 Keil 更“直男”很多人用 J-Flash 烧完直接按复位就跑用 Keil 烧完就是不跑。这种差异本身就很能说明问题。另外STM32CubeProgrammer 也是我常用的工具它比 ST-Link Utility 维护更活跃对芯片读保护、选项字节、OTP 这些区域的操作更直观。如果 Keil 反复出问题可以先在 CubeProgrammer 里把芯片的读保护等级确认一下再把程序刷进去试运行。在实际项目里我一般这样分工Keil 负责日常编译和在线调试。ST-Link Utility 或 CubeProgrammer 负责批量下载、读保护解除、Flash 数据备份。J-Flash 负责量产阶段的固件烧录和校验。这样做的好处是Keil 的烧录问题不会变成唯一依赖一旦交叉对比你立刻能判断问题在哪个层面。5. 最后一点经验最后分享一个我现在的固定动作。每次新建或者拿到一个 STM32 工程我不是先写代码而是先花一分钟检查三个地方编译器的版本、Flash Download 里的算法型号和 Reset and Run 复选框以及是否开启生成 hex 文件。这三个地方确认好后编译下载直到看到 Output 窗口出现 Application running 这一类的提示再开始写项目功能。这个小习惯听起来很基础但它真的帮我省掉了很多“烧录后不运行”的低级坑。尤其是新版 Keil 界面变化后很多设置入口不像以前那么显眼但底层逻辑没有变。做嵌入式开发遇到奇怪问题先别急着“优化代码”或者“怀疑硬件”把工具链的最基本环节重新确认一遍往往比瞎调代码高效得多。