1. 从一颗Flash芯片说起为什么我要重写W25QXX驱动手里攥着一颗W25Q64焊在板子上上电读ID返回一串乱七八糟的数据。换个批次同样的代码读出来又是另一个值。这种场景搞过嵌入式存储的同行应该都不陌生。W25QXX系列SPI Flash芯片从W25Q16到W25Q256甚至到W25Q512、W25Q01容量翻了几十倍但底层协议大体相通可偏偏各家厂商的参考代码、开源驱动、HAL库示例写法五花八门移植起来总得改上几刀。我最初接触W25Q系列是在一个数据采集项目里需要把传感器数据循环写入Flash掉电不丢上电续写。当时图省事直接拿了一份网上流传的驱动改改引脚定义就用了。结果批量生产时发现某些板子写入速度慢得离谱某些板子偶尔丢数据还有几块板子干脆识别不到芯片。排查了一圈问题出在驱动对芯片状态寄存器的轮询逻辑上——不同容量的W25QXX忙状态位的位置和超时特性有细微差别那份驱动只针对W25Q128做了优化换型号就露馅了。从那以后我决定自己写一套覆盖全系列的驱动。不是因为它有多难而是因为市面上的代码要么太碎片化要么太依赖特定平台要么对边界情况处理得不够细致。这套驱动我前后迭代了十几个版本在STM32、GD32、ESP32以及一些国产RISC-V平台上都跑过从W25Q16到W25Q256全系验证通过。今天把它拆开来讲不是要证明我写得多好而是想把里面踩过的坑、做过的取舍、以及那些数据手册上不会明说的细节一次性说清楚。这篇文章适合谁看如果你正在用SPI Flash做数据存储或者准备把W25QXX集成到自己的项目里又或者你手头有一份能跑但不太稳定的驱动想优化那接下来的内容应该能帮你省下不少调试时间。我会从芯片本身的特性讲起然后逐层拆解驱动的设计思路最后给出完整的代码框架和实测数据。不堆砌术语不照搬手册只说人话和实操。2. W25QXX全系列芯片的关键差异与共性梳理2.1 容量跨度带来的地址寻址变化W25QXX系列从W25Q162MB到W25Q01128MB容量跨度很大。容量不同最直接的影响就是地址位宽。W25Q16到W25Q128地址是24位3个字节就能覆盖。到了W25Q256及以上地址变成32位需要4个字节。这个变化不是简单地在命令后面多跟一个字节就完事它涉及到命令集的切换。W25Q256支持两种模式3字节地址模式和4字节地址模式。上电默认是3字节模式要访问超过16MB的空间必须发送进入4字节地址模式的命令0xB7或者使用专门的4字节地址命令比如0x13对应4字节页编程。很多驱动在这里翻车就是因为只处理了3字节地址结果W25Q256的前16MB能读写后面的空间一访问就出错。我的做法是在驱动初始化时读取芯片的JEDEC ID根据容量自动判断是否需要切换到4字节地址模式。对于W25Q256及以上的芯片统一进入4字节模式后续所有读写操作都按4字节地址处理。这样代码逻辑统一不用在每次读写时判断容量。2.2 页大小、扇区与块擦除的粒度W25QXX全系列的页大小都是256字节这一点没有例外。但擦除粒度有区别扇区擦除是4KB块擦除有32KB和64KB两种整片擦除命令全系列通用。写数据时如果跨页必须分多次写因为页编程命令不会自动翻页。比如你要从地址0x00F0开始写300字节前16字节写到第一页末尾剩下的284字节需要从下一页开头继续写。这个逻辑听起来简单但实际写代码时很容易忽略。我见过不少驱动直接调用页编程命令写任意长度结果数据在页边界处被覆盖。正确的做法是在写函数里做地址对齐判断把长数据拆分成多个页编程操作。拆分的逻辑不复杂但必须做而且要考虑写保护、忙等待等状态。擦除方面扇区擦除4KB是最常用的因为粒度细适合小数据更新。块擦除64KB速度快适合大块数据清理。整片擦除最慢一般只在出厂初始化或固件升级时用。我的驱动把三种擦除都封装成独立函数上层根据数据量选择。这里有个经验擦除前一定要确认目标区域没有重要数据因为Flash的擦除是不可逆的写错了只能整片擦。2.3 状态寄存器与忙判断的细节W25QXX有两个状态寄存器状态寄存器1和状态寄存器2。忙状态位BUSY在状态寄存器1的bit0写使能锁存位WEL在bit1。读状态寄存器用命令0x05读状态寄存器2用0x35。判断芯片是否忙就是读状态寄存器1检查bit0是否为1。这里有个坑不同容量的芯片忙状态的持续时间不同。W25Q16页编程典型时间0.7ms最大3msW25Q256页编程典型时间0.4ms最大3ms。扇区擦除典型时间45ms最大400ms。如果你用固定延时等待要么等太久浪费时间要么等太短导致操作失败。正确做法是轮询忙状态位直到它变0。但轮询也要加超时防止芯片异常时死循环。我的驱动里忙等待函数带一个超时参数默认给500ms足够覆盖所有擦除操作的最大时间。超时后返回错误码上层可以决定重试还是报错。这个设计在批量生产时特别有用能快速定位是芯片坏了还是时序问题。2.4 写使能与写保护的配合每次写操作页编程、擦除、写状态寄存器之前必须先发送写使能命令0x06把WEL位置1。操作完成后WEL位自动清零。如果忘记发写使能操作会被忽略而且不会报错数据静默丢失。这是新手最容易犯的错误之一。写保护方面W25QXX有硬件写保护和软件写保护。硬件写保护通过WP引脚控制软件写保护通过状态寄存器里的BP位和SRP位控制。我的驱动默认不启用软件写保护因为大多数应用场景不需要。但如果你的项目有数据安全需求可以在初始化时配置保护区域。注意一旦启用写保护擦除和编程操作会被拒绝必须先用写命令解除保护。3. 驱动架构设计分层与接口抽象3.1 硬件抽象层与平台解耦写驱动最忌讳的就是把硬件操作和业务逻辑混在一起。我的做法是分三层底层硬件抽象层HAL、中间命令层、上层应用接口层。HAL层只负责SPI收发、片选控制、延时函数这些函数用弱符号定义移植时只需要实现这几个函数不用动核心逻辑。具体来说HAL层需要实现五个函数SPI初始化、SPI单字节收发、片选拉低、片选拉高、毫秒级延时。这五个函数覆盖了所有硬件相关操作。在STM32上用HAL_SPI_TransmitReceive实现收发在ESP32上用spi_device_transmit在裸机平台上直接操作寄存器。不管什么平台只要把这五个函数填好驱动就能跑。这种分层的好处是同一套驱动代码可以在不同项目间复用换平台只需要改HAL层命令层和应用层完全不用动。我试过把同一份驱动从STM32F103移植到GD32E230只改了HAL层的五个函数十分钟搞定一次点亮。3.2 命令层的封装策略命令层是驱动的核心负责把W25QXX的命令集封装成可调用的函数。每个命令对应一个函数比如读ID、读状态、写使能、页编程、扇区擦除等。这些函数的参数和返回值要设计得清晰方便上层调用。我采用的结构体封装方式把芯片信息、状态、配置参数放在一个结构体里所有命令函数都接收这个结构体的指针。这样做的目的是支持多片Flash共存。比如你的系统里挂了两片W25Q128用同一个驱动只需要定义两个结构体实例分别初始化互不干扰。命令层里还有一个重要的设计是命令发送的原子性。SPI总线是共享资源如果多个任务同时访问Flash必须加锁。我的驱动在命令层不直接加锁而是把加锁的责任交给上层因为不同RTOS的锁机制不同。但我在文档里明确写了多任务环境下调用任何Flash操作函数前必须先获取SPI总线锁。3.3 上层接口的易用性设计上层接口面向应用开发者应该尽量简单直观。我提供了几个常用函数初始化、读数据、写数据、擦除扇区、擦除块、整片擦除。读数据函数支持任意地址和长度内部自动处理地址模式。写数据函数内部处理页对齐和忙等待上层只需要关心数据缓冲区和长度。这里有个设计取舍写数据函数要不要自动擦除我的选择是不自动擦除。因为擦除操作耗时较长而且有些场景下数据是追加写入的不需要擦除。如果自动擦除反而会降低效率。所以我的写函数只负责编程擦除由上层显式调用。但我在文档里给出了典型的使用流程先擦除目标扇区再写入数据。另外我提供了一个数据校验函数写入后可以回读比对确保数据正确。这个函数在调试阶段很有用量产时可以根据需要决定是否调用。4. 核心功能实现从读ID到数据读写4.1 初始化流程与ID识别初始化是驱动工作的第一步。我的初始化函数做以下几件事初始化SPI硬件、拉高片选、延时等待芯片上电稳定、读取JEDEC ID、根据ID判断芯片型号和容量、配置地址模式、读取状态寄存器确认芯片正常。读JEDEC ID用命令0x9F返回3个字节制造商ID、存储类型ID、容量ID。制造商ID通常是0xEF华邦存储类型ID是0x40容量ID从0x14到0x20对应不同容量。比如0x14是W25Q160x15是W25Q320x16是W25Q640x17是W25Q1280x18是W25Q256。通过容量ID驱动可以自动识别芯片型号并设置相应的地址模式。这里有个细节读ID之前必须先拉低片选发送命令然后读取数据最后拉高片选。片选的时序要符合芯片手册的要求拉低和拉高之间要有足够的延时。我见过一些驱动因为片选时序不对导致读ID偶尔失败。我的做法是在片选操作后加一个微秒级延时确保信号稳定。4.2 页编程的边界处理页编程是写数据的基本操作。W25QXX的页编程命令是0x023字节地址或0x124字节地址后面跟地址和数据。一次最多写256字节且不能跨页。如果写入的数据超过页边界必须拆分成多次页编程。我的实现逻辑是这样的先计算当前地址到页末尾的剩余空间如果剩余空间大于等于要写入的长度直接写否则先写满当前页然后地址跳到下一页开头继续写剩余数据。这个过程循环直到所有数据写完。每次页编程前都要发写使能命令写完后轮询忙状态。这里有个容易忽略的点页编程的地址必须是页对齐的吗不是。你可以从页内的任意地址开始写只要不跨页就行。比如从地址0x00F0开始写16字节写到0x00FF结束这是允许的。但如果从0x00F0开始写20字节就会跨到下一页必须拆分。4.3 扇区擦除与块擦除的取舍擦除操作是Flash写入的前置步骤。W25QXX的擦除命令有扇区擦除0x204KB、32KB块擦除0x52、64KB块擦除0xD8、整片擦除0xC7或0x60。我的驱动把扇区擦除和64KB块擦除封装成独立函数32KB块擦除用得少没有单独封装但保留了命令定义。选择哪种擦除方式取决于数据量和更新频率。如果只是更新几个字节的参数用扇区擦除最合适因为粒度细不影响其他数据。如果要清空一大片区域比如固件升级时擦除应用程序区用64KB块擦除效率更高。整片擦除只在极端情况下用比如恢复出厂设置。擦除操作的时间开销很大。扇区擦除典型45ms最大400ms64KB块擦除典型150ms最大2s整片擦除典型20s最大100s。所以擦除函数必须带超时机制而且上层调用时要考虑任务调度避免阻塞其他任务。我的做法是在擦除函数里轮询忙状态每次轮询之间让出CPU在RTOS环境下调用任务延时这样不会独占CPU。4.4 数据读取的连续性与效率读数据用命令0x033字节地址或0x134字节地址后面跟地址然后连续读取任意长度的数据。读操作没有页边界限制可以从任意地址开始读任意长度芯片内部会自动递增地址。这是Flash读操作的便利之处。我的读函数支持任意长度内部用一个循环分批读取。为什么要分批因为SPI收发缓冲区有限一次性读太多会占用大量内存。我通常设置一个256字节的缓冲区每次读256字节循环直到读完。这样内存占用小效率也不差。读操作的效率主要受SPI时钟频率影响。W25QXX支持最高104MHz的SPI时钟部分型号支持133MHz。在实际项目中我通常设置在40MHz到80MHz之间兼顾速度和信号完整性。如果PCB走线较长时钟频率要降低否则数据会出错。我遇到过一块板子SPI时钟设到80MHz时读数据偶尔出错降到40MHz就稳定了。后来检查发现是SPI走线没有做阻抗匹配加了端接电阻后问题解决。5. 实测中的坑与排查过程5.1 读ID正常但读写数据失败有一次我在一块新板子上调试W25Q128读ID正常返回0xEF4018说明芯片识别没问题。但写数据后回读发现数据全是0xFF好像没写进去。排查过程如下第一步确认写使能是否成功。读状态寄存器1发现WEL位是0说明写使能命令没有生效。检查代码发现写使能函数里片选拉低后没有延时直接发命令然后拉高片选。用逻辑分析仪抓波形发现片选拉低和命令发送之间的间隔太短芯片还没准备好。在片选拉低后加了一个1微秒的延时问题解决。第二步确认页编程是否执行。写使能正常后再写数据回读还是0xFF。读状态寄存器1发现BUSY位一直是1说明芯片一直处于忙状态。检查页编程命令发现地址发错了——我用的3字节地址模式但芯片被配置成了4字节地址模式。原因是之前测试时发过进入4字节模式的命令芯片掉电后没有复位。解决方法是每次初始化时都发送退出4字节模式的命令0xE9确保芯片回到默认状态。这个坑让我意识到Flash芯片的状态是掉电保持的初始化时必须显式复位到已知状态不能假设芯片上电后是默认状态。5.2 跨页写入导致的数据覆盖另一个典型问题是跨页写入。我在写一个数据日志时从地址0x0010开始写300字节结果发现从0x0100开始的数据被覆盖了。排查后发现页编程命令在跨页时不会自动翻页而是回绕到当前页的开头继续写。也就是说写到页末尾后地址指针回到页首覆盖了之前的数据。解决方法是拆分写入。我在写函数里加了页边界判断把300字节拆成两段第一段从0x0010到0x00FF共240字节第二段从0x0100到0x012B共60字节。两段分别调用页编程命令问题解决。这个坑的教训是永远不要假设页编程会自动处理跨页必须手动拆分。而且拆分逻辑要写对特别是当起始地址不是页对齐时计算要准确。5.3 擦除超时导致的系统卡死还有一次我在一个没有RTOS的裸机项目里调用扇区擦除结果系统卡死了。排查发现擦除函数里的忙等待循环没有超时机制芯片因为某种原因一直处于忙状态循环出不来。后来加了超时计数超过500ms就返回错误码系统恢复正常。这个坑让我明白任何轮询操作都必须有超时。Flash芯片虽然可靠但电源不稳、时序错误、芯片损坏等情况都可能导致忙状态不解除。超时机制是驱动健壮性的基本保障。5.4 SPI总线冲突导致的数据错乱在多任务环境下SPI总线是共享资源。我曾经在一个项目里Flash和显示屏共用SPI总线结果Flash读写时偶尔会干扰显示屏显示屏出现花屏。排查后发现两个任务的SPI操作没有互斥一个任务在发Flash命令时另一个任务插进来发了显示屏命令导致时序错乱。解决方法是在SPI操作外层加互斥锁。我的驱动不直接提供锁但在文档里明确要求多任务环境下调用Flash操作前必须获取SPI总线锁。上层可以用RTOS的信号量或互斥量实现。加锁后问题消失。6. 驱动代码框架与关键函数实现6.1 结构体定义与全局变量typedef struct { uint8_t manufacturer_id; uint8_t memory_type; uint8_t capacity_id; uint32_t capacity_bytes; uint8_t addr_mode; // 3 or 4 bytes uint32_t timeout_ms; } w25qxx_info_t; typedef struct { w25qxx_info_t info; void (*cs_low)(void); void (*cs_high)(void); uint8_t (*spi_transfer)(uint8_t data); void (*delay_ms)(uint32_t ms); } w25qxx_dev_t;这个结构体把芯片信息和硬件操作函数指针放在一起每个Flash实例一个结构体。初始化时填充函数指针后续所有操作都通过结构体调用。6.2 底层SPI收发与片选控制static uint8_t w25qxx_spi_transfer(w25qxx_dev_t *dev, uint8_t data) { return dev-spi_transfer(data); } static void w25qxx_cs_low(w25qxx_dev_t *dev) { dev-cs_low(); dev-delay_ms(0); // 实际用微秒延时 } static void w25qxx_cs_high(w25qxx_dev_t *dev) { dev-cs_high(); }片选控制看似简单但时序很重要。拉低后要等一小段时间再发命令拉高后也要等一小段时间再操作其他设备。我的做法是在片选函数里加微秒级延时具体延时时间根据芯片手册和实际测试确定。6.3 读状态与忙等待static uint8_t w25qxx_read_status(w25qxx_dev_t *dev, uint8_t reg) { uint8_t cmd (reg 1) ? 0x05 : 0x35; uint8_t status; w25qxx_cs_low(dev); w25qxx_spi_transfer(dev, cmd); status w25qxx_spi_transfer(dev, 0xFF); w25qxx_cs_high(dev); return status; } static int w25qxx_wait_busy(w25qxx_dev_t *dev, uint32_t timeout_ms) { uint32_t start get_tick_ms(); while (w25qxx_read_status(dev, 1) 0x01) { if (get_tick_ms() - start timeout_ms) { return -1; // timeout } dev-delay_ms(1); } return 0; }忙等待函数是驱动里调用最频繁的函数之一。每次页编程、擦除后都要调用。超时时间默认500ms可以通过结构体配置。在RTOS环境下delay_ms可以替换成任务延时让出CPU。6.4 页编程与数据写入int w25qxx_page_program(w25qxx_dev_t *dev, uint32_t addr, const uint8_t *data, uint16_t len) { if (len 0 || len 256) return -1; if ((addr 0xFF) len 256) return -1; // 跨页检查 w25qxx_write_enable(dev); w25qxx_cs_low(dev); if (dev-info.addr_mode 4) { w25qxx_spi_transfer(dev, 0x12); w25qxx_spi_transfer(dev, (addr 24) 0xFF); } else { w25qxx_spi_transfer(dev, 0x02); } w25qxx_spi_transfer(dev, (addr 16) 0xFF); w25qxx_spi_transfer(dev, (addr 8) 0xFF); w25qxx_spi_transfer(dev, addr 0xFF); for (uint16_t i 0; i len; i) { w25qxx_spi_transfer(dev, data[i]); } w25qxx_cs_high(dev); return w25qxx_wait_busy(dev, dev-info.timeout_ms); }这个函数只负责单页编程跨页由上层处理。上层写函数会计算页边界拆分数据循环调用这个函数。6.5 扇区擦除与块擦除int w25qxx_sector_erase(w25qxx_dev_t *dev, uint32_t addr) { w25qxx_write_enable(dev); w25qxx_cs_low(dev); if (dev-info.addr_mode 4) { w25qxx_spi_transfer(dev, 0x21); w25qxx_spi_transfer(dev, (addr 24) 0xFF); } else { w25qxx_spi_transfer(dev, 0x20); } w25qxx_spi_transfer(dev, (addr 16) 0xFF); w25qxx_spi_transfer(dev, (addr 8) 0xFF); w25qxx_spi_transfer(dev, addr 0xFF); w25qxx_cs_high(dev); return w25qxx_wait_busy(dev, dev-info.timeout_ms); }擦除函数和页编程类似只是命令不同且没有数据阶段。注意4字节地址模式下扇区擦除命令是0x21不是0x20。这个细节容易忽略导致4字节模式下擦除失败。7. 移植与适配的实操建议7.1 不同MCU平台的SPI配置要点移植驱动时SPI配置是关键。以STM32为例SPI需要配置为全双工主模式时钟极性CPOL和相位CPHA根据芯片手册设置。W25QXX支持模式0CPOL0CPHA0和模式3CPOL1CPHA1。我通常用模式0因为大多数MCU的SPI默认支持。时钟频率方面初始化时先用低速比如1MHz确保通信正常然后再切换到高速。有些MCU的SPI时钟分频器设置不当会导致实际时钟频率与预期不符。我习惯用示波器或逻辑分析仪确认SPI时钟频率确保在芯片支持范围内。片选引脚可以用硬件SPI的NSS也可以用普通GPIO。我倾向于用普通GPIO因为控制更灵活不受SPI外设状态影响。片选拉低和拉高之间要有足够的延时具体时间参考芯片手册的时序图。7.2 电源与PCB布局的注意事项Flash芯片对电源噪声比较敏感。如果电源纹波大读写操作可能出错。我在PCB布局时会在Flash的电源引脚旁边放一个0.1uF的陶瓷电容有时候还会加一个1uF的钽电容。SPI走线尽量短避免与其他高速信号平行走线。如果Flash和MCU距离较远SPI走线要考虑阻抗匹配。我遇到过一块板子SPI走线长度超过10cm时钟频率设到40MHz时数据出错。后来在SPI线上串了22欧姆的电阻问题解决。这个电阻的作用是抑制信号反射改善信号完整性。7.3 多片Flash共存的片选管理有些项目需要挂多片Flash比如一片存数据一片存固件。多片Flash共用SPI总线片选分别控制。我的驱动支持多实例每个实例有自己的片选函数。初始化时分别读ID确认每片芯片正常。多片共存时要注意片选不能同时拉低。如果两个片选同时有效两片Flash会同时驱动MISO线导致数据冲突。我的做法是在片选函数里加互斥逻辑确保同一时间只有一个片选有效。在RTOS环境下用互斥量保护片选操作。7.4 低功耗场景下的驱动调整在电池供电的设备里Flash的功耗需要考虑。W25QXX在待机模式下电流只有几微安但在读写和擦除时电流较大。如果设备大部分时间处于休眠状态可以在休眠前把Flash置于深度掉电模式命令0xB9唤醒后发释放命令0xAB。深度掉电模式下Flash不响应任何命令除了释放命令。这个模式可以显著降低功耗。我的驱动提供了进入和退出深度掉电的函数上层可以根据需要调用。注意进入深度掉电前要确保所有写操作完成否则数据可能丢失。8. 性能实测与优化经验8.1 不同SPI时钟下的读写速度对比我在STM32F407平台上用W25Q128做了读写速度测试。SPI时钟分别设为10MHz、20MHz、40MHz、80MHz测试连续读写1MB数据的时间。结果如下SPI时钟读1MB耗时写1MB耗时含擦除10MHz820ms3.2s20MHz410ms2.8s40MHz205ms2.5s80MHz103ms2.3s读速度基本与时钟频率成正比写速度受擦除时间限制提升不明显。因为擦除操作的时间是固定的不受SPI时钟影响。所以优化写速度的关键是减少擦除次数比如用扇区擦除代替整片擦除或者用缓存机制批量写入。8.2 擦除策略对写入效率的影响擦除是Flash写入的瓶颈。如果每次写几个字节都擦除一个扇区效率极低。我的做法是在RAM里维护一个扇区缓存数据先写到缓存缓存满了再一次性擦除和写入。这样可以把多次小写入合并成一次大写入减少擦除次数。另一种策略是使用日志式写入。数据追加写到空闲区域不擦除旧数据只在空间不足时整理。这种策略适合数据采集场景写入效率高但需要额外的空间管理逻辑。我的驱动不直接提供日志功能但提供了底层接口上层可以基于这些接口实现。8.3 数据校验与错误恢复机制Flash芯片虽然可靠但长期使用后可能出现坏块。我的驱动在写入后提供回读校验函数比对写入数据和读出数据。如果发现不一致可以重试写入或标记坏块。对于关键数据我建议使用双备份机制。比如参数存储写两份到不同扇区读取时比对两份数据如果一份损坏用另一份恢复。这种机制增加了空间开销但提高了可靠性。我的驱动支持多扇区操作上层可以方便地实现双备份。8.4 与文件系统结合的注意事项有些项目需要在Flash上跑文件系统比如FatFS、LittleFS。这些文件系统对底层驱动的要求是读、写、擦除接口稳定扇区大小匹配。W25QXX的扇区是4KB正好匹配大多数文件系统的块大小。结合文件系统时要注意擦除操作的耗时。文件系统可能会频繁擦除导致性能下降。我的建议是在文件系统层加缓存减少擦除次数。另外文件系统的磨损均衡算法要考虑Flash的擦除寿命。W25QXX的擦除寿命是10万次如果频繁擦除同一扇区寿命会很快耗尽。LittleFS自带磨损均衡适合在W25QXX上使用。9. 写在最后一些个人体会这套驱动我用了好几年从W25Q16到W25Q256都验证过也在多个平台上移植过。最大的体会是Flash驱动不难写但写好很难。难的不是命令集的实现而是对边界情况的处理、对时序的把握、对异常情况的容错。我见过很多项目Flash驱动能跑但批量生产时问题频出。有的是因为芯片批次不同时序特性有差异有的是因为PCB布局不好信号完整性差有的是因为代码没有超时机制偶尔卡死。这些问题在实验室里可能复现不了但在现场就会暴露。所以我的建议是驱动写完后一定要做压力测试。连续读写擦除几万次看看有没有出错。在不同温度下测试看看时序是否需要调整。在电源波动的情况下测试看看芯片是否稳定。这些测试花时间但能帮你避免量产后的噩梦。另外不要迷信网上的开源驱动。很多驱动只针对特定型号优化换型号就出问题。理解芯片手册自己写一遍比拿来主义靠谱得多。我写这套驱动的过程也是重新学习SPI Flash协议的过程收获很大。最后分享一个小技巧在调试Flash驱动时用逻辑分析仪抓SPI波形比用printf打印有用得多。波形能直观地看到片选、时钟、数据的时序关系一眼就能看出问题所在。我调试跨页写入问题时就是靠逻辑分析仪抓到了地址回绕的波形才快速定位到问题。