STM32L4内部Flash读写实战：解锁、页擦除与64位编程全流程

简介：面向采用意法半导体STM32L4系列微控制器的嵌入式开发者，这套内部闪存读写驱动方案已在项目中调通，核心代码基于LL库与寄存器操作编写，并在具体芯片型号上完成验证；若切换到HAL库环境，只需调整对应的宏定义即可复用。压缩包内共包含两个文件，分别是一个C源文件和一个头文件，整体体积仅2KB，代码量精简，便于直接嵌入现有工程并按需裁剪。作者还记录了后续适配其他型号芯片时的关键排错经验：部分L4系列芯片的闪存页码不连续，按默认逻辑擦页会失败，修改擦页函数中的页码号即可解决。这一提醒对于使用L4x1系列或者打算在不同型号间移植代码的开发者尤其实用，可减少反复排查的时间。目前已有1935人学习下载，适合需要快速实现闪存读写功能的初中级嵌入式工程师参考。

1. 内部FLASH不是黑匣子：一个能把STM32L4读写链路跑通的Demo

做Bootloader升级或者掉电参数存储时，大部分人第一次碰内部Flash都会被擦写翻车劝退：写进去读出来是0xFF，擦除时程序卡死，严重时仿真器都连不上芯片。这份基于STM32L4xx的读写内部Flash Demo，用LL库和寄存器操作两条路线把解锁、页擦除、64位双字编程、读回校验这一整条链路全部打通——下载后烧录就能看到Flash地址从0xFF变成写入的测试数据，全程有串口打印和错误码，不用靠猜。适合正准备做OTA、想存校准则参数、或者刚接触L4系列想搞懂Flash底层时序的开发者。项目不大，但每个环节都是做产品前必须趟平的坑。

2. 项目形态与技术选型：LL库、寄存器与工程结构

2.1 这个Demo到底做了什么

先明确这份资源不是高大上的完整工程框架，而是一组聚焦的Flash读写工具代码加一个验证入口。它把操作内部Flash这件事拆成五个独立动作：初始化解锁、页擦除、64位编程写入、读回校验、结果打印。测试地址默认放在0x08008000，这是L4系列内部Flash主存储区的用户可用区域（0x08000000起始，L4标准页大小2KB，不同型号容量不同），避开低地址的启动代码区，不容易把系统搞挂。

执行流程很直白：上电后先调Flash_Init解锁FLASH控制逻辑，然后擦除测试地址所在页，紧接着写入一个64位的测试数据，再把这个地址上的内容读回来逐字比对，串口把每一步操作的状态打出来。成功时能看到写入值和读回值完全一致，失败时能看到具体错误码（对齐错误、校验失败、BSY超时），而不是面对一个黑匣子干瞪眼。

这里有一个很容易误解的地方：很多人以为写内部Flash像写SRAM那样直接赋值就行，其实Flash必须先擦除再编程，而且擦除的粒度是一整页，不能像SRAM那样按字节清零。Demo把“擦除”和“编程”分成两个函数就是这个原因，后续做Bootloader或参数存储时，这两个动作也必须分开控制——否则你会在“为什么写入前要擦一整页”这个问题上浪费一整天。

2.2 为什么选LL库而不是HAL

选型原因值得多说两句。L4系列的官方驱动包里同时提供HAL库和LL库，HAL库是厚而重的全功能封装，初始化外设确实方便，但Flash擦写这种时序敏感操作，HAL库会在里面插入各种状态检查和超时等待，出了问题反而不容易定位到硬件行为。LL库只做一层很薄的寄存器映射封装，保留底层控制感，代码精简、执行路径短，适合用来理解Flash时序。

三个档次各有用途。项目赶进度直接HAL，想搞明白Flash的擦写时序和避坑点，建议用LL库跟着走一遍寄存器流程。这份资源把LL库和寄存器两版都提供了，同一份工程里能对照着看——LL库里某个操作到底改的是哪个寄存器，翻一下寄存器版代码就清楚了，这种双视角结构在网上的例程里很少见。

2.3 工程目录结构与关键文件

解压后是标准的STM32工程布局，没有花哨的文件夹。核心代码集中在应用层两个文件里：flash_if.c是Flash读写功能实现，main.c负责调用顺序和串口打印。驱动层用L4系列的LL库（和HAL库同包），CMSIS提供寄存器地址定义。

移植到自己板子上的时候，注意LL库的函数签名在不同型号上有细微差别，比如Bank枚举在部分L4型号上叫LL_FLASH_BANK_1，某些衍生型号可能带LL_FLASH_BANK_ALL；个别早期版本LL_FLASH_EraseFlashPage甚至只有地址参数没有Bank参数。移植时先打开头文件看一眼具体枚举和函数原型，别盲抄。另外一个通用习惯：在自己工程的芯片型号头文件里确认FLASH_PAGE_SIZE这个宏，L4系列一般是2048，个别型号有差异，页大小直接决定了擦除地址要对齐到哪个边界。

3. 核心模块拆解：一次写入从解锁到读回的完整链路

3.1 解锁：KEYR密钥与FLASH_Init

FLASH控制器在复位后处于锁定状态，所有修改CR寄存器（控制寄存器）的操作都会被忽略。必须先往KEYR（密钥寄存器）依次写入两个固定的32位密钥——0x45670123和0xCDEF89AB，FLASH才解锁。LL库把这步封装成了LL_FLASH_Unlock()，反汇编看到的实际就是连续两次写KEYR寄存器。

void Flash_Init(void) { if (LL_FLASH_IsActiveFlag_BSY()) { LL_FLASH_ClearFlags(LL_FLASH_FLAG_ALL); // 清掉残留错误标志 } LL_FLASH_Unlock(); // 连续写两次KEYR完成解锁 LL_FLASH_EnablePrefetch(); // 打开预取缓冲 }

逻辑说明：Flash_Init在系统上电后调用一次。第一段先检查BSY（忙标志），如果上一次异常复位留下了未完成的操作，先清标志避免后续轮询读到脏状态。LL_FLASH_Unlock是解锁入口，把两把密钥按顺序写进KEYR，写错顺序或只写一把都会被硬件忽略。EnablePrefetch打开预取缓冲，Flash读取速度会快一些，L4跑较高系统时钟时属于推荐配置。

参数说明：LL_FLASH_IsActiveFlag_BSY不需要参数，读的是FLASH_SR寄存器的BSY位；LL_FLASH_ClearFlags的参数是位掩码，写成LL_FLASH_FLAG_ALL表示把错误标志全部清掉。Demo为了上手简单用了全清，实际产品里建议先读SR判断是什么错误再决定怎么清，直接全清会把有效诊断信息抹掉。

解锁这个动作是关键前提，它决定了后续所有CR操作是否有效。常见的现象是：没有解锁就调用擦除函数，函数返回正常但Flash内容一点没变，或者写KEYR的时序不对，FLASH控制器直接忽略后续操作。遇到这种“擦了没反应”的问题，先检查有没有调Flash_Init，别急着怀疑硬件坏了。

3.2 页擦除：先擦后写，2KB一页

L4系列的Flash按页管理，标准页大小2KB。擦除的最小单位是页，无法按字节或半字擦除，擦除后这一页内容全部变成0xFF，这是Flash的物理特性。写入操作只能把1写成0，不能把0写成1，所以写入之前必须先擦除目标页，否则写操作就是在旧数据上叠加，结果必然错乱。

#define FLASH_TEST_ADDR 0x08008000UL // 测试用目标地址 uint8_t Flash_ErasePage(uint32_t page_addr) { while (LL_FLASH_IsActiveFlag_BSY()); // 等待上一条Flash操作结束 LL_FLASH_EraseFlashPage(LL_FLASH_BANK_1, page_addr); // L4页擦除：置PER模式 + 写AR目标地址 + 拉STRT触发，LL库一次完成 while (LL_FLASH_IsActiveFlag_BSY()); // 等待本次擦除完成 return FLASH_IF_OK; }

逻辑说明：函数入参是目标页的起始地址，不是页编号，LL库内部会按地址换算到具体页。第一个while循环做互斥，保证上一个Flash操作（可能是编程也可能是擦除）彻底结束之前，新的操作指令不会被覆盖。LL_FLASH_EraseFlashPage内部做了三件事：把CR寄存器置为页擦除模式、把目标地址写入AR寄存器、把STRT位拉起开始擦除。第二个while循环等BSY清零，擦除过程一般需要十几毫秒量级，阻塞轮询是合理的，因为擦除期间Flash控制器的状态机就是忙的，做不了别的事。

参数说明：LL_FLASH_BANK_1是Bank编号枚举，L4系列地址空间分Bank1和Bank2，0x08000000到0x0807FFFF一般是Bank1。传入的page_addr必须对齐到页边界，即2KB整数倍，如果地址落在页中间，硬件行为未定义。返回FLASH_IF_OK表示擦除正常完成，实际擦除失败的场景多发生在电压跌落或温度异常时，正常室温调试很少出现。

不少人在这步翻车的原因是传了页内偏移地址而不是页起始地址，比如往0x08008100擦除，实际擦掉的是0x08008000这一页，看起来像“擦错页了”。更隐蔽的是往Bank2的地址擦除，代码却按Bank1的逻辑校验，地址合法但数据和预期对不上。第4章会展开说这类问题。

3.3 64位编程：对齐、PGSIZE与LL_FLASH_Program

擦除完就能写入了。L4系列的Flash编程支持三种宽度：32位编程、64位双字编程和快速编程。最常用的是64位编程，因为L4的Flash编程物理单元是双字（8字节），用32位编程反而要按硬件规则拆分成对的双字操作，更容易踩对齐的坑。这个Demo用的就是64位编程。

uint8_t Flash_WriteDoubleWord(uint32_t addr, uint64_t data) { uint64_t rd = 0; if ((addr & 0x07U) != 0U) { // 8字节对齐检查 return FLASH_IF_ERR_ALIGN; } while (LL_FLASH_IsActiveFlag_BSY()); LL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, addr, data); // 内部：置PG编程模式 + 设置PGSIZE为64位宽度 + 写数据到目标地址 while (LL_FLASH_IsActiveFlag_BSY()); rd = *(volatile uint64_t *)addr; // 读回，校验写入结果 if (rd != data) { return FLASH_IF_ERR_VERIFY; } return FLASH_IF_OK; }

逻辑说明：函数开头先做对齐检查，addr低3位必须为0，因为64位编程要求8字节对齐。没有对齐直接返回错误码，这是避免HardFault的第一道防线。中间的LL_FLASH_Program是写入核心，LL库根据传入的FLASH_TYPEPROGRAM_DOUBLEWORD把CR寄存器配置成64位编程宽度，再把data写入目标地址对应的存储单元，硬件检测到地址写操作后自动触发编程状态机。两个while轮询保证写前写后都处在非忙状态。写完立刻用volatile指针把该地址强制读回，与原数据比对。volatile在这里很关键，Flash区域在编译器视角可能被优化成从缓存读，加volatile强制走总线访问实际存储单元。

参数说明：FLASH_TYPEPROGRAM_DOUBLEWORD是LL库枚举，对应寄存器里PGSIZE字段设为64位宽度；data是64位无符号数，一次写入8字节。返回值三种：FLASH_IF_OK、FLASH_IF_ERR_ALIGN（地址未对齐）、FLASH_IF_ERR_VERIFY（写后读回不一致）。实际写的时候发现ERR_VERIFY，大概率是擦除没成功，或者写入前BSY没有真正清掉，回头查Flash_ErasePage的地址参数。

一个容易忽略的性能点：64位双字写入一次最多写8字节，如果要写一大片参数区，循环调用这个函数即可，每次地址加8。不要试图搞一个“内存拷贝”式的大块写入，Flash编程必须按硬件规定的宽度一次一次来，循环本身不慢，慢的是擦除那一步。

3.4 读回校验与main流程

LL库版本把整个链路串起来，在main里长这样：

int main(void) { uint8_t ret = FLASH_IF_OK; SYSTEM_Init(); // 时钟、串口初始化（略） Flash_Init(); printf("[FLASH] init done\r\n"); ret = Flash_ErasePage(FLASH_TEST_ADDR); printf("[FLASH] erase ret=%u\r\n", ret); ret = Flash_WriteDoubleWord(FLASH_TEST_ADDR, 0x1122334455667788ULL); printf("[FLASH] write ret=%u\r\n", ret); uint64_t val = *(volatile uint64_t *)FLASH_TEST_ADDR; printf("[FLASH] read back: 0x%08X%08X\r\n", (uint32_t)(val >> 32), (uint32_t)val); while (1); }

逻辑说明：main先初始化系统时钟和串口，然后按解锁→擦除→写入→读回的顺序执行。每一步都打印返回值，读回的val应该等于0x1122334455667788。这个流程已经是一个完整的冒烟测试，没有多余功能，方便新手验证自己的板子是否正常。如果串口打印的读回值是0xFFFFFFFFFFFFFFFF，说明擦除失败或写入没触发，回头查解锁和擦除环节。

参数说明：SYSTEM_Init是时钟和串口的初始化入口，不同开发板串口引脚不一样，移植时改成自己板子的串口配置即可。printf重定向到串口的实现依赖具体IDE和库，有些嵌入式printf不支持%llX格式，所以代码里把64位值拆成两个32位分别打印，高32位在前低32位在后，这个写法在任何C库下都能用。

3.5 寄存器直操作：疑难问题排查的照妖镜

寄存器直操作版本的意义在于透明度。LL库虽然薄，毕竟还是封装，真正调试疑难问题时直接看寄存器最直观。L4擦除一页的寄存器操作是这样的：

void Flash_PageErase_Reg(uint32_t page_addr) { while (FLASH->SR & FLASH_SR_BSY); // 等不忙 FLASH->CR |= FLASH_CR_PER; // 页擦除模式 FLASH->AR = page_addr; // 目标页地址 FLASH->CR |= FLASH_CR_STRT; // 开始擦除 while (FLASH->SR & FLASH_SR_BSY); // 等擦除完成 FLASH->CR &= ~FLASH_CR_PER; // 退出擦除模式 } void Flash_Write64_Reg(uint32_t addr, uint64_t data) { while (FLASH->SR & FLASH_SR_BSY); FLASH->CR |= FLASH_CR_PG; // 编程模式 FLASH->CR |= (2U << FLASH_CR_PGSIZE_Pos); // 64位编程宽度 *(volatile uint64_t *)addr = data; // 写入即触发编程 while (FLASH->SR & FLASH_SR_BSY); FLASH->CR &= ~FLASH_CR_PG; // 退出编程模式 }

逻辑说明：寄存器版本和LL库版逻辑一一对应。FLASH_CR_PER对应页擦除模式位，FLASH_CR_STRT是启动位，一次擦除流程必须按“置PER→写AR→置STRT→等BSY→清PER”顺序执行，不能颠倒。编程流程是“置PG→设PGSIZE→写地址触发→等BSY→清PG”。注意写入操作本身是通过对目标地址赋值触发的，不是通过CR寄存器触发的，这是新手最容易懵的地方：看起来像普通内存赋值，实际上写这一行代码的瞬间，Flash控制器接管总线开始编程。

参数说明：FLASH_CR_PGSIZE_Pos在CMSIS头文件里定义，是PGSIZE字段的偏移量；2U表示64位编程宽度，如果用32位编程这里要改成1U。FLASH->SR的BSY位在第16位，判断忙状态就是读这一位。寄存器版本写起来啰嗦，但任何异常都能在调试器里直接看到CR和SR的状态，比如发现CR置了PG但SR的BSY一直为1，说明状态机被中断干扰卡住了，这种问题在LL库里只能靠猜，在寄存器版里一眼就能看出来。

4. 避坑指南：Flash擦写中的常见翻车现场

Flash擦写是嵌入式领域最典型的“玄学重灾区”，很多问题不是逻辑写错，而是对硬件行为理解有偏差。下面几条都是踩过的坑，按现象→原因→解决顺序写，碰到类似症状可以顺着排查。

4.1 现象：写入后读回全是0xFF

这个是最常见的翻车现场。代码逻辑看起来完全没问题——先擦除再写入，读回却是0xFFFFFFFF，像是写入操作根本没有生效。

原因：地址参数传错了。擦除函数要求传页起始地址，也就是2KB的整数倍，很多人直接传目标数据的地址，比如0x08008100，而0x08008000这一页才是实际被擦除的页。随后写入操作写到0x08008100上，这个地址刚被擦成0xFF，写入的内容又被覆盖成0xFF。另一种情况是调用了擦除但擦的是Bank2的页，写入却写到了Bank1，两个地址看起来都合法，串起来就错位了。

解决：擦除前打印一下页起始地址和Bank编号，确认和目标地址在同一个Bank。调试器里直接看FLASH->AR寄存器的值，就知道硬件实际收到的擦除地址是什么。我的习惯是定义一个宏，把目标地址注释上“页起始：0x08008000，页内偏移：0”，避免过两周自己都不知道当初传的是什么。

4.2 现象：擦写过程中程序卡死，像死机一样

程序跑到Flash擦除或写入的while等BSY循环里出不来，串口不再打印，调试器暂停后看到程序停在轮询BSY的下一条指令。

原因：绝大多数是中断惹的祸。擦写Flash期间来一个中断，中断服务函数里的代码正好在Flash上取指执行，和正在进行的编程操作抢同一个Flash控制器。虽然L4支持RWW（读-写-同时执行），但条件是读和写需要在不同Bank，或者代码在RAM里执行。系统默认的SysTick处理函数、串口中断都在Flash，一进中断就撞车。另一个原因是擦除Bank1的同时当前程序正运行在Bank1，等于在擦自己的代码区，等BSY永远等不到头。

解决：擦写过程前后用关中断指令包住，让擦写在原子环境中完成。如果擦除的不是当前执行所在Bank，可以把中断服务函数和主循环代码全部搬到RAM执行。还在卡死的话，确认一下当前PC指针所在的地址段，是不是正好落在目标Bank里——调试器里查看PC寄存器和SP寄存器，对照地址区间就能判断。

4.3 现象：写入后仿真器连不上芯片

这个最吓人。程序跑了一次写入，然后调试器再也连不上，报错提示连接失败，感觉芯片被写坏了。其实芯片没坏，只是Flash的选项字节（Option Bytes）被意外改写了。

原因：写入地址越界，写到了选项字节区域，或者代码里动了RDP（读保护）等级。RDP等级从Level 0改成Level 1之后，调试接口直接被锁死，外部工具无法再读写Flash。某些非法写入操作会让芯片进入保护状态，用编程器连接时握手失败。

解决：别慌，这个状态用Boot引脚拉高配合全擦除可以救回来。把Boot0拉高重新上电，芯片从系统存储器启动，用配套工具执行整片擦除（Mass Erase），选项字节恢复成出厂值。这之后我给自己定了个规矩：每次测试Flash写入代码之前，先读一遍RDP等级，确认是Level 0再开跑，调试器连不上这种事一次就够受的了。

4.4 现象：写入时触发HardFault

程序在执行Flash_WriteDoubleWord或者寄存器直操作版本时，直接跳进HardFault_Handler。

原因：地址访问违规。最常见的是地址没有对齐——64位编程对8字节对齐有硬性要求，地址低3位非0时总线直接报错。其次是写到了Flash地址空间的保留区域或者容量边界之外，比如某型号实际只有512KB Flash，地址范围0x08000000到0x0807FFFF，往0x08090000写就是访问不存在的存储区，总线错误。

解决：函数入口做对齐检查，不对齐直接返回错误码而不是继续执行。写之前运行时判断目标地址是否落在Flash合法范围内，编译期也可以用静态断言卡住越界地址。HardFault的现场在调试器里能看到出错地址，把出错地址减去FLASH_BASE得到偏移量，再对照这个型号的Flash容量，能快速定位是越界还是对齐问题。

4.5 现象：擦写完成后系统变慢，外设行为乱掉

Flash读写都成功了，但程序主频掉了，跑起来明显变慢，或者某些外设直接乱码。

原因：Flash等待周期（LATENCY）配置问题。L4系统时钟跑得比较高，Flash读取需要插入等待周期才能保证时序，这个等待周期存在FLASH_ACR寄存器里。某些代码在时钟初始化后把FLASH_ACR覆盖了，或者低功耗模式切换时钟后没有重新配置LATENCY，Flash读取时序错乱，表现为整体变慢或者指令取错。

解决：检查时钟初始化代码，确保HCLK频率和FLASH_ACR里的LATENCY匹配。L4系列手册里有对应关系表，比如HCLK跑到80MHz需要4个等待周期。改完时钟树之后重新确认一遍LATENCY寄存器没有被覆盖，尤其是低功耗唤醒路径上。这条问题最难排查，因为写Flash本身是成功的，症状出现在Flash之外，遇到系统慢半拍的诡异问题先查这里。

5. 二次开发：把读写Demo改造成可靠的参数存储模块

5.1 从裸函数升级到带校验的存储结构

直接裸写Flash验证时序没问题，但放进产品代码里活不过第一轮掉电测试。产品断电不会挑“你刚好写完”的时候断，可能写到一半断电，重启后读到的就是半截数据。改造办法是给存储区定义一个带魔数、版本、CRC的结构体，每次写入前算CRC，读的时候先验魔数再看CRC，校验不过就回滚到备份数据。

typedef struct { uint32_t magic; /* 固定魔数，如 0xA5A5A5A5 */ uint32_t version; uint32_t crc; /* 对 data 数组的 CRC32 结果 */ uint8_t data[64]; /* 业务参数区 */ } param_block_t;

写入流程变成：先擦除目标页，构造param_block_t并计算CRC，再用Flash_WriteDoubleWord按64位宽度分块写完整个结构体，最后读回校验。读流程变成：读整块数据，先检查magic，再重算CRC和存储的crc比对，不一致说明写入被断电打断，这时用备用槽的数据恢复。这套模式就是掉电安全参数存储的最小实现，比裸写可靠得多。

5.2 双槽轮换与Bootloader衔接

再往上走一层，用两个备份槽做A/B切换：固定Slot A和Slot B，写之前先看当前活跃槽，写到另一个槽里去，写完校验通过再切换活跃标记。这样任何一次写入失败，总有上一次完整数据可以恢复，代价是Flash容量换可靠性，而且天然实现磨损均衡，避免总擦同一页把页寿命用光。L4的Flash擦写次数典型值是1万次量级，用双槽能把等效寿命拉高一倍。

和Bootloader衔接时有两个细节：跳转到App之前必须关全局中断并把SysTick复位，防止App启动时中断向量还是旧的；如果App要擦除Bootloader所在Bank，代码必须整个在另一个Bank或RAM里跑，这条规则和4.2提到的RWW限制是同一个道理。换地址时记得同步更新链接脚本的FLASH起始地址，别让App自己把自己覆盖了。

整套改造做完，这个Demo已经能当一个小型参数模块用。以后我每次换目标页或者动Flash选项字节，都会强制走一遍“确认RDP等级→擦除→写回→读校验”的完整流程，宁可多花几分钟，也不想再被仿真器连不上折磨。希望帮到你。

本文还有配套的精品资源，点击获取