前阵子有个做物联网网关的朋友又来找我说照着网上教程把FATFS挂到W25Q16上f_mount返回FR_OK建文件也正常可跑了个把小时往里面写日志后再上电文件系统直接挂了返回FR_NO_FILESYSTEM。我远程看了他的底层代码问题一目了然disk_write里把512字节的逻辑扇区直接当成了Flash物理扇区也没做擦除纯靠内存里的数据以为写进去了。这个坑其实很多人都踩过。W25Q16这种SPI NOR Flash容量不大2MB但胜在便宜、接口简单、引脚占用少很适合在STM32项目里做日志存储、字库存储、固件升级缓存这类活。而FATFS是嵌入式领域最常用的文件系统两者组合是经典搭配。但有个关键矛盾很多人没意识到FATFS的读写单位是512字节的逻辑扇区W25Q16的擦除单位却是4KB的物理扇区两者之间差了8倍。这个不对齐不只是性能问题而是直接决定你的Flash会不会在几个月内被写报废、掉电后文件系统会不会损坏。这篇文章我就从头到尾把整条链路走一遍SPI通信怎么配、W25Q16驱动怎么写、diskio怎么移植、以及标题里那个扇区管理优化方案到底优化了什么。整个过程我会用HAL库的写法给完整代码也会讲清楚每一步背后的原因。1. 为什么是W25Q16FATFS存储需求与选型逻辑1.1 W25Q16的基本盘2MB能干什么先看芯片本身。W25Q16是华邦的SPI NOR Flash16Mbit也就是2MB。别嫌小在MCU场景里这个容量能干的活不少存中文字库16x16点阵的GB2312全字库大约2MB左右W25Q16刚好能放下常用字库子集存运行日志按每条约100字节算2MB能存约2万条配合循环覆盖可以跑很久存固件升级包STM32F103这类芯片的固件一般几十到几百KB2MB绰绰有余存参数配置和BootLoader备份区这反而是它最擅长的场景它和SD卡、EEPROM、内部Flash的对比也值得说一下我平时选型基本按这个逻辑存储介质容量擦写寿命写入速度适合场景内部Flash几十~几百KB约1万次较快参数存储、固件I2C EEPROM2KB~256KB约100万次慢少量频繁改写参数W25Q162MB约10万次中等字库、日志、升级包SD卡大与磨损均衡相关快大容量数据采集注意一个数字W25Q16的擦写寿命标称是10万次每个扇区。这个数字看着不小但在文件系统场景下如果实现得不好几天就能耗尽后面第五节我会专门算这笔账。1.2 为什么需要FATFS裸Flash的痛点如果不加文件系统直接往W25Q16里读写数据你会立刻碰到几个问题不知道哪些地址被用了哪些是空的数据长度变了之后旧数据和文件头对不上想按文件名找数据完全没有这个概念写了一半掉电整个存储区域变成垃圾而且不知道哪里是垃圾FATFS干的事就是把这一切封装起来。它帮你维护FAT表、目录项、簇的分配与释放你只需要f_open、f_write、f_read、f_close跟用电脑上的文件系统一样。在MCU上跑FATFS是嵌入式开发里的标配操作而且R0.15版本对资源要求不高一个STM32F103就完全带得动。1.3 移植前必须想清楚的四层结构作为一个做过两三次移植的人我强烈建议动手前先把层次关系在脑子里过一遍。从底往上依次是SPI硬件层负责把字节按SPI时序发出去W25Q16驱动层把SPI收发封装成Read、Write、Erase这种Flash操作FATFS diskio层把Flash操作包装成FATFS能识别的disk_read、disk_write、disk_ioctlFATFS应用层直接调用f_mount、f_open、f_write等API这篇文章的标题从SPI协议到文件系统本质上就是在讲这四层怎么打通。很多人移植失败就是因为跳过了某一层——比如以为FATFS可以直接调HAL的SPI接口或者把disk_write实现成直接写Flash不管擦除那后面出问题就一点都不奇怪了。2. 移植前的通信底座SPI协议与HAL库配置细节2.1 SPI四线制与时序模式的选择SPI全称是Serial Peripheral Interface四根线SCK时钟、MOSI主输出从输入、MISO主输入从输出、CS片选低有效。它是全双工通信主设备发时钟的同时Master发一个字节的同时也能收一个字节。这个特性在下面读Flash的时候会用到HAL库对应的接口是HAL_SPI_TransmitReceive收发同时完成。SPI有两个关键参数时钟极性CPOL和时钟相位CPHA。CPOL决定空闲时SCK是高还是低CPHA决定数据在第一个还是第二个边沿采样。组合出来四种模式。W25Q16数据手册明确写了支持SPI Mode 0和Mode 3也就是CPOL0/CPHA0和CPOL1/CPHA1。实测中两种都能正常通信但网上绝大多数教程默认用Mode 0。我的建议是跟着用Mode 0省得后续和别人代码对比时还要纠结时序。判断SPI配置是否正确的标准方式不是看示波器而是发一条JEDEC读ID指令0x9F能返回0xEF 0x40 0x15就说明时序通了。2.2 CubeMX里的SPI配置要点在STM32CubeMX里配置SPI1这里以SPI1为例关键项如下ModeFull-Duplex MasterClock PolarityLowClock Phase1 EdgePrescaler根据主频算确保SCK不超过W25Q16支持的最大时钟W25Q16JV标称104MHz但STM32F103的SPI1最多跑到18MHz左右所以基本不构成瓶颈Data Size8 BitFirst BitMSB FirstNSSDisable这个特别重要关于NSS我专门说一下为什么很多教程都建议用软件片选。硬件NSS在HAL库里的行为比较迷容易在主从切换时产生意料之外的片选拉低而且多设备挂同一SPI总线时软件控制更灵活。CubeMX里把NSS设成Disable然后在代码里随便找个GPIO当CS用代码里手动拉低拉高这是最省心的方式。2.3 轮询、中断还是DMAHAL库API的选择HAL库给SPI提供了三套收发接口轮询HAL_SPI_Transmit、中断HAL_SPI_Transmit_IT、DMAHAL_SPI_Transmit_DMA。在W25Q16这种纯命令应答式的设备上我的建议是移植阶段用轮询逻辑简单出错好排查如果在RTOS环境里或者需要长时间连续读写数据比如往Flash里批量写固件用DMA配合信号量别用轮询阻塞任务还有一点想顺带提一下如果你对时序要求极苛刻可以考虑SPI用LL库LL库的收发是寄存器级操作比HAL少一层状态机判断吞吐量能高一些。但对W25Q16这种IO密集型外设来说瓶颈通常不在HAL库的CPU开销而是在Flash本身的擦写时间上。所以大部分场景HAL轮询就够用没必要一上来就折腾LL。2.4 用读ID验证通信链路CubeMX生成工程后先把SPI链路验证通了再往下走。读ID的代码很简单uint32_t W25Q16_ReadJEDEC_ID(void) { uint8_t tx[4] {0x9F, 0x00, 0x00, 0x00}; uint8_t rx[4] {0}; W25Q16_CS_Low(); HAL_SPI_TransmitReceive(hspi1, tx, rx, 4, 100); W25Q16_CS_High(); // W25Q16 期望返回0xEF 0x40 0x15 return (rx[1] 16) | (rx[2] 8) | rx[3]; }用调试器看返回值如果返回0xEF4015说明SPI时序、引脚连接、CS控制全部正常。如果读到0xFFFFFF或者0x000000优先检查MISO/MOSI是不是接反了、CS有没有正确拉低、SPI模式是不是选错了。这一步排查成本最低后面所有问题都是基于链路正常的前提。3. W25Q16驱动层指令集与HAL库实现要点3.1 必须掌握的五个Flash操作指令W25Q16数据手册指令很多但移植FATFS真正必须的只有五个指令码功能说明0x03Read Data从指定24位地址连续读数据0x06Write Enable擦写操作前必须发置位状态寄存器WEL位0x02Page Program向指定地址写入1~256字节0x05Read Status Register读状态寄存器bit0为BUSY0x20Sector Erase擦除4KB扇区抓住一个核心逻辑就全通了NOR Flash写入只能把1写成0要把0改回1必须先擦除。所以每次写之前要么目标地址本来就是0xFF没写过要么必须先擦除整个扇区。这是后面所有优化的出发点。3.2 状态寄存器与WaitBusyFlash执行擦除和编程需要时间页编程典型0.7ms扇区擦除典型150ms最大400ms。判断操作完成的方式是轮询状态寄存器0x05的bit0static void W25Q16_WaitBusy(void) { uint8_t tx[2] {0x05, 0x00}; uint8_t rx[2] {0}; uint32_t timeout 0xFFFFFF; do { W25Q16_CS_Low(); HAL_SPI_TransmitReceive(hspi1, tx, rx, 2, 100); W25Q16_CS_High(); } while ((rx[1] 0x01) --timeout); if (timeout 0) { // 处理超时这里根据项目需要加错误上报 } }这里有个细节值得注意发完0x05之后HAL的TransmitReceive第二个字节同时收回了状态值所以rx[1]才是状态寄存器的内容。很多新手容易把tx[0]当成rx的内容调半天发现busy标志永远不对。3.3 页编程的边界回卷坑W25Q16一次最多写256字节一个Page但还有一个坑很多人不知道如果写入长度跨越了页边界Flash内部地址会自动回卷到本页开头而不是自动换页。也就是说你往地址0x1F0写入40字节最后16字节不会写到0x220而是回到0x200覆盖你之前写的数据。这种错误非常隐蔽因为单次读取时数据好像对的只有对比尾部数据时才会发现丢了。解决方法是驱动层按页切分写入static void W25Q16_WriteData(uint32_t addr, const uint8_t *pData, uint32_t len) { while (len 0) { uint16_t page_remain 256 - (addr 0xFF); // 当前页剩余字节 uint16_t chunk (len page_remain) ? (uint16_t)len : page_remain; W25Q16_WriteEnable(); uint8_t hdr[4] {0x02, (uint8_t)(addr 16), (uint8_t)(addr 8), (uint8_t)addr}; W25Q16_CS_Low(); HAL_SPI_Transmit(hspi1, hdr, 4, 100); HAL_SPI_Transmit(hspi1, (uint8_t *)pData, chunk, 100); W25Q16_CS_High(); W25Q16_WaitBusy(); addr chunk; pData chunk; len - chunk; } }有这个函数之后往任意地址写任意长度都安全FATFS的那些512B级别的写入都会被这个函数安全拆分。3.4 擦除操作扇区擦除就够了W25Q16提供三种擦除粒度Sector Erase4KB、Block Erase64KB、Chip Erase整片。日常开发中90%的场景用扇区擦除就够了。void W25Q16_EraseSector(uint32_t addr) { uint8_t cmd[4] {0x20, (uint8_t)(addr 16), (uint8_t)(addr 8), (uint8_t)addr}; W25Q16_WriteEnable(); W25Q16_CS_Low(); HAL_SPI_Transmit(hspi1, cmd, 4, 100); W25Q16_CS_High(); W25Q16_WaitBusy(); }注意擦除地址必须4KB对齐。FATFS的disk_write里你可能会传入任意512B对齐的地址所以这一步的地址对齐逻辑要放在diskio层去处理后面会说。4. FATFS diskio移植512字节逻辑扇区与4KB物理块的映射4.1 先搞懂FATFS的扇区模型FATFS把存储介质抽象成一个一个的逻辑扇区Logical Block Address默认每个扇区512字节。对FATFS而言整个磁盘就是LBA 0到LBA N-1的线性地址空间它不关心底层介质物理上是怎么组织擦除的。而W25Q16呢物理上擦除单位是4KB扇区读/写单位是字节写受页限制。这中间就差出一个关键映射问题FATFS认为写LBA 100只影响LBA 100那512字节但底层Flash要写这512字节可能得先擦除整个4KB块。如果实现不当每次写512字节都擦4KB性能差不说寿命损耗直接放大8倍。W25Q16 2MB容量对应4096个512B逻辑扇区对应512个4KB物理块。映射关系是逻辑扇区sector对应的物理块号sector 3逻辑扇区在物理块内的偏移(sector 7) 9也就是低3位扇区号乘以512物理地址(sector 3) 12再加上块内偏移4.2 ffconf.h关键配置FATFS移植第一步是配置ffconf.h。针对W25Q16这个使用场景需要重点确认的配置项#define FF_USE_MKFS 1 // 允许格式化新Flash第一次挂载前必须格式化成文件系统 #define FF_USE_STRFUNC 0 // 默认关掉printf格式化写文件节省代码空间 #define FF_USE_LFN 1 // 支持长文件名默认1如果存中文文件名建议开 #define FF_MIN_SS 512 #define FF_MAX_SS 512 // 固定512字节逻辑扇区 #define FF_VOLUMES 1 // 只挂载一个卷4.3 四个diskio函数怎么实现FATFS通过diskio.c里的四个函数访问底层介质。这里给出一个能正确工作的最小实现重点看disk_write。disk_status和disk_initialize很简单固定返回正常DSTATUS disk_status(BYTE pdrv) { if (pdrv ! 0) return STA_NOINIT; return RES_OK; } DSTATUS disk_initialize(BYTE pdrv) { if (pdrv ! 0) return STA_NOINIT; return RES_OK; }disk_read实现相对简单因为读操作不需要先擦除W25Q16也支持连续跨页读取DRESULT disk_read(BYTE pdrv, BYTE *buff, LBA_t sector, UINT count) { if (pdrv ! 0) return RES_PARERR; W25Q16_ReadData((uint32_t)sector 9, buff, (uint32_t)count 9); return RES_OK; }disk_write是整个移植的核心直接决定了正确性和寿命。下面这段代码实现了一个按4KB物理块读改写的方案static uint8_t blk_cache[4096]; // 4KB缓存 DRESULT disk_write(BYTE pdrv, const BYTE *buff, LBA_t sector, UINT count) { if (pdrv ! 0) return RES_PARERR; while (count 0) { LBA_t cur_block sector 3; // 当前物理块号 uint32_t blk_addr (uint32_t)cur_block 12; // 物理块起始地址 uint32_t off (sector 7) 9; // 块内偏移字节 uint32_t remain 4096 - off; // 块内剩余字节 uint32_t chunk (uint32_t)count 9; // 本次要写的字节数 if (chunk remain) chunk remain; // 情况A整块写满4KB直接擦除写入 if (off 0 chunk 4096) { W25Q16_EraseSector(blk_addr); W25Q16_WriteData(blk_addr, buff, 4096); } // 情况B没写满读改写 else { W25Q16_ReadData(blk_addr, blk_cache, 4096); memcpy(blk_cache off, buff, chunk); W25Q16_EraseSector(blk_addr); W25Q16_WriteData(blk_addr, blk_cache, 4096); } sector (chunk 9); buff chunk; count - (chunk 9); } return RES_OK; }这段代码逻辑上分了情况A和情况B。情况A是理想情况FATFS恰好连续写了8个逻辑扇区我们把整个4KB块擦掉再写干净利落。但实际FATFS经常只写1~2个逻辑扇区比如更新一个目录项这时就得走情况B的读改写流程先把整个4KB块读到缓存在RAM里修改对应的512字节再擦除最后整块写回。这样虽然每次还是擦了一个4KB块但至少不会破坏块内其他扇区的数据。disk_ioctl提供容量和几何信息DRESULT disk_ioctl(BYTE pdrv, BYTE cmd, void *buff) { if (pdrv ! 0) return RES_PARERR; switch (cmd) { case CTRL_SYNC: return RES_OK; case GET_SECTOR_COUNT: *(LBA_t *)buff 4096; // 2MB / 512B 4096个逻辑扇区 break; case GET_SECTOR_SIZE: *(WORD *)buff 512; // 逻辑扇区大小 break; case GET_BLOCK_SIZE: *(DWORD *)buff 8; // 一个物理块包含8个逻辑扇区 break; default: return RES_PARERR; } return RES_OK; }GET_BLOCK_SIZE返回8这个值很重要FATFS格式化时会根据它尽量把簇对齐到4KB物理边界能显著减少跨块读改写后面优化里再展开说。4.4 第一次挂载和格式化的顺序问题新买的Flash默认全是0xFF没有文件系统直接f_mount会返回FR_NO_FILESYSTEM。正确流程是先格式化再挂载或者挂载失败后格式化FATFS fs; BYTE work[4096]; void Fatfs_Init(void) { FRESULT res f_mount(fs, , 1); if (res FR_NO_FILESYSTEM) { res f_mkfs(, FM_ANY, 0, work, sizeof(work)); if (res FR_OK) { f_mount(NULL, , 0); f_mount(fs, , 1); } } }注意f_mkfs需要一个4KB的工作缓冲至少FF_MAX_SS大小这个缓冲可以放全局数组或者malloc都行。格式化2MB的卷FATFS会自动选择FAT16或者FAT12不用管它。5. 扇区管理优化从能跑到抗用的四个关键手段5.1 先算一笔账为什么直接读改写会快速耗死FlashW25Q16标称10万次擦写寿命。假设你做一个数据采集设备每秒记录一条日志并调用f_sync确保数据落盘。每秒一次syncFATFS通常至少涉及两次写操作一次写文件数据区512B一次更新FAT表512B。在未优化的情况下这两次都会触发读改写也就是每秒擦除两个4KB物理块。一天有86400秒一天擦除约17万次。即使这些擦写均匀分散在8个物理块上每块每天也有约2.1万次擦写。按10万次寿命算不到5天FAT表所在的物理块就会达到寿命上限。而实际上FAT表更新通常集中在固定的几个块上寿命消耗比这个模型还要快。这就是标题里说的扇区管理优化方案的核心价值不是让Flash能用而是让它能用得久。5.2 手段一通过GET_BLOCK_SIZE对齐减少跨块写前面disk_ioctl里我返回了GET_BLOCK_SIZE8。这个值的作用是告诉FATFS底层最小的擦除块等于8个逻辑扇区。FATFS在f_mkfs格式化时会倾向于把簇大小设成8的整数倍让FAT表、根目录、数据簇都尽量落在4KB物理边界上。这样FATFS在写入一个簇时大概率命中完整的一个4KB物理块能走disk_write里的情况A整块擦写避免读改写。实际操作中你会发现格式化后簇大小自动变成了4KB或8KB这就是对齐生效了。如果你的代码里GET_BLOCK_SIZE返回1或者忘了实现格式化出来的文件系统很可能会出现一个簇跨两个物理块的情况写一次数据擦两个块寿命直接腰斩。5.3 手段二脏块缓存合并小写读改写能保证正确性但频繁小写还是会带来大量无谓擦除。一个更进一步的优化是在diskio层加一个脏块缓存把最近写入的几个物理块缓存在RAM里只有满足以下条件时才真正落盘缓存块被写满4KB直接擦除写入FATFS调用了CTRL_SYNC对应f_sync/f_close/f_unmount缓存块即将被换出LRU淘汰这个方案类似于操作系统的页缓存。对于日志型应用效果非常明显FATFS先写数据区512B再写FAT表512B如果这两个512B落在不同物理块脏块缓存不会立即擦写而是等数据积累到4KB或f_sync时统一落盘擦除次数可以降一个数量级。实现起来会增加一个块管理结构和LRU链表代码量不小。如果你的应用日志是周期性批量写的比如一分钟攒一批建议值得做。如果只是偶尔写几条数据读改写就够了。5.4 手段三应用层的磨损均衡思路如果你做过长周期运行的设备会发现即使上面都做了FAT表所在的物理块还是比数据区磨损快得多。FATFS本身没有磨损均衡机制这是它的设计缺陷。在W25Q16这种小容量Flash上一个务实的方案是在应用层做规避不要把FATFS卷铺满整个2MB留出备用区块日志文件按固定大小滚动写满一个日志文件后关闭写入下一个形成环形文件组定期通过f_unlink删除最老的日志文件这样做的意义在于文件数据通过FATFS的簇分配会散布到整个卷的不同物理块上不会长时间集中写同一块。以2MB卷为例日志区域有约512个物理块每块10万次寿命如果写入流量均匀分布整体寿命能达到约5000万次擦写级这对绝大多数嵌入式设备都够用了。实现上只需要在应用层维护日志文件编号逻辑char log_path[16]; snprintf(log_path, sizeof(log_path), log%03d.dat, file_index); // 写入到固定大小后关闭 // 当 file_index 到达上限时回绕到0删除旧文件5.5 手段四掉电保护SPI NOR Flash最怕的就是擦除过程中掉电。情况A里的流程是先擦后写如果擦除完、数据还没写回去就掉电这个物理块就变成一整个0xFF块内所有文件数据全完。FATFS对这类损坏没有恢复能力结果就是整个分区挂掉。对关键数据比如FAT表、根目录区可以在Flash尾部划一个备份块写入流程改成把旧块内容复制到备份块按原流程擦写目标块写入完成后更新备份区的有效版本号上电启动时检查目标块和备份块的有效版本号如果发现目标块擦写到一半版本号对不上就用备份块恢复。这个方案在嵌入式设备里叫双备份代码量不大但能显著提高可靠性。如果你做的是电池供电、随时可能掉电的设备这个优化比前面的磨损均衡还重要。6. 移植路上的真实坑三个典型故障与排查链路6.1 故障一f_mount返回FR_DISK_ERR现象挂载失败错误码为FR_DISK_ERR也就是1。排查过程FR_DISK_ERR来自diskio层返回的错误。顺着排查顺序走第一步确认disk_read正常。单独读LBA 0的前几个字节如果读出来全是0xFF说明Flash确实还没格式化但也说明读路径是通的。第二步确认disk_write正常。手动构造一个小测试向LBA 0写512字节再读回来对比。如果数据不一致基本是写路径的擦除逻辑有问题。最常见的是disk_write里直接调W25Q16_WriteData但没先擦除扇区。NOR Flash的特性决定了不擦除就往非0xFF区域写读出来的数据就是错乱的。第三步如果读写都正常还是FR_DISK_ERR检查disk_ioctl是否实现了GET_SECTOR_COUNT。FATFS第一次挂载时要读介质容量返回0或者没实现会导致FATFS内部直接判失败。6.2 故障二能挂载能写掉电后文件系统损坏现象写日志写入半天断电重启f_mount返回FR_NO_FILESYSTEM。这是很多人栽过的坑根因往往是f_sync不够及时。FATFS默认有写缓存f_write的数据先放在内存要等f_sync或者f_close才真正落到disk_write。如果设备在没落盘时断电丢的还只是几行日志但如果在disk_write的擦除后、写回前掉电整个物理块里的数据就没了。修改建议日志类应用每写几条就调一次f_sync关键文件写完立即f_close按照5.5节的方式给FAT表或整个卷做双备份我见过有些项目组为了性能把f_sync频率降到很低然后现场频繁掉电几个月内损坏率居高不下。做数据记录设备可靠性优先级应该高于写入性能。6.3 故障三擦写操作一直失败读ID正常现象SPI读ID正常但每次写数据或擦除后读回来还是0xFF好像根本写不进去。这种情况的排查要点是检查芯片的写保护位BP3、BP2、BP1、BP0和状态寄存器保护SRP。W25Q16的写保护状态存在状态寄存器里出厂时默认不保护但如果芯片之前被别的代码改过状态寄存器或者误操作过Block Protection就会出现能读不能写的诡异现象。检查方式uint8_t W25Q16_ReadSR(void) { uint8_t tx[2] {0x05, 0x00}; uint8_t rx[2] {0}; W25Q16_CS_Low(); HAL_SPI_TransmitReceive(hspi1, tx, rx, 2, 100); W25Q16_CS_High(); return rx[1]; }如果返回的bit7~bit2有非零值说明有块保护生效。解除保护需要先写使能再写状态寄存器清除保护位void W25Q16_DisableBlockProtect(void) { uint8_t cmd 0x01; uint8_t sr_val 0x00; W25Q16_WriteEnable(); W25Q16_CS_Low(); HAL_SPI_Transmit(hspi1, cmd, 1, 100); HAL_SPI_Transmit(hspi1, sr_val, 1, 100); W25Q16_CS_High(); W25Q16_WaitBusy(); }你可能会问项目里的Flash为什么会突然出现写保护大概率是代码里有代码路径意外写了状态寄存器或者芯片本身是拆机件/翻新件状态寄存器被人为设置过。这也是为什么我建议新板子贴片后先做一次读SR的操作确认芯片初始状态正常再开发上层功能。6.4 通用的排查手段最后分享一个排查手段保留一个裸Flash测试的调试入口绕开FATFS直接调W25Q16_ReadData和W25Q16_EraseSector。一旦FATFS层出问题可以随时用这个入口确认底层驱动是否正常。底层正常了问题就锁定在diskio映射或者FATFS层排查范围缩小一大半。我在实际项目里一直保留这个调试入口效果很好。根据我个人的实践经验这个W25Q16FATFS的项目最值得花时间的不是SPI配置也不是FATFS API而是disk_write那一层。你在这个函数里多花一天做读改写和优化设备在用户手里就能多活几年。移植完成后建议专门写一个压力测试程序循环写入、随机掉电、再上电校验数据完整性只要这个测试能连续跑几天不出问题这版移植才算真正合格。