JFlash烧录程序为何必须先擦除Flash？一个工程师踩坑后的深度复盘
最近在带新人调试一款基于STM32H7的工业控制器时，遇到了一个“经典老问题”：
代码编译、下载都显示成功，但设备上电后就是不启动——既没有串口输出，也进不了调试器。反复检查链接脚本和中断向量表也没发现问题。
最后排查了一圈才发现：根本原因竟然是忘了在JFlash里勾选“预擦除”选项。
这事儿听起来简单，但背后涉及的是嵌入式系统中最基础却最容易被忽视的一环——Flash存储器的物理特性与写入逻辑。今天我就结合这次经历，彻底讲清楚：为什么用JFlash烧录程序前，必须搞懂Flash预擦除这件事。
你以为的“写入”，其实是“打补丁”
我们平时在电脑上保存文件，改几个字再保存，系统会自动覆盖原内容。但在MCU的Flash里，没有“覆盖”这个操作。
Flash是一种非易失性存储器（断电不丢数据），它靠浮栅晶体管来存储电荷。这些晶体管有个硬性规则：
只能把 bit 从 1 变成 0，不能直接从 0 变回 1。
这意味着：
- 初始状态是全0xFF（所有位都是1）；
- 写数据时，可以把某些位从1拉低为0；
- 但如果某个地址已经是0x00或其他非0xFF值，你就不能再往里面写新的0了——因为硬件检测到该位已是0，就会拒绝再次编程。
那怎么才能重新写入？答案只有一个：擦除（Erase）。
而擦除不是按字节进行的，它是以扇区或块为单位，一次性将整个区域的所有bit恢复成1（即变为0xFF）。只有完成这一步，后续的写入操作才真正安全可靠。
换句话说，在Flash里，“写入”其实更像是“打补丁”——你只能在干净的白纸上画线，不能在已经涂黑的地方重画。
JFlash里的“预擦除”到底干了啥？
很多人打开JFlash，看到界面上那个“Program”按钮就想点，觉得点了就能把程序烧进去。但实际上，如果你跳过了关键设置，很可能就是在往一堆旧数据上强行“贴补丁”。
在 JFlash 的项目配置中（Options → Project Settings → Flash），有一个至关重要的选项叫Pre-Erase，它决定了你在烧录前要不要先把目标区域清空。
四种常见模式，各有用途
| 模式 | 说明 | 使用场景 |
|---|---|---|
| No Erase | 不做任何擦除 | 极少使用，仅用于追加写入（如日志记录） |
| Erase Sectors Used by Program Data | 仅擦除程序实际占用的扇区 | ✅ 推荐！开发调试首选 |
| Erase Full Chip | 整片Flash全部擦除 | 出厂初始化、换固件架构时用 |
| Erase All Used Sectors | 擦除所有已使用的扇区（含Option Bytes等） | 谨慎使用，可能误删保护配置 |
举个例子：你的新程序只用了Flash前128KB，其余部分是保留区或未来升级预留。如果选择“全片擦除”，哪怕你只改了一行代码，也要花几百毫秒甚至几秒去擦除整个芯片，严重影响效率。
反过来，如果不擦除，而旧程序恰好占用了相同区域，新旧数据叠加后可能出现“位与效应”——比如原来某处是0xAA (1010_1010)，你想写成0x55 (0101_0101)，但由于已有bit为0的位置无法再变，最终结果可能是0x00或完全错乱。
这就是为什么有时候烧录显示“Verify OK”，但程序一运行就崩溃——数据看似对了，实则已被旧内容污染。
实战中的三大典型翻车现场
❌ 场景一：烧录成功，程序跑飞
现象：JFlash提示“Programming/Verify passed”，但单板通电无响应。
根因分析：
最常见的原因是中断向量表未正确更新。假设旧程序的复位向量指向0x0800_0100，而新程序起始地址是0x0800_0000。若未擦除，旧向量仍存在，CPU上电后跳转到了错误位置，自然无法执行有效代码。
✅解决方案：
务必启用“Erase Sectors Used by Program Data”，确保向量表所在扇区被清空后再写入。
❌ 场景二：编程失败，卡在某个地址
现象：烧录过程中报错：“Failed to program flash at address 0x08004000”
根因分析：
该地址所在的扇区之前已被写入过数据（例如上次调试遗留的日志或参数），且未被擦除。现在尝试写入新数据时，发现某些bit已经是0，无法再次编程，导致操作中止。
✅解决方案：
- 检查该地址属于哪个扇区（查阅芯片手册）；
- 确认当前预擦除策略是否包含该扇区；
- 必要时手动扩展擦除范围，或临时改为“全片擦除”清理环境。
❌ 场景三：量产烧录太慢，拖慢产线节奏
现象：每台设备烧录耗时超过5秒，影响自动化测试节拍。
根因分析：
通常是误设为“Erase Full Chip”。对于一颗2MB Flash的STM32U5来说，全片擦除可能需要2~3秒，即使你只更新了几个字节的版本号。
✅优化方案：
切换为“Erase Sectors Used by Program Data”。JFlash会自动解析ELF/HEX文件中的加载段（.text,.rodata等），精准定位所需扇区，仅擦除必要区域，可将总时间缩短至1秒以内。
那些没人告诉你但必须知道的技术细节
🔹 扇区大小差异巨大，别想当然
不同MCU的Flash扇区划分完全不同：
- STM32F103：前4个扇区1KB，后面都是2KB
- STM32F407：有16KB、64KB、128KB等多种扇区
- GD32系列：部分型号最小扇区为4KB
如果你的程序刚好跨了两个扇区边界，就必须保证这两个扇区都被擦除，否则第二段写不进去。
🔹 擦除比编程还慢
典型时间对比：
| 操作 | 时间 |
|------|------|
| 擦除一个16KB扇区 | ~50ms |
| 编程1KB数据 | ~5ms |
| 校验1KB数据 | ~2ms |
可见，擦除才是拖慢整体速度的大头。因此合理控制擦除粒度，是提升烧录效率的关键。
🔹 Flash寿命有限，别频繁全擦
普通NOR Flash耐久性约1万~10万次擦写循环。虽然日常开发不至于耗尽，但在自动化测试脚本中若每次烧录都全片擦除，长期下来可能导致早期损坏。
建议做法：
- 日常调试：按需擦除
- 出厂清零：全片擦一次即可
- OTA升级：由Bootloader精确管理擦除区域
如何正确配置JFlash？一步步教你避坑
以下是我在团队内部推广的标准操作流程：
- 打开JFlash → Create New Project
- Select Target Device：准确选择MCU型号（如
STM32H743ZI） - Load File：导入
.elf或.hex文件（推荐用ELF，包含符号信息） - 进入 Project Settings → Flash
- ✅ 勾选“Always pre-program erase”
- 下拉选择“Erase sectors used by program data”
- （可选）勾选 “Verify programming” 提高可靠性 - 点击 “Erase & Program” 开始烧录
⚠️ 注意：不要单独点击“Program”，除非你确定目标区域已擦净！
此外，还可以通过批处理脚本实现自动化烧录：
// save as burn.jflashscript SetLogFile "burn.log" OpenProject("stm32h7.jflashproj") Connect() Erase() ProgramFile("build/app.hex") Verify() Reset() Exit();配合CI/CD工具或产线治具，实现无人值守批量烧录。
写在最后：理解底层，才能远离“玄学故障”
很多新手遇到“烧录成功却不运行”的问题时，第一反应是怀疑编译器、怀疑下载线、怀疑电源……但往往忽略了最根本的一点：Flash不是RAM。
它的读、写、擦机制有着严格的物理约束。你不尊重它，它就给你脸色看。
掌握Flash预擦除的意义，不只是为了回答“jflash怎么烧录程序”这个问题，更是培养一种深入硬件层思考的习惯。当你开始关注扇区分布、擦除时间、状态寄存器时，你就已经从“调功能的人”变成了“懂系统的人”。
未来哪怕面对更复杂的存储介质（如QSPI NOR/NAND、eMMC、ReRAM），这种底层思维依然适用。
所以，请记住一句话：
在Flash世界里，干净的开始，才是成功的前提。
下次你点下“Program”之前，不妨多问一句：这片Flash，真的擦干净了吗？
关键词延伸阅读：jflash怎么烧录程序、JFlash预擦除设置、Flash先擦后写机制、STM32烧录失败排查、JLink烧录教程、SWD接口烧录原理、HEX文件加载、MCU固件更新流程、嵌入式Flash管理、量产烧录效率优化
