先说结论：最近用STM32L071KZ做低功耗采集节点，固件升级走的是BOOT0拉高进ST系统Bootloader，再用串口刷Flash。本来以为这条路最省事，结果实际调试时被“Flash Issue”折腾了一整晚：串口工具能连上，读出来的Flash却是全0xFF；用STM32CubeProgrammer擦除直接报“erase failed! cannot access memory internal command error”；好不容易擦除成功，烧录校验又失败；最后程序刷进去了，复位后却死活不跑。这篇文章就把这类问题的排查思路、根因分析和可复现的解决方案完整写出来，给正在拿STM32L071KZ（或者其他STM32L0系列）做Bootloader刷写、量产烧录、救砖的朋友一个参考。
做嵌入式开发遇到“MCU Flash下载失败”并不稀奇，但通过ST Bootloader刷写时的失败，和用ST-Link/J-Link在IDE里直接烧录的失败，原因往往不是一回事。Bootloader场景下的问题大多是选项字节保护、引脚配置、通信链路时序、擦写对齐这几类，排查顺序和方法完全不一样。下面按我实际踩坑的顺序来写。
1. 现象复盘：ST Bootloader下Flash问题的三类典型表现
1.1 第一类：握手成功，但Flash读出来是空白
我一开始用的是STM32CubeProgrammer的UART模式连接，Boot0拉高后复位，软件很顺利就识别到了目标芯片，Get ID返回了L0系列的ID，说明Bootloader已经正常工作。但当我尝试读取主Flash区域时，整个0x08000000区域返回的全是0xFF，跟全新空片一样。
这个现象的迷惑性非常强。表面看像是Flash里本来就没程序，或者程序丢了，但实际情况是读取操作被保护机制拦住了。STM32L0系列的保护机制不止RDP读保护一种，还有WRP写保护、PCROP代码读出保护。当某个区域被保护之后，通过Bootloader发Read Memory命令，可能会读到全0xFF而不是报错，这正是它容易误导人的地方。
还有一种更朴素的可能：读地址填错了。L071KZ的Flash起始地址是0x08000000，容量192KB，有效范围到0x0802FFFF。如果上位机在输入地址时用了0x8000000（少个0），或者填了0x08030000开始越界地址，读回来自然也是0xFF。这类问题虽然低级，但实际工作中很常见。
1.2 第二类：Erase命令报错，擦除进行不下去
这是我最头疼的一类。CubeProgrammer连接正常，点击“Full chip erase”之后，进度条走了一小段就弹错：“erase failed! cannot access memory internal command error”。
这个错误信息本身挺误导人的，它没有直接说“写保护”，而是说“内存访问失败”。实际上在STM32L0系列上，除了RDP读保护之外，Flash写保护（WRP）才是擦除失败的头号原因。L0的WRP是按页组配置的，一旦某个区域的写保护选项字节被置位，Bootloader执行Erase命令时就会因为访问到受保护区域而中止。
另外一个容易忽略的原因是供电电压。Flash擦写需要电荷泵，VDD过低时Flash控制器会拒绝执行擦除操作。L071KZ虽然标称1.8V到3.6V工作，但Flash擦写对电压余量是有要求的，如果板子用纽扣电池供电，或者USB转TTL模块输出电流不够，电压被拉低，擦除就会间歇性失败。
1.3 第三类：写入校验失败，或者写完程序不跑
擦除过了之后，烧录过程也可能在中途翻车。我遇到的报错是校验和失败，具体表现是写入过程显示成功，但“Verify”阶段发现读回来的数据和bin文件对不上。
这类问题在Bootloader场景下通常是这几个原因：
- 写入地址没有按8字节对齐。STM32L0的Flash编程是双字（64位）操作，一次写入必须8字节对齐，长度也必须是8的整数倍。如果hex文件里某个段的首地址不对齐，Bootloader就会写失败或者写入错误数据。
- 上位机校验算法和Bootloader不一致。ST Bootloader返回的校验是基于XOR的，如果自研上位机用的是CRC或者简单累加，校验结果自然对不上。
- 写保护依然存在，但只保护了部分区间。整片擦除可能碰巧成功，写入时某些页仍然受WRP保护，数据写不进去，校验就失败。
程序刷完复位不跑也是经典问题。最常见原因就是Boot0引脚还拉在高电平，复位之后又进了Bootloader；其次则是选项字节里的nBOOT0、nBOOT1、nBOOT_SEL配置和你的启动期望不一致。
2. 排查前的底层基础：L0 Flash架构与Bootloader行为
2.1 先搞懂L071KZ的Flash结构，排查才有方向
STM32L071KZ属于STM32L0超低功耗系列，Cortex-M0+内核，主频32MHz。Flash容量192KB，SRAM 20KB，封装是LQFP32。这颗芯片的Flash架构有几个特点直接关系到Bootloader刷写：
- 页大小是128字节，不是常见的1KB或者2KB。擦除操作以页为单位，Bootloader的擦除命令也是按页来。
- 编程必须是双字（64位）操作，也就是一次写入8个字节。所以不管是官方工具还是自研上位机，写入长度都必须是8的整数倍。
- Flash地址范围是0x08000000到0x0802FFFF，共1536页。
- 选项字节（Option Bytes）位于独立的区域，配置RDP、WRP、PCROP、启动源等。选项字节本身也是Flash，修改时同样需要擦写。
理解这几点之后，再看Bootloader写Flash失败的问题就清晰多了：地址越界、未对齐、写到保护页、供电不足导致Flash控制器中止，这些都能从Flash自身的限制中找到答案。
L071KZ的Flash在Bootloader场景下还有一个特殊点：写Flash时必须先擦除。Flash写入只能把1写成0，不能把0写成1，所以往一个已经是0x00的区域写0xFF是无效的。很多自研上位机只做了Write Memory命令，没预先擦除，导致写进去的数据和预期完全不符。
2.2 系统Bootloader的进入条件和通信协议
L0系列出厂时在系统存储区有一段Bootloader固件，地址在0x1FF00000起始处。要让MCU上电后运行这段固件，需要满足启动条件。对L071KZ来说，最直接的方式是把BOOT0引脚拉高再复位。
这里有一个容易踩的坑：L0的启动源选择不仅受BOOT0引脚控制，还受选项字节里的nBOOT_SEL位影响。如果nBOOT_SEL配置为“使用选项字节nBOOT0”而不是“使用BOOT0引脚”，那么就算外部把BOOT0拉高了，芯片也不一定会进Bootloader。很多板子出厂时烧录过选项字节，可能改过这个位，导致你拉高BOOT0没反应。
ST Bootloader支持USART、I2C、SPI三类接口（L071KZ没有USB，所以没有DFU）。USART协议在应用笔记AN3155里定义，I2C对应AN4221，SPI对应AN4286。基本流程都是：上电后Bootloader等待主机发送0x7F同步字节，收到后返回ACK（0x79），然后主机再发命令帧，命令帧由命令码、地址/数据、XOR校验组成。
调试时我建议记住一个关键点：Bootloader运行不依赖外部晶振，它内部用HSI16时钟。这意味着如果系统程序起不来是因为外部晶振、PLL配置问题，Bootloader刷写通常不会受影响。反过来想，如果程序刷进去之后运行不起来，而Bootloader读写Flash一切正常，那问题大概率就在应用固件本身的时钟配置，而不是Flash内容损坏。
2.3 选项字节的“一票否决权”
在STM32L0上，选项字节对Flash访问的控制权是绝对的。排查Bootloader刷写问题，第一个要查的就是选项字节状态。
- RDP（读保护）：Level 0是无保护；Level 1是禁止调试接口访问Flash，同时Bootloader的读写Flash能力也会受限；Level 2是永久保护，不可解除。如果芯片被设成Level 1，CubeProgrammer连接时有时还能识别芯片，但读取Flash会得到异常数据或者全0xFF。
- WRP（写保护）：按页组保护Flash区域，受保护区域不能擦除、不能写入。L0的WRP粒度是4页一组，也就是512字节一组。选项字节里有多组WRP配置位。
- PCROP（代码读出保护）：保护区域内的代码不能通过Bootloader读取，但执行不受影响。如果程序和数据正好落在PCROP区域，Read Memory读回来就是空数据。
解保护的操作本身也有风险。把RDP从Level 1降回Level 0时，芯片会自动执行一次全片擦除，所有Flash内容都会清空。如果你只是想临时读一下Flash内容，没做备份，改完选项字节之后数据就没了。我在调试时就因为这个动作丢过一版测试固件，教训非常深刻。
3. 实操排查：从连接失败到Flash写失败的完整定位流程
3.1 连接不上时的硬件排查
先解决最基础的问题：Bootloader连不上。在ST Bootloader场景里，USART连接不上是最常见的，原因也最琐碎。
第一，确认BOOT0电平真的拉高了。不要相信电路图，用万用表量一下引脚实测电压。有的板子BOOT0没直接引出，是通过跳线帽或者焊盘短接的，时间久了氧化会导致接触不良。更隐蔽的是，有些低功耗板子BOOT0引脚还并联了电容，上电瞬间电压爬升太慢，MCU启动时BOOT0还没到高电平，导致从主Flash启动了。
第二，检查TXD和RXD有没有接反。USB转TTL模块的TXD要接MCU的RXD，RXD接MCU的TXD。这个错误我犯过不止一次，尤其是用杜邦线临时飞线的时候，线序一乱就白折腾。
第三，注意电平匹配。如果USB转TTL模块是5V电平，而L071KZ是3.3V供电，5V的TXD输出可能会通过MCU的引脚内部保护二极管倒灌电流，轻则通信不稳定，重则损坏芯片。建议用3.3V电平的模块，或者确保模块有电平转换。
第四，复用哪个串口引脚要看AN2606。STM32L0的Bootloader支持多个USART引脚映射，但具体到LQFP32封装，能用的是哪些引脚，需要查AN2606里对应型号的表格。不要想当然认为PA9/PA10一定就行，L0的引脚映射比较灵活，有的封装下Bootloader的USART可能映射到其他引脚。
第五，连接时要卡准Bootloader的握手窗口。Bootloader上电后只会等待有限时间的同步字节，如果上位机打开太慢，窗口就过了。CubeProgrammer连接时，可以先点Connect，然后在软件开始等待时手动按一下板子的复位键。更省事的做法是预留一个NRST控制信号，或者用支持DTR/RTS自动复位的USB转TTL模块。
第六，别用老掉牙的Flash Loader Demonstrator。热搜词里提到的Flash Loader Demonstrator 2.2.0是很多年前的官方工具，对L0系列的支持不够完善，在新系统上还容易出现驱动问题。新项目直接换STM32CubeProgrammer，省心得多。
3.2 连接成功但Flash操作失败的寄存器级定位
当CubeProgrammer能连上芯片，但Flash擦除或写入报错时，不要急着反复重试，先读一下Flash控制器的状态寄存器，确认硬件层面的实际原因。
L0系列的Flash状态寄存器里有几个位特别关键：
- BSY：Flash忙标志。擦写过程中置1，如果长时间不结束，说明Flash控制器卡死了。
- WRPRTERR：写保护错误。置1说明本次写入/擦除操作触碰了WRP保护区域。
- PGAERR：编程对齐错误。地址没按双字对齐时会置位。
- SIZERR：长度错误。写入长度不是8字节整数倍时触发。
- PGSERR：编程序列错误。比如没擦除就写，或者写0到非0xFF区域。
用CubeProgrammer连接后，可以在内存视图中直接查看选项字节区域，对比RDP、WRP的状态。如果发现WRP相关位被置位，用软件里的“Option Bytes”页面修改配置，把写保护取消再试。
如果寄存器显示BSY一直为1，大概率是Flash控制器处于异常状态，最常见原因是擦写过程中供电跌落导致控制器半途停止。解决方法是断电、恢复正常供电、重新上电再连一次。如果反复出现，就要检查板子的电源电路了，我遇到过一次LDO选型余量不足，擦写Flash瞬间电流增大，电压掉到2.7V以下，然后各种随机失败。
3.3 换接口交叉验证，区分通信问题和Flash问题
排查这种问题我习惯用“交叉验证法”：不换芯片、不换固件，只换Bootloader的通信接口。
L071KZ的Bootloader同时支持USART、I2C和SPI。如果USART连接之后Flash读写报错，可以试试用I2C或者SPI接口连接同一个芯片，做同样的Flash擦除操作。如果I2C/SPI能正常擦除，说明Flash本身和保护设置都没问题，故障点就锁定在USART通信链路，比如电平不稳、波特率偏差、引脚映射错误。如果换了接口之后报一模一样的错误，那问题就在Flash保护配置或者供电，不是通信的问题。
这个方法的逻辑很简单：Bootloader的通信接口是独立的，但Flash控制器是同一个。通信接口的故障只会影响该接口的数据传输，不会影响Flash操作本身的结果。Flash操作的结果是跨接口一致的。
我实际测试中，用USART连接时偶尔会出现握手失败，切到I2C之后非常稳定。后来查出是USART1的引脚和板上的一个按键复用了，按键按下时把RX电平拉低，导致握手数据出错。这种硬件复用问题靠看代码很难发现，但换接口一测就暴露了。
4. 解决与复现：用CubeProgrammer完成一次可靠的Flash刷写
4.1 GUI操作：从连接到烧录的完整步骤
解决完上面的问题之后，我把刷写流程固化成一个标准操作，每次刷写L071KZ都按这个顺序走，基本不再翻车。
第一步，连接前准备。给板上电，确认VDD在3.0V以上，BOOT0通过1k电阻接到3.3V，串口模块的TXD、RXD、GND分别接好，共地必须保证。
第二步，打开STM32CubeProgrammer，选择UART模式，选择正确的串口号，波特率建议先用9600这种低波特率，等稳定后再尝试115200。接口参数保持默认的8E1（8数据位、偶校验、1停止位），这是AN3155协议的标准配置。如果选错奇偶校验，握手阶段就会失败。
第三步，点击Connect。连接成功后，软件右侧会显示芯片型号、设备ID、Flash大小等信息。此时先别急着烧录，点击“Option Bytes”页面，查看RDP级别和WRP状态。如果RDP不是Level 0，先改为Level 0并执行，注意此时Flash会被全片擦除。如果WRP有保护区域，全部取消。
第四步，点击“Erase”标签，选择“Full chip erase”，执行一次全片擦除。擦除完成后，用“Read”功能读回整个Flash，确认所有区域都是0xFF，再进行烧录。
第五步，在“Download”页面选择固件文件，hex文件会自动解析地址，bin文件需要手动指定烧录地址（L071KZ的Flash起始地址是0x08000000）。勾选“Verify after download”，点击“Start”开始烧录。
第六步，烧录完成后，把BOOT0跳线恢复到低电平，手动复位板子，程序应该正常启动。
4.2 命令行烧录与量产脚本
手工点GUI在调试阶段没问题，但一旦涉及量产，就得用命令行工具。CubeProgrammer自带的STM32_Programmer_CLI支持完整的烧录流程，可以写到批处理脚本里，实现一键烧录。
下面是一个典型的生产烧录脚本：
STM32_Programmer_CLI.exe -c port=COM7 br=115200 -e all -w firmware.hex -v -rst参数含义拆解一下：
-c port=COM7：指定串口。如果量产中串口号不固定，可以用port=auto或者结合设备管理器里的COM号做对应。br=115200：波特率，实测115200在短连接线（小于15cm）下很稳定。-e all：执行全片擦除。如果只需要擦除部分区域，可以指定地址范围，比如-e 0x08000000 0x08010000。-w firmware.hex：写入固件。写bin文件时要加-a 0x08000000指定地址。-v：烧录后校验。-rst：烧录完成后复位芯片。
量产时还可以加一步设置RDP Level 1，防止固件被读出来：
STM32_Programmer_CLI.exe -c port=COM7 br=115200 -ob RDP=0xBB这里0xBB就是Level 1的配置值。需要特别注意，设置RDP Level 1之后，再想解除会触发全片擦除。而且量产工具如果每次都设置RDP，后续返修时再连接就会受到读保护限制，必须先解保护再烧录，所以解锁和加锁的动作要设计成独立选项，别写死在同一条命令里。
4.3 自研上位机按AN3155协议刷写时的坑
如果项目需要自己写上位机，通过Bootloader刷写L071KZ，下面几个坑是绕不开的。
坑一：串口参数必须是8E1。AN3155的USART协议标准配置是8数据位、偶校验、1停止位。上位机配置成8N1虽然有时候也能握手成功，但后续数据帧的奇偶校验对不上，会导致随机失败。我一开始就是被这个坑的，改完串口参数之后立刻稳定。
坑二：地址和长度必须遵守Flash对齐规则。发送Write Memory命令时，起始地址要8字节对齐，数据长度必须是8的整数倍，且最大不超过256字节。如果bin文件最后一段不满8字节，要补0xFF填充，不能直接把剩余几个字节发出去。
坑三：擦除命令有两条。AN3155定义了Erase（0x43）和Extended Erase（0x44）两条命令。老版本Erase命令一次只能擦除有限页数，Extended Erase支持更灵活的范围。L0的Bootloader对这两条命令的支持程度不完全一样，建议上位机优先用Extended Erase，兼容性更好。
坑四：注意擦除和编程的时间。Bootloader在擦除或写入Flash时，是不会响应新的同步字节的。上位机要么在命令之间插入足够延时，要么等待ACK超时后重新发同步字节。我实测STM32L071KZ擦除一页大约需要几十毫秒，全片擦除要几秒，上位机超时时间至少给10秒，否则整个流程走一半就报超时。
坑五：收到ACK不代表数据写完了。Bootloader是先接收数据，再执行Flash编程，编程完成后才返回结果。所以要在发送完整个数据帧之后，等待一个额外的响应作为“写完成”信号。如果上位机只发了数据不管结果，下一帧就可能因为Flash还在忙而失败。
5. 常见问题速查表与避坑清单
5.1 故障速查表
基于最近这次实战，我整理了下面这张速查表，遇到问题直接对号入座：
| 现象 | 可能原因 | 处理方案 |
|---|---|---|
| Bootloader连接失败 | BOOT0没拉高、串口线接反、奇偶校验不对、握手窗口错过 | 量BOOT0电平，交叉检查TXD/RXD，串口改8E1，先点Connect再手动复位 |
| 能连接但读Flash全0xFF | RDP读保护、PCROP保护、地址越界 | 读选项字节，解除保护或修正地址范围 |
| 擦除失败，报cannot access memory | WRP写保护、供电电压过低、Flash控制器忙 | 取消WRP，检查VDD，断电重启后重试 |
| 写入校验失败 | 地址未8字节对齐、WRP保护、校验算法不一致 | 按8字节对齐重写，取消保护，用XOR校验 |
| 烧录成功但程序不跑 | BOOT0仍为高、nBOOT_SEL配置不对、应用固件时钟配置 | 恢复BOOT0低电平，检查选项字节启动源，检查外部晶振启动配置 |
| 刷写过程中随机失败 | 供电不足、串口线过长、电磁干扰 | 独立供电，缩短串口线，降波特率到9600 |
| Keil里报flash download failed - cortex-m3 | 芯片型号选错、Flash算法缺失、RDP保护 | 检查Keil Device选择，添加STM32L0xx Flash算法，解除RDP |
5.2 避坑清单
以下几项是我这轮调试下来觉得最值得提醒同行的经验：
- 不要把BOOT0直接接3.3V，中间串个1k电阻。这样方便用万用表量电平，也方便飞线。直连的话万一接线短路，MCU的启动引脚容易受损。
- BOOT0和NRST引出来做成两个测试点。哪怕板子空间再紧张也值得。有了这两个测试点，后期刷写、救砖、调试都方便。量产板还可以做成双排针，配合夹具一键烧录。
- 烧录前先把Flash读一遍。如果板子上有旧固件，先读出来备份，再擦除。不要一上来就Erase，不然旧程序丢了后悔都来不及。
- 不要在擦写进行中断电。Flash擦写中途断电，轻则数据损坏，重则选项字节错乱导致芯片锁死。量产时如果供电不稳，建议加电容或者用带过流保护的烧录器。
- 检查选项字节的nBOOT_SEL。如果在Bootloader场景下BOOT0拉高没反应，第一反应就是看这个位，而不是反复换串口工具。
- 尽量用独立电源给板子供电，不要从USB转TTL模块取电。USB转TTL模块的输出电流通常只有几十毫安到一百毫安，Flash擦写瞬间的电流尖峰容易把电压拉掉。
5.3 IDE直接下载失败和Bootloader问题要分开排查
热搜词里有一个“error: flash download failed - cortex-m3”，这个错误很多人都遇到过，但它和ST系统的Bootloader本质上没有关系，属于两条排查线路。
如果是在Keil MDK或者IAR里用ST-Link/J-Link直接下载时遇到这个错误，常见原因是：
- Keil里Device型号没选对，比如把L071KZ选成了L073或者别的L0型号，Flash算法加载错误。
- Flash Download页面的Programming Algorithm列表里没有添加对应的L0 Flash算法。
- 芯片被RDP Level 1保护，调试口被禁用，调试器无法访问Flash。
这类问题不要往Bootloader上靠，直接查IDE配置和解保护就行。我有一块板子就是之前测试时设置了RDP Level 1，后来在Keil里下载报这个错，用CubeProgrammer连ST-Link解掉RDP之后恢复。
6. 写在最后：这次折腾给我留下的三个习惯
折腾了一整晚之后，我给自己定了几条规矩，现在做L0系列项目基本不再被Flash刷写问题卡住。
第一，拿到新板子先不做功能调试，先把选项字节完整读出来保存一份。这样后面无论出了什么问题，都能对照最初的选项字节配置，快速判断是软件改了它还是硬件异常改了它。
第二，所有涉及Bootloader刷写的测试，统一用CubeProgrammer的日志功能。每次操作都导出完整日志，里面会记录错误码和寄存器状态，比肉眼盯屏幕靠谱得多。
第三，量产工装里保留一个“仅解锁”模式，专门用于处理返修板。返修板进线后先解保护、全片擦除、再重新烧录，避免因为RDP保护导致整块板报废。
最后分享一个小技巧：如果板子上BOOT0引脚实在没法操作，可以试试用I2C或者SPI接口进Bootloader。只要这几个引脚留出来了，就能绕过USART引脚占用的限制，依然完成刷写。L0的Bootloader支持多接口，这也是它的一个隐藏优势。希望这次的踩坑记录能帮大家少走几个弯路。
)