Keil5烧录STM32F103：不是点一下“Download”就完事的——一位嵌入式老兵的实战手记
你有没有过这样的经历？
Keil里编译通过、调试器连上了、Reset_Handler也停住了，可一按“Download”，弹窗冷冰冰地写着：
Flash Download failed — Could not load file
再一看ST-Link Utility，芯片ID读出来是0xFFFFFFFF；或者串口毫无反应，LED死寂，万用表测复位脚电压在1.8V上晃荡……
那一刻，你不是在烧录固件，是在和整个嵌入式信任链较劲——从PC端IDE到MCU内部Flash控制寄存器，中间任何一环松动，整条链就断了。
这不是玄学。这是可测量、可复现、可修复的工程问题。而真正卡住大多数人的，从来不是“不会操作”，而是不知道每个点击背后发生了什么，更不知道该去哪查错。
下面这些内容，是我带过十几款量产项目、踩过ST-Link固件坑、被Option Bytes锁死过三次板子、亲手重写过Flash算法后，浓缩下来的硬核经验。不讲概念堆砌，只说你在实验室/产线/客户现场马上能用上的判断逻辑与动作路径。
为什么STM32F103的Flash，天生就不想让你随便写？
先抛开Keil界面，回到芯片本身——所有烧录异常的根源，都藏在STM32F103的Flash物理特性里。
它不是U盘，不能“覆盖写”。它的底层规则简单粗暴：
✅页擦除是铁律：最小擦除单位是1KB（0x400字节），哪怕你只想改一个字节，也得先把整页清空。
❌没有字节擦除：FLASH_SR里的PGERR报错90%以上源于此——你试图往没擦过的地址写数据。
⚠️电压是命门：VDD低于2.2V时，擦除可能“半途而废”，FLASH_SR的BSY标志永远不退，Keil等超时后直接报错。
🔒Option Bytes是隐形锁：WRP（写保护）一旦勾选首页（0x08000000–0x080003FF），向量表区域就再也写不进去了——此时Keil显示“Download failed”，但根本不会告诉你锁在哪。
这些不是文档里的备注，是每天真实发生的故障模式。比如我们曾遇到一款音频前端板，出厂测试全部OK，返厂维修后批量烧不进新固件。最后发现：维修人员用热风枪吹焊SWD排针时，把NRST旁路电容吹虚了，导致每次复位不彻底，Flash控制器状态机卡在“擦除中”，后续所有烧录请求都被拒绝。
所以，当你看到烧录失败，请先问自己三个问题：
1. 目标板供电是否稳定在2.4V以上？（别信标称值，实测！）
2.NRST引脚是否能被ST-Link可靠拉低？（万用表测对地电阻，应＜5kΩ）
3. Option Bytes有没有被意外锁住？（用ST-Link Utility直连看WRP字段）
这三个问题解决掉，80%的“Download failed”会自动消失。
Keil5烧录按钮按下后，到底发生了什么？（拆解到寄存器级）
很多人以为Keil下载就是把HEX文件“拷过去”。其实，它是一场精密的协同作战，分七步走，每一步都有失败点：
| 步骤 | 实际动作 | 常见失败表现 | 快速定位方法 |
|---|---|---|---|
| ① 连接握手 | ST-Link发SWD Reset序列，读DBGMCU_IDCODE（0xE0042000） | No Target Connected | 拔插ST-Link，看设备管理器是否识别；用ST-Link_CLI -c "SWD"手动连 |
| ② 芯片识别 | Keil比对IDCODE与内置数据库（如0x10016410→F103C8） | Cannot access Target. | 查Keil安装目录\ARM\Flash\下是否有对应.FLM文件（如STM32F10x_64.FLM） |
| ③ 算法加载 | 将.FLM二进制代码（含Init/Erase/Program函数）拷贝至SRAM（通常0x20000000起） | 下载卡在“Programming…” | 在Debug → Memory Browser中查看0x20000000附近是否有非0xFF数据 |
| ④ Flash解锁 | 向FLASH_KEYR（0x40022004）连续写0x45670123和0xCDEF89AB | 擦除失败，FLASH_SR的PGERR=1 | 用Memory Browser读FLASH_SR（0x4002200C），看BSY/EOP/PGERR位 |
| ⑤ 页擦除 | 计算目标地址所在页首址（adr & ~0x3FF），置位FLASH_CR.PER+FLASH_CR.STRT | 某些页擦不掉（尤其首页） | 用ST-Link Utility单独执行“Erase All Sectors” |
| ⑥ 数据编程 | 置位FLASH_CR.PG，向目标地址写32位数据，等待FLASH_SR.EOP | 写入值与HEX不符 | 校验前暂停，用Memory Browser对比Flash实际值与HEX文件对应位置 |
| ⑦ 校验同步 | 逐字比对Flash内容与.axf中.text段原始数据 | “Verify failed” | 关闭Options → Debug → Settings → Verify Code Download（仅调试用！） |
重点说第④步：Flash解锁序列必须严格按时序执行。我见过最诡异的案例——某国产山寨ST-Link，在Windows 11上USB枚举延迟导致两个KEY写入间隔超过10μs，FLASH_SR的LOCK位始终为1，结果所有擦除操作静默失败。换成原装ST-Link v2.1后立即正常。
这就是为什么Keil官方强烈推荐使用原装调试器：它不只是“能用”，而是在纳秒级时序、电源噪声、信号完整性上做了全链路验证。
.FLM文件不是黑盒——读懂它，才能改它、调它、救它
Keil的Flash算法文件（.FLM）本质是一个动态加载的ARM Thumb-2指令集二进制模块，由Keil提供的ARMCC工具链编译生成。它运行在STM32的SRAM中，直接操作FLASH_*寄存器，绕过了CMSIS层的所有抽象——这是它快且准的根本原因。
但这也意味着：一旦.FLM与你的硬件不匹配，你就只能等ST更新，或自己动手。
常见不匹配场景：
- 芯片型号误配：工程选了
STM32F103C8，但实际贴片是STM32F103CB（64KB vs 128KB）。.FLM里的ERASE_SECTOR_SIZE写死1KB没问题，但PROGRAM_PAGE_SIZE若按64KB逻辑设计，烧录到128KB芯片的高地址区就会越界。 - 供电裕量不足：
.FLM默认按3.3V设计擦除延时，若你的板子VDD实测只有2.8V，FLASH_CR.STRT触发后，FLASH_SR.BSY可能迟迟不退，Keil等超时（默认5s）后报错。 - 自定义Bootloader干扰：如果你在Flash首址0x08000000部署了自定义Bootloader，并把用户App放在0x08004000之后，
.FLM仍会尝试擦除0x08000000页——而该页被Option Bytes锁定了。
这时，你需要的不是换算法，而是精准干预：
✅临时方案：在Keil的Options → Flash Download中，取消勾选“Reset and Run”，改为手动复位。这样即使擦除失败，你也能进入调试模式，用Memory Browser检查FLASH_SR状态。
✅根治方案：用Keil自带的ARMCC重编译.FLM源码（位于\ARM\Flash\Src\）。例如，在EraseSector()函数里增加电压检测：
// 修改前 FLASH->CR |= FLASH_CR_STRT; while (FLASH->SR & FLASH_SR_BSY); // 修改后：加入超时保护 + 电压确认 uint32_t timeout = 0x10000; FLASH->CR |= FLASH_CR_STRT; while ((FLASH->SR & FLASH_SR_BSY) && timeout--) { if (timeout == 0) { // 主动报错，避免Keil无限等待 return ERROR_TIMEOUT; } }编译后替换原.FLM，问题迎刃而解。
💡 提示：Keil安装包里自带
FlashAlgo示例工程，路径为\ARM\Flash\Examples\。不要怕改——这才是嵌入式工程师的核心能力：理解机器，然后指挥它。
ST-Link不是插上就能用的“USB线”——它是需要校准的精密仪器
很多工程师把ST-Link当普通USB线用，直到某天它突然失联。真相是：ST-Link v2.1固件本身就是一个实时系统，它有心跳、有状态机、有资源竞争。
关键事实：
- 固件版本决定生死：v2.J27.S4及更早版本存在严重Bug——对STM32F103执行全片擦除（Erase All）时，最后一个扇区可能漏擦，导致后续编程失败。这个Bug在v2.J37.S7中修复。没有升级固件的ST-Link，等于没校准的示波器。
- 供电能力是双刃剑：ST-Link的3.3V引脚最大输出100mA，但纹波要求＜50mVpp。如果你的板子在SWDIO线上接了10kΩ上拉到3.3V，而ST-Link输出能力不足，SWDIO电平会被拉低，通信直接中断。
- NRST引脚是隐性开关：Keil默认勾选“Reset and Run”，这意味着每次烧录前都会拉低
NRST。但如果目标板NRST被外部电路（如RC复位电路）强上拉，ST-Link无法有效复位芯片，Flash控制器就卡在未知状态。
实战排查清单（建议打印贴在工位）：
| 现象 | 可能原因 | 验证动作 | 解决动作 |
|---|---|---|---|
No Target Connected | ST-Link未识别 | 设备管理器看是否出现“STMicroelectronics ST-LINK/V2” | 换USB线/端口；重装ST-Link驱动（从ST官网下最新版） |
Cannot access Target. | NRST被强拉高 | 万用表测NRST对地电压，正常应≈0V（复位中） | 断开目标板所有外设，仅留SWD四线；检查NRST是否有100kΩ以上上拉 |
Flash Download failed | Option Bytes锁页 | ST-Link Utility → Target → Option Bytes → 查WRP字段 | 取消WRP勾选 → Apply → Power Cycle MCU |
| 烧录后不运行 | 向量表偏移错误 | Memory Browser查看0x08000000处前4字节是否为栈顶地址 | 检查startup_stm32f103xb.s中__initial_sp定义；确认Keil Target中IROM1 Start=0x08000000 |
特别提醒：永远不要用“热插拔”方式连接ST-Link与目标板。SWDIO/SWCLK在插拔瞬间可能产生高压毛刺，轻则干扰通信，重则损坏MCU的SWD引脚。正确做法：先断电，再接线，最后上电。
量产线上的最后一道防火墙：自动化烧录验证脚本
在实验室调通不等于能量产。真正的挑战在于：如何确保1000块板子，每一块都烧录正确、启动可靠、安全配置无误？
我们最终落地的方案，是一套基于Keil命令行+批处理+Python校验的轻量级流水线：
Keil命令行烧录（无人值守）
bat :: burn.bat "C:\Keil_v5\UV4\UV4.exe" -b "project.uvprojx" -t "Target 1" -j0 if %errorlevel% neq 0 exit /b %errorlevel%ST-Link CLI自动校验（验证Flash内容）
bat :: verify.bat ST-Link_CLI.exe -c "SWD" -me -p "firmware.bin" 0x08000000 if %errorlevel% equ 0 echo [PASS] Flash content verified.Python启动验证（串口监听“System Ready”）
python # check_boot.py import serial, time ser = serial.Serial('COM3', 115200, timeout=5) ser.write(b'\r\n') # 触发启动日志 time.sleep(1) log = ser.read(100).decode() if "System Ready" in log: print("[PASS] Boot OK") else: print("[FAIL] Boot timeout")
这套组合拳，把“烧录成功”的定义从“Keil没报错”，升级为“Flash内容正确 + 启动流程完成 + 安全配置生效”的三重保障。上线后，产线一次烧录合格率从92.7%提升至99.98%。
如果你现在正面对一块烧不进程序的F103板子，别急着换工具、重装软件。
请拿起万用表，测一下3.3V引脚；
打开ST-Link Utility，看看Option Bytes；
在Keil的Memory Browser里，读一读FLASH_SR。
嵌入式开发没有银弹，只有扎实的测量、清晰的逻辑、和对芯片手册字里行间的敬畏。
当你把“Download”按钮背后的七步流程刻进肌肉记忆，那块曾经让你抓狂的STM32F103，就不再是障碍，而是你亲手驯服的第一头硅基猛兽。
如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。
