内部FlashHAL库bin文件——这三个词放在一起就是很多单片机学习者从“能跑程序”走向“会做产品”的一道分水岭。我最近在整理HAL库系列学习笔记第十一篇正好写到内部Flash的读写顺手把怎么生成bin文件、估算程序占用Flash大小也聊透。这篇文章拿一个保存用户参数的场景把两部分串起来第一部分先搞懂Flash为什么先擦后写、HAL库的读写API怎么用第二部分讲清HEX、AXF、BIN的区别然后在MDK里配置生成bin文件。做嵌入式开发做到一定阶段手里总有几个项目会出现这种尴尬用户配置要保存掉电不能丢标定系数要调整每台设备的数值还不一样又或者产品要OTA升级得先弄清楚现在编译出来的程序到底有多大。我以前一直把这些事拆开处理后来发现它们都绕不开两个基础技能——操作内部Flash以及通过bin文件评估固件体积。这篇笔记就专门把这两件事放在一起讲适合刚学完HAL库基础外设、想继续深入存储和固件管理的开发者也适合做BootLoader之前先补课的朋友。1. 内部Flash到底能干什么它和EEPROM、外部Flash不是一回事1.1 你可能一直小看了Flash很多朋友用单片机第一年对Flash的印象就是“下载程序时它用来存代码”。确实芯片上电后CPU从Flash取指令执行但Flash并不只是“只读”的存在。只要芯片支持在代码运行过程中同样可以解锁Flash、擦除扇区、写入数据下次上电之后这些数据依然还在。这就是内部Flash除了跑程序之外的另一个价值掉电不丢的存储空间。我见过不少产品把用户参数、校准系数、设备序列号、运行日志甚至OTA标志直接放在内部Flash里。原因很简单不加任何外部芯片不增加PCB面积和BOM成本读取的时候还特别快。而且现在很多MCU内部没有真正意义上的EEPROM或者EEPROM容量小得可怜这时候用内部Flash来模拟一段非易失存储就是性价比最高的方案。1.2 一张表看懂Flash和EEPROM的差异我们常说“Flash模拟EEPROM”那它和真正的外挂EEPROM有什么区别我整理了一张表方便新手建立概念对比项内部Flash外挂I2C EEPROM如24系列外挂SPI Flash数据通路内部总线直接访问I2C串行通信SPI串行通信读取速度最快可当内存读慢按地址读中等页读为主擦写粒度扇区/页通常几KB到几十KB字节级灵活扇区级一般4KB擦写寿命通常10万次左右通常100万次通常10万次接线难度无需外接需要两根线需要四根线适合场景程序存储批量参数保存小数据、频繁改写字库、固件备份、大数据这张表最关键的一点是擦写粒度。内部Flash的最小擦除单位是一个扇区可能是1KB、4KB、8KB甚至128KB而不像EEPROM那样可以单独改一个字节。这就意味着哪怕你只想改掉一个参数也得把整个扇区先擦掉再重新写入。这也是后面代码里最大的坑。1.3 想用Flash存数据先接受三条物理规则我在带新人时经常说操作Flash之前先背三条规则第一写入只能把1变成0不能把0变成1。也就是说如果Flash某一位当前是0你想直接写成1硬件上是做不到的。必须先执行擦除操作把整个扇区恢复成全1即0xFF然后才能写。这和RAM完全不同很多人第一次写Flash失败就是因为没擦。第二擦除的最小单位是扇区不是字节。哪怕你只想清掉一个字节也必须把所在扇区全体擦一遍。所以设计数据存储结构时要尽量让一个扇区只承载一类数据避免频繁擦除大扇区。第三擦写寿命有限。内部Flash的擦写寿命通常在1万到10万次之间不同芯片差异很大。你不可能像用RAM一样高频地写Flash否则很快把扇区磨损。产品里如果用Flash保存频繁变化的数据必须自己做磨损均衡或者把“写Flash”这种操作设置得非常谨慎。理解了这三条后面的HAL库操作代码就顺理成章了先解锁再擦除再编程最后上锁。2. Flash操作的底层逻辑先擦后写还有最小单位这个坑2.1 从“橡皮擦作业”理解为什么必须先擦后写我在课堂和群里都爱打一个比方内部Flash就像一张写满了铅笔字的白纸铅笔写上去容易但想把某个字改成另一个字尤其是把浓重的笔画擦没你没法用笔尖直接刮掉必须用橡皮擦。Flash里的“橡皮擦”就是擦除操作而且这块橡皮很大一擦就是一整块区域。你可能会问为什么Flash不设计成直接改写呢这要从存储单元的物理结构说起。Flash的存储单元基于浮栅晶体管写入是通过隧穿效应把电荷注入浮栅而擦除是把电荷从浮栅中拉走。硬件上“注入电荷”只能让存储状态从1变成0而“拉走电荷”需要更高的电压和更复杂的机制所以只能通过擦除实现。芯片设计时把大量单元连成片共享擦除高压电路于是最小擦除单位就成了一个扇区。这个原理具体到代码上就是HAL库里的HAL_FLASHEx_Erase和HAL_FLASH_Program两个核心函数。2.2 翻开芯片手册先确认扇区表和容量不管是哪家芯片做Flash读写之前第一步永远都是看手册查三个东西Flash起始地址、总容量、扇区划分表。以常见的Cortex-M系列MCU为例应用Flash通常从0x08000000开始但容量从64KB到1MB不等扇区划分也差异巨大。有些芯片前面几个扇区是1KB中间4KB后面32KB有些则整个都是128KB的大扇区。我一般会画一张地址草图左侧程序区右侧数据区。程序从首地址开始加载按照链接脚本和编译结果连续占用数据区则放到Flash末尾的最后一个扇区或者至少放到程序当前结束地址之后的扇区。这样最不容易冲突也符合程序向后增长的习惯。如何确认程序区到哪结束编译之后打开map文件搜索Total RW Size之类的字段或者直接看__initial_sp和代码段结束地址就能估算。更省事的办法是把数据区固定在最后一个扇区不管程序涨多大只要还没超过末尾扇区起始地址就不会撞车。这比把数据区放在中间要安全得多。2.3 读Flash和写Flash的“待遇”完全不同内部Flash的读取在绝大多数情况下是和普通内存一样直接寻址的。比如你想读地址0x08080000处的数据在C语言里写*(uint32_t *)0x08080000就行。不需要解锁不需要调用任何HAL库函数CPU可以直接从Flash读取内容。这也是前面说“读取方便”的原因。但写Flash就不一样了。为了防止程序跑飞后乱改存储芯片默认会把Flash置于写保护状态。在调用擦除或编程操作前必须通过HAL_FLASH_Unlock()解锁操作完成后再用HAL_FLASH_Lock()锁上。HAL库的这两个函数不仅仅是在寄存器里写一个标志位它还会检查解锁键序列、等待Flash状态机就绪内部逻辑比较多所以一旦调用失败返回值会直接反映问题。我习惯在调试阶段把每个HAL函数的返回值打串口或者用调试器看而不是忽略返回值。解锁之后真正干活的是HAL_FLASHEx_Erase和HAL_FLASH_Program下面一章直接上代码。3. 用HAL库把用户参数写进内部Flash一封可直接抄的代码3.1 先规划一个“用户参数区”的地址我建议在工程头文件里把地址写清楚比如#define APP_FLASH_START 0x08000000U /* 芯片Flash起始地址 */ #define USER_DATA_SECTOR 10U /* 数据区所在扇区按芯片实际情况修改 */ #define USER_DATA_ADDR 0x08080000U /* 数据区起始地址 */ #define USER_DATA_MAGIC 0xA5A5A5A5U /* 校验魔数用于判断数据是否有效 */这个0x08080000不是所有芯片都有效我只是拿一个中等容量芯片的末尾地址举例。你拿到自己的板子后一定要先看数据手册确认。方法很简单用调试器打开Memory窗口输入你怀疑的Flash末尾地址看看读回来是不是全是0xFF。如果全是0xFF说明这块区域还没有被程序占用可以用来放数据。还要注意扇区号。HAL库为每个扇区定义了常量比如FLASH_SECTOR_10你在擦除代码里必须填对。这里最容易出的问题是不同型号芯片的扇区编号和地址映射不一样同样的FLASH_SECTOR_10在不同芯片上可能对应完全不同的地址。所以定义地址和扇区号的时候一定要跟芯片手册对照。3.2 擦除扇区不只是调一个函数下面是一段完整的扇区擦除代码直接可以抄进工程改一改static void UserData_EraseSector(void) { FLASH_EraseInitTypeDef erase_cfg {0}; uint32_t sector_error 0; HAL_FLASH_Unlock(); erase_cfg.TypeErase FLASH_TYPEERASE_SECTORS; erase_cfg.Sector USER_DATA_SECTOR; erase_cfg.NbSectors 1; erase_cfg.VoltageRange FLASH_VOLTAGE_RANGE_3; if (HAL_FLASHEx_Erase(erase_cfg, sector_error) ! HAL_OK) { /* 擦除失败sector_error会指示出错的扇区号 */ } HAL_FLASH_Lock(); }这段代码看起来简单但有两个细节值得说明。第一VoltageRange这个字段不是选电压而是选择芯片内核电压范围不同系列填法不同但常见的Cortex-M系列支持范围3照抄通常没问题。第二HAL_FLASHEx_Erase内部会阻塞等待Flash操作完成如果你担心看门狗或者长中断可以在函数里加一些标志位但别把写Flash放在时间极其苛刻的地方。擦除不是越快越好。擦除期间CPU会等着如果你在擦除期间发生复位很可能留下一个擦了一半的扇区导致后读出来是一堆半FF半00的无意义数据。所以产品级的代码一般会先记录状态标志再执行擦除擦完再把标志置为成功。3.3 用HAL_FLASH_Program写入结构体数据擦完之后扇区全变成0xFF这时就可以写了。HAL库提供了HAL_FLASH_Program函数支持按字节、半字、字、双字编程。我的习惯是尽量按字或双字写速度和可靠性都比按字节好。假设我们要保存这样一个结构体typedef struct { uint32_t magic; /* 魔数 */ uint16_t version; /* 版本号 */ uint16_t length; /* 数据长度 */ uint32_t baudrate; /* 串口波特率 */ float kp; /* 某控制参数 */ } UserParams;那么写Flash的代码可以这样写HAL_StatusTypeDef UserData_Write(const UserParams *params) { HAL_StatusTypeDef status HAL_OK; uint32_t addr USER_DATA_ADDR; uint32_t *src (uint32_t *)params; uint32_t word_count sizeof(UserParams) / 4; uint32_t i; HAL_FLASH_Unlock(); for (i 0; i word_count; i) { status HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr, *src); if (status ! HAL_OK) { break; } addr 4; } HAL_FLASH_Lock(); return status; }这里的word_count必须保证结构体大小是4的整数倍。如果结构体里有奇数个uint16_t或者有char编译器可能插入填充字节sizeof结果还是4的倍数但你在别的平台解析时可能会有对齐问题。我一般会在结构体定义后加一句_Static_assert(sizeof(UserParams) 16, size mismatch);编译期验证大小。为什么用字写而不是双字因为双字要求8字节对齐而结构体里的数据往往不能保证8字节对齐。字对齐只要4字节对齐就行Cortex-M的Flash编程硬件通常天然支持。如果你确定地址是8字节对齐也可以用FLASH_TYPEPROGRAM_DOUBLEWORD一次写64位速度更快。3.4 读取与校验Flash里到底写对了没有读取比写入简单太多直接指针解引用即可const UserParams *p (const UserParams *)USER_DATA_ADDR; if (p-magic USER_DATA_MAGIC) { printf(params valid, baud%lu, kp%.2f\r\n, (unsigned long)p-baudrate, p-kp); }这就是读Flash的数据。因为HAL库没有提供Flash的“读函数”Flash区域就像普通内存一样映射在地址空间上。但要注意魔数只是很粗糙的校验实际产品还会加CRC或者校验和。我见过不少项目只判断magic结果flash写了一半或者被干扰魔数凑巧对了参数却乱套。如果你保存的数据很重要建议至少加一个简单的CRC8/CRC16写入结构体时把校验值填进去读取时重新计算对比。这里也推荐一个辅助手段调试器Memory窗口。你可以在仿真暂停时输入0x08080000直接看到Flash里的字节。小端模式下0xA5A5A5A5在内存窗口里显示为A5 A5 A5 A5如果结构体里的baudrate是0x0001C200会显示00 C2 01 00。这样能直观验证写入结果也方便排查对齐问题。4. 编译产物里的大学问HEX、BIN、AXF到底谁代表程序真实大小4.1 每个嵌入式工程师都应该关心“固件有多大”我刚开始写单片机时从来不看编译产出的大小反正能下载能跑就行。直到有一次做产品选型芯片Flash就64KB程序却越写越大一编译发现爆了才开始回头研究固件体积。后来又做OTA升级上位机要把固件分包发给设备这时候必须知道BIN文件的确切大小因为分包数量、CRC算法、Flash写入策略全都要根据它来计算。如果你不做OTA只看bin大小也能帮你判断Flash剩余空间。比如芯片Flash 128KBbin文件15KB你心里就有数剩下的空间还能放字库、放升级缓存区或者继续加功能。这个“看大小”的行为应该成为日常习惯。4.2 AXF、HEX、BIN三者的区别很多新手在工程目录里看到三个后缀名不知道谁是谁。我列个表格式内容文件体积能否直接看程序大小常见用途AXFELF格式包含调试信息、符号表、重定位最大不能体积虚胖调试器加载断点、变量查看HEXIntel HEX文本格式每行有地址和数据中约为BIN的2~3倍文件大小不可直接代表固件大小下载器烧录大部分J-Link/ST-Link支持BIN纯二进制镜像从起始地址开始连续存放最小接近真实固件数据量可以文件字节数就是需要写入Flash的字节数量产烧录、OTA升级、体积评估有人习惯用HEX文件大小乘一个系数去估计固件大小这非常不准。HEX是ASCII文本每行有冒号、长度、地址、数据类型和校验哪怕真实数据只有1KBHEX也可能有3KB以上。直接用BIN文件看大小才是最简单可靠的做法。AXF文件更不能拿来当大小参考它里面有完整的调试符号和字符串表体积比实际固件大得多。调试器能用AXF加载符号但烧录到Flash的是AXF解析出来的加载段不等于AXF文件本身。所以选型时别看AXF体积吓人。4.3 MDK里配置命令让每次编译自动产出bin在MDKKeil里生成BIN文件最常用的方法是设置一条“编译后命令”。我用的步骤是打开Options for Target。切到User标签页。在After Build/Rebuild下面的Run #1输入框里填命令。重新编译看Build Output窗口有没有报错。去工程输出目录找生成的bin文件。关键就是这条命令两种工具链写法不完全一样AC5编译器fromelf.exe --bin -o $LL.bin #LAC6编译器$K\ARM\ARMCLANG\bin\fromelf.exe --bin -o $LL.bin #L如果你安装了ARMCC也可以直接用绝对路径C:\Keil_v5\ARM\ARMCC\bin\fromelf.exe --bin -o $LL.bin #L这里$LL.bin的意思是生成一个与链接器输出文件同名的bin文件放在同一个目录。#L代表链接器输出的axf文件完整路径。如果路径里带空格必须用双引号包住。我实际用下来的感觉是优先用fromelf.exe不带路径MDK会自动去当前工具链目录找。如果命令没生效再换成绝对路径。有时候你装了AC5和AC6共存MDK默认的fromelf不一定是你想要的那一个这时候显式写路径最稳。注意如果你用的是AC6工具链目录是ARMCLANG不是ARMCC千万别照抄老教程里的路径。还有文件名里不要带空格有些SDK工程名喜欢带“-”或者中文生成的bin文件名也可能有这些字符产线脚本处理起来容易出问题。4.4 bin文件大小怎么换算成Flash占用生成bin之后右键属性就能看到“大小”和“占用空间”。我一般只看“大小”单位是字节。比如显示15284字节那这个程序大约需要14.9KB的Flash空间。但这里有个容易误解的点bin文件大小是程序数据本身需要的字节数不等于Flash擦除后占用的扇区总和。比如程序15284字节芯片Flash最小扇区是4KB那它至少会占4个扇区也就是16KB。中间有几百字节的余量是扇区对齐造成的不是“漏洞”而是Flash物理结构决定的。这个差额在OTA差分包设计时必须注意。所以在设计方案时我会把“Flash可用空间”理解为总容量减去向上取整到扇区边界的程序占用。比如128KB Flash程序15284字节按4KB扇区算程序占4×416KB剩余112KB。如果按bin大小算会误以为剩了113KB多估那么一点看似无所谓但数据区擦写容易越界。5. 串起来跑一遍读写Flash到bin文件大小实测5.1 实验目标这一章我完整演示一个实验上电后读取Flash里的用户参数如果发现magic无效就先擦除数据区扇区再写入一组默认参数然后串口打印“default params saved”如果magic有效就直接读取并打印参数同时把LED闪烁频率改掉。编译结束后生成bin文件看看固件大小。这个实验能验证三个点Flash写入是否成功、掉电后数据是否保留、bin文件生成是否正常。5.2 主循环和初始化代码我整理了一个简化版main函数int main(void) { HAL_Init(); SystemClock_Config(); MX_UART4_Init(); MX_GPIO_Init(); const UserParams *p (const UserParams *)USER_DATA_ADDR; if (p-magic ! USER_DATA_MAGIC) { UserParams defaultParams; memset(defaultParams, 0, sizeof(defaultParams)); defaultParams.magic USER_DATA_MAGIC; defaultParams.version 1; defaultParams.length sizeof(UserParams); defaultParams.baudrate 115200; defaultParams.kp 1.5f; UserData_EraseSector(); if (UserData_Write(defaultParams) HAL_OK) { printf(default params saved\r\n); } } else { printf(baud%lu, kp%.2f\r\n, (unsigned long)p-baudrate, p-kp); /* 根据参数调整LED闪烁 */ } while (1) { HAL_Delay(500); HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); } }第一次烧录时Flash数据区全是0xFFmagic不可能是0xA5A5A5A5所以程序会走写入分支。等你复位或者重新上电Flash里的数据还在magic有效就会走读取分支。这就是最直观的“掉电保存”验证。注意我在写参数之前先擦除了扇区如果扇区本来就是干净的0xFF擦除会影响性能但单次操作无所谓。产品代码里通常会记录“是否已初始化”标志已经初始化过的就不再擦除了。5.3 编译生成bin并对照芯片Flash容量代码编译通过后去工程输出目录找到project.bin右键属性改一下单位或者直接用文件管理器查看。假设我看到的字节数是19872除以1024约19.4KB。如果芯片Flash是128KB那程序只占了约15%用来做BootLoader和App分区还是很宽裕的。你可以做一个有意思的对比把编译器优化等级从-O0改成-O2重新编译再看bin文件大小通常能缩小30%甚至更多。这直观展示了编译优化对固件体积的影响。我在团队里带新人时会让他们分别编译三次把bin大小记录下来理解-O0、-O1、-Os的区别。这不只是性能问题直接关系到Flash占用。5.4 顺带用调试器验证Flash区域内容继续往下验证可以进入Debugger暂停运行在Memory窗口输入0x08080000。如果刚才写成功了应该能看到类似这样的字节序列A5 A5 A5 A5 01 00 10 00 00 C2 01 00 00 00 C0 3F其中A5 A5 A5 A5是magic01 00是version10 00是length00 C2 01 00是115200的十六进制最后00 00 C0 3F是1.5f的IEEE 754表示。看到这些说明HAL库的编程函数真的把数据写进了Flash不是只在RAM里操作。如果数据不对优先检查USER_DATA_ADDR是否在有效Flash范围内再检查结构体大小是否对齐。还有一个很常见的错误是写的时候忘了擦除直接HAL_FLASH_Program返回HAL_ERROR。遇到这种情况第一反应就是看看扇区是不是干净的0xFF。6. 我的踩坑清单Flash读写和bin文件体积相关的血泪经验6.1 擦错扇区导致程序区全军覆没我最早踩过一个大坑想把数据放到Flash中后段结果把扇区号填成了前段的一个扇区。程序下载进去一运行咔一下把正在跑的代码给擦空了芯片当场变“砖”重新下载程序才恢复。那次之后我才真正理解为什么Flash数据区要放到程序区后面。防错方法其实很简单每次擦除前先看map文件里程序区的结束地址。通常map文件的Memory Map部分会列出所有加载区的地址范围程序主体从0x08000000往后排。数据区放在最后一个扇区然后写一个编译检查#if (USER_DATA_ADDR 0x08000000 PROGRAM_FLASH_SIZE) #error USER_DATA_ADDR overlaps the program area #endif这个宏里的PROGRAM_FLASH_SIZE是你预估的程序大小可能不够精确但能挡住低级错误。更严谨的做法是根据编译产物计算但那要动构建脚本一般项目没精力搞我通常就选最后一个扇区天然规避冲突。6.2 写Flash期间被中断打断导致写入超时或数据错误HAL库的HAL_FLASH_Program是阻塞调用会等待Flash操作完成但它在等待过程中CPU依然可以响应中断。如果中断里也有访问Flash的指令或者DMA搬运的数据正好要经过Flash控制器可能会和正在进行的编程操作冲突。轻则延长写入时间重则导致写入失败。我在一个使用实时操作系统的项目里有一个周期性任务会写Flash保存运行统计结果抓包发现偶尔写入超时就是因为在写Flash过程中被高优先级任务抢占。后来我干脆在写Flash的临界区关掉调度器或者用taskENTER_CRITICAL()包起来。你如果不用RTOS至少要把Flash写入放到主循环的串行上下文里别放在运行频繁的中断回调中。6.3 掉电写坏数据没有备份机制这是产品级问题学习阶段可以不管但做量产必须想。Flash擦除和编程期间如果突然断电扇区里的数据可能处于未知状态。设计上我建议至少划分两个槽位A槽和B槽。写入时先写B槽确认成功后更新一个“当前槽索引”下次读时优先读索引指向的槽。这样即使掉电发生在写入中间另一个槽的数据还是完好的。你也可以在数据区加一个简单的标志序列写入前先写一个“准备中”标志写完数据后再写“已完成”标志。上电时如果看到“准备中”而没有“已完成”就认为上次写入异常自动回退到备份数据。这些机制在BootLoader和参数存储里几乎是标配。6.4 fromelf命令生成bin失败路径、变量、工具链版本MDK里配fromelf命令最常见的问题是报“无法打开输入文件”。我一开始也遇到过后来发现是命令里的路径没有加双引号导致包含空格的目录被拆开了。用#L包一下就好。第二个坑是AC5和AC6的fromelf路径不同。有的工程默认用了AC6但你网上搜到的是AC5的命令直接复制过来就找不到fromelf.exe。我的建议是不用写完整路径直接用fromelf.exe --bin -o $LL.bin #L让MDK自己找。如果确实要写路径AC6是ARMCLANGAC5是ARMCC。第三个坑是变量$L和$LL的区别。$L是axf文件的完整路径$LL是不带扩展名的路径变量。我第一次用的时候写成$L.bin结果生成的是project.axf.bin虽然也能用但看着难受。用$LL.bin就干净了。还有一个隐藏坑如果你的构建脚本依赖生成bin的路径尽量设置成固定输出路径不要用$LL这种相对路径。比如$K\ARM\ARMCLANG\bin\fromelf.exe --bin -o .\Output\app.bin .\Output\app.axf路径写死后产线脚本、CI集成更省事只是每次改工程名要同步改。6.5 只看bin大小就以为Flash占用忽略了扇区对齐我见过有同事用bin大小除以总容量算出占用率后说“还剩98KB可以随便用”结果数据区放多了超出实际剩余容量。原因就是bin的大小没按扇区向上取整。比如芯片Flash 128KB最小扇区4KB程序bin是20KB实际占用是5个扇区正好20KB这没问题但如果是21KB占用就是6个扇区共24KB实际可用是104KB而不是107KB。差的这3KB在数据存储规划时可能就是压垮骆驼的稻草。我的习惯是在注释里写清楚/* 程序bin约21KB占用4KB扇区6个共24KB剩余104KB */这样后面改代码的人心里有数。如果你不想手动算可以在生成bin后用一个小脚本获取大小再打印到构建日志但这属于进阶玩法这里不展开。6.6 读取非法Flash地址导致HardFault内部Flash不是所有地址都能随便读。系统存储区、选项字节区、以及某些保留区域可能在读的时候直接触发总线错误进了HardFault中断。所以用指针读Flash时务必确认地址落在用户Flash范围内。我调试时有一次把地址写到0x08000000之前结果芯片直接HardFault查了半天才发现是地址越界。后来我封装了一个统一的读取函数每次访问前做边界判断static int UserData_IsValidAddr(uint32_t addr) { return (addr APP_FLASH_START addr APP_FLASH_START APP_FLASH_SIZE); }地址校验看着多写几行但能帮你少调一晚上的HardFault。最后再分享一点体会内部Flash的读写和bin文件的生成单独看都不算复杂但把它们组合起来就是一个完整的“自举能力”你会存参数了就能做带记忆的设置你会看bin大小了就能规划BootLoader分区和OTA升级。我现在每编译完一个工程都会顺手看一眼bin文件大小再想想当前Flash容量余额。这个习惯帮我提前发现了不少“快超了”的风险。如果你正在做批量产品建议把bin文件生成放到自动构建流程里产线上只烧bin不烧HEX这样既可以严格控制固件版本也能在发布前用脚本自动检查固件大小是否符合分区限制。如果对Flash读写还想继续深入下一步可以研究Flash模拟EEPROM的磨损均衡算法或者基于内部Flash的BootLoader跳转那都是非常实用的方向。