前阵子帮一个客户调板子他们用的就是 Winbond 这颗 W25N01GV SPI NAND Flash。本来以为不就是一颗 SPI Flash 嘛照着 W25Q 系列的老套路写驱动就行了结果数据写进去再读出来全是 0xFF折腾了两天才发现这芯片骨子里是颗 NAND不是带 SPI 接口的 NOR。这个项目之后我把 W25N01GV 的驱动完整整理了一遍也总结了不少跟 2KB 缓冲区机制、状态寄存器相关的坑。今天把这颗芯片驱动开发的关键点全部摊开讲尤其是标题里这两个核心2KB 缓冲区机制和状态寄存器用法搞懂它们你基本就不会再在 W25N01GV 上浪费调试时间了。这篇文章适合正在做嵌入式 Linux 驱动、RTOS 裸机驱动或者只是想在新项目里评估 SPI NAND 方案的朋友。不管你是要把文件系统跑在 SPI NAND 上还是只用它当大容量数据存储下面这些原理和代码流程都能直接抄作业而且我会把为什么这么做也讲清楚。1. 先认清这颗芯片SPI 接口的 NAND不是带 SPI 的 NOR1.1 引脚兼容协议不兼容W25N01GV 单看封装和引脚跟常见的 W25Q128 SPI NOR Flash 几乎一模一样SOIC-8 封装CS、CLK、DI、DO 四个信号硬件上完全可以替换。但你要是以为软件也能直接平移那就踩坑了。SPI NOR 的 0x03 命令可以直接按字节地址线性读SPI NAND 不行。NAND 的存储结构是“页Page”和“块Block”数据不能直接按字节访问必须先发命令让芯片把某一页的数据搬进内部缓冲区再到缓冲区里读数据。这个问题刚开始调试的时候极具迷惑性。因为读 ID 命令是通用的 0x9F硬件上能正常返回 Winbond 的 Manuf. ID 0xEF很多人就会觉得“芯片是好的SPI 通信也通”然后一头扎进读写数据调试。实际上从这个时候开始你就应该意识到这已经不是一个 NOR 型 Flash 的驱动思路了你要按照 NAND 的访问模型重新组织代码。1.2 2KB 缓冲区到底是什么标题里说的 2KB 缓冲区机制是 W25N01GV 和普通 SPI NOR 最大的区别。这颗 1Gbit 芯片的页大小是 2048 字节外部还有额外的 64 字节 Spare/OOB 区域所以芯片内部有一片静态随机存储器SRAM用来做“阵列Memory Array到外部接口”的中转。你写入数据的时候是先把数据通过 SPI 接口存进这个 SRAM 缓冲区然后再发一条“Program Execute”命令芯片才会把缓冲区里的数据搬到 NAND 阵列里。这个过程可以类比成仓库出货仓库里货架密密麻麻不方便直接一件一件往外拿所以仓库门口有个装卸平台。你要从仓库取货先让工人把整托货搬到装卸平台再从平台搬上车。平台就是那个 2KB 缓冲区工人搬货的指令就是 READ 命令从平台搬上车就是 READ DATA 命令。搞懂这个类比很多 SPI NAND 的命令流程就顺了。这个缓冲区机制带来两个直接后果第一页编程必须按“写缓冲区 Program Execute”两步走不能像 NOR 那样直接发地址和数据第二读数据必须按“READ 搬运 READ DATA 读取”两步走不能指望一条命令把页里的数据流式读出来。所谓“2KB 缓冲区机制”本质上就是这一套搬运逻辑。1.3 读出 ID 之后还要确认变体W25N01GV 后面那个后缀比如 ZEIG、SEIG影响的是封装和温度等级但 Device ID 可能不同。我用过的 W25N01GVZEIG 读回来是 EF AA 21但有的批次可能是 EF AB 21不一定是芯片有问题也可能是变体差异。建议在驱动里把 Device ID 也列入匹配条件并且在上电初始化的时候把 ID 打印出来留档万一后续换批次也能快速定位是驱动不兼容还是芯片供货变化。2. 状态寄存器这么读才对GET FEATURES 不是 0x052.1 两个状态寄存器别只看一个很多从 SPI NOR 转过来的人习惯用 0x05 命令读状态寄存器。W25N01GV 这里就不一样了它的状态寄存器是通过 GET FEATURES0x0F命令读取的后面要跟一个 Feature 地址0xC0 对应状态寄存器 10xC1 对应状态寄存器 2。同理写状态寄存器要用 SET FEATURES0x1F命令不是 NOR 里面常见的 0x01 写状态命令。我第一次调的时候就是拿着 NOR 的驱动框架去看寄存器读到 0xC0 地址的位定义全是乱码整个人都懵了。后来翻了手册才发现读状态函数的封装全要改。下面这段代码是我实际在用的读状态接口static int w25n01_read_status(struct spi_device *spi, u8 feat, u8 *status) { u8 tx[2] {0x0f, feat}; /* GET FEATURES Feature Address */ u8 rx[1]; int ret; ret spi_write_then_read(spi, tx, 2, rx, 1); if (ret 0) return ret; *status rx[0]; return 0; }状态寄存器 1 的关键位是 OIPbit0、WELbit1、E_FAILbit2、P_FAILbit3。OIP 是 Operation In Progress表示当前有没有操作在执行轮询这个位是关键。WEL 是写使能锁存位很多命令执行完后 WEL 会自动清掉所以每次写操作前都要重新发 0x06 写使能。E_FAIL 和 P_FAIL 分别是擦除失败和编程失败标志如果操作失败会置 1。状态寄存器 2 中值得关注的是 ECC 状态位一般在 bit4 和 bit5这个我们后面会详细讲。2.2 OIP 轮询的正确姿势判断芯片忙不忙正确姿势是发 0x0F 0xC0然后看返回字节的 bit0。如果 bit0 是 1说明芯片还在忙要继续等如果是 0说明操作完成了。下面这个轮询函数我加了超时保护避免芯片异常时死循环static int w25n01_wait_ready(struct spi_device *spi, int timeout_ms) { u8 tx[2] {0x0f, 0xc0}; u8 rx[1]; unsigned long deadline jiffies msecs_to_jiffies(timeout_ms); do { int ret spi_write_then_read(spi, tx, 2, rx, 1); if (ret 0) return ret; if (!(rx[0] 0x01)) return 0; udelay(50); } while (time_before(jiffies, deadline)); return -ETIMEDOUT; }这里要特别提醒一下不要在轮询之前随便加固定延时比如死等 1 毫秒再判断 OIP。页编程时间在不同温度、不同电压、芯片生命周期不同阶段差别很大标称典型值 700 微秒但老化和低温环境下可能拉到几毫秒。固定延时要么把整体性能拖慢要么等得不够导致误判超时。轮询 OIP 才是标准做法既快又稳。2.3 WEL、P_FAIL、E_FAIL 怎么组合判断完整的编程流程里先发 0x06 写使能然后写数据最后发 Program Execute执行完轮询 OIP。等 OIP 变成 0 之后千万别急着返回成功还要再看一下状态寄存器 1 的 P_FAIL 位。如果 P_FAIL 是 1说明编程失败返回错误码让上层做坏块处理。我见过不少驱动只轮询 OIPP_FAIL 从来不看结果坏块写入静默失败后续读取随机出错非常难排查。WEL 位也有讲究。操作执行完后 WEL 会被清掉如果调试时发现某条命令没生效先读一下 WEL要是 WEL 是 0说明之前根本没有成功写使能。这种情况常见于两条命令之间 CS 片选异常、SPI 时钟极性错误或者主控 SPI 控制器在连续传输间插入了多余字节。擦除命令也一样D8h 执行完之后判断 E_FAIL不能只看 OIP。2.4 ECC 状态到底在哪里W25N01GV 本身不提供完整的硬件 ECC 纠错但它会在读操作的时候告诉你从 NAND 阵列搬进缓冲区之后这一页数据有没有检测到比特错误。这个信息就在状态寄存器 2 里。我用的读取方法是u8 sr2 0; w25n01_read_status(spi, 0xc1, sr2); int ecc_status (sr2 4) 0x03;ECC 状态位组合的具体含义以你手里那颗芯片的最新数据手册为准不同批次或衍生型号可能有细节差异。但大致规律是00 表示没有检测到错误非 00 表示读取过程中发现了可纠正的比特翻转数值越大通常代表错误越严重。我实际项目里的策略是ECC 状态非 0 就把这个页标记为“有风险”如果频繁出现说明这个块接近寿命极限要做数据搬移。3. 页编程流程拆解2KB 缓冲区填不对写进去等于白写3.1 完整写页步骤我把 W25N01GV 的页编程拆成四步驱动里每一步都有明确对应的命令。以写入完整的 2048 字节为例第一步发 0x06 写使能命令。不加这一步后面的 Program Execute 不会生效。第二步发 0x02 Load Program Data 命令后面跟上列地址、行地址以及 2048 字节的数据。这个命令的作用就是把数据填进内部缓冲区此时数据还没有真正进入 NAND 阵列。第三步发 0x10 Program Execute 命令后面跟行地址。芯片收到这条命令后才会把缓冲区里的数据写入指定页。第四步轮询 OIP然后检查 P_FAIL。对应代码如下这个是基于 Linux SPI 设备驱动接口的写法static int w25n01_write_page(struct spi_device *spi, int page, const unsigned char *data, size_t len) { u8 cmd; u8 addr[4]; u8 status 0; int ret; cmd 0x06; /* Write Enable */ ret spi_write(spi, cmd, 1); if (ret 0) return ret; cmd 0x02; /* Load Program Data */ addr[0] 0x00; /* 列地址高 8 位 */ addr[1] 0x00; /* 列地址低 8 位 */ addr[2] (page 8) 0xff; /* 行地址高 8 位 */ addr[3] page 0xff; /* 行地址低 8 位 */ spi_write(spi, cmd, 1); spi_write(spi, addr, 4); spi_write(spi, data, len); cmd 0x10; /* Program Execute */ spi_write(spi, cmd, 1); spi_write(spi, addr[2], 2); /* 只需要行地址 */ ret w25n01_wait_ready(spi, 2000); if (ret 0) return ret; w25n01_read_status(spi, 0xc0, status); if (status 0x08) { dev_err(spi-dev, page %d program fail\n, page); return -EIO; } return 0; }注意上面代码的第 23 行我只发了行地址 2 个字节。W25N01GV 是 1Gbit 容量页数量是 6553616 位行地址足够用。如果你手头换成了 2Gbit、4Gbit 的 SPI NAND行地址有效位会变宽需要往 3 字节甚至更多字节扩展否则高地址页会读写错乱。3.2 列地址与行地址的分工SPI NAND 里有两个地址概念列地址是页内偏移行地址是页号。我用 4 字节地址缓冲来模拟这个过程前两字节是列地址后两字节是行地址。写入时列地址为 0表示从缓冲区起始位置开始填数据。不少第一次写驱动的人在这里会犯一个隐蔽错误把页号乘上页大小当成线性地址再把结果当成行地址发出去。W25N01GV 的行地址就是页号本身不是字节地址。比如要操作第 100 页行地址直接发 100也就是 0x00 0x64不是发 100 * 2048 204800。你把 204800 分成两字节发出去芯片实际读到的页号是 0x2000 之类的错误值写出去的数据不知道跑到哪个页去了。所以我在代码里特意把列地址和行地址写在两个变量里逻辑上分开调试起来也直观。如果你想在页的中间偏移开始写数据比如从偏移 512 字节开始写列地址就改成 0x02 0x00而不是把偏移量加到行地址里。3.3 只改一两个字节怎么办NAND 的特性决定了页编程本质上是对缓冲区的一次覆盖式写入。如果你只想改页内某个字节不能像 NOR 那样直接写一个字节必须先把整页读出来到缓冲区在缓冲区里修改目标字节再执行 Program Execute 把整页写回去。这就是所谓的读-改-写Read-Modify-Write操作。我之前犯过懒尝试只往页内偏移写一小段数据效果是一开始看起来没问题多写几次之后数据就出现随机损坏。原因是 NAND 部分页编程虽然硬件上允许但对同一个物理位置重复编程有次数限制而且容易干扰相邻存储单元。所以标准做法就是整页读写宁可多搬 2048 字节也别偷那点小动作。如果追求性能可以把读-改-写过程拆成两步先用 0x13 READ 命令把目标页搬到缓冲区再用 0x02 LOAD PROGRAM DATA 命令往缓冲区指定偏移写新数据最后 0x10 Program Execute。这样的好处是少了一遍完整的读数据流程数据不用经过主控内存往返速度会快不少。3.4 擦除整块时的地址计算块擦除命令是 0xD8后面跟块地址Block Address。W25N01GV 每块是 64 页所以页号除以 64 得到块号然后把这个块号作为地址发出去不是发这个块里某一页的页号。实际操作中我就是这么算的static int w25n01_erase_block(struct spi_device *spi, int block) { u8 cmd 0x06; /* Write Enable */ u8 addr[3]; u8 status 0; int ret; ret spi_write(spi, cmd, 1); if (ret 0) return ret; addr[0] (block 8) 0xff; addr[1] block 0xff; addr[2] 0x00; cmd 0xd8; /* Block Erase */ spi_write(spi, cmd, 1); spi_write(spi, addr, 3); ret w25n01_wait_ready(spi, 4000); if (ret 0) return ret; w25n01_read_status(spi, 0xc0, status); if (status 0x04) { dev_err(spi-dev, block %d erase fail\n, block); return -EIO; } return 0; }擦除操作比页编程耗时更长典型值可能到 3 到 4 毫秒超时时间我习惯给到 4 秒以上。因为擦除是对整个块操作的某个环节出问题恢复代价大超时判断宁可宽松一些。4. 页读取流程与缓冲区回读4.1 READ 加 READ DATA 两步走读数据流程和写数据是镜像的。第一步发 0x13 READ 命令和行地址芯片把对应页从 NAND 阵列搬到内部缓冲区。第二步轮询 OIP 确认搬运完成。第三步发 0x03 READ DATA 命令和列地址从缓冲区把数据读出来。对应的读整页代码static int w25n01_read_page(struct spi_device *spi, int page, unsigned char *data, size_t len) { u8 cmd; u8 addr[4]; int ret; cmd 0x13; /* Read */ addr[0] 0x00; addr[1] 0x00; addr[2] (page 8) 0xff; addr[3] page 0xff; spi_write(spi, cmd, 1); spi_write(spi, addr, 4); ret w25n01_wait_ready(spi, 2000); if (ret 0) return ret; cmd 0x03; /* Read Data */ spi_write(spi, cmd, 1); spi_write(spi, addr, 2); /* 列地址 */ spi_read(spi, data, len); return 0; }这里读出来的数据长度可以小于 2048比如只想读页内偏移 100 字节开始的 64 字节那么发 0x03 命令时列地址填 100然后只读 64 字节即可。芯片会从缓冲区的 100 字节位置开始连续输出没有“必须读整页”的限制。但注意每次 0x13 READ 命令之后缓冲区里的数据就是这个页的“快照”你再想读同一页的另一个区域需要重新发 0x13 吗不需要只要不执行新的 READ 命令缓冲区数据不变直接发 0x03 改列地址就行。这个特性在做随机读的时候可以省一次搬运。4.2 跨缓冲区的连续读和 Cache ReadSPI NAND 的 0x03 读缓冲区命令支持连续读也就是说如果在列地址 2000 处开始读芯片会一路读下去越过 2048 字节边界后继续读下一列对于 W25N01GV 这种单缓冲区结构连续读一般是限定在缓冲区内的读到头之后继续读是未定义行为不能依赖。要读下一页必须重新发 0x13。W25N01GV 还支持 Cache Read 这类带预取特性的命令可以在读当前缓冲区的过程中提前把下一页搬到缓冲区从而提高连续读吞吐。性能优化时可以研究但先不要碰。原因是 Cache Read 的状态机更复杂需要处理“芯片什么时候开始预取”“上一页有没有读完”这类问题在驱动稳定之前引入它只会增加排查难度。我的做法是先把最简单的 0x13 0x03 流程跑通再考虑优化。4.3 OOB 和 Spare 区域的读写除了 2048 字节主数据区每页还有 64 字节的额外区域在 Winbond 的文档里叫 Spare Area行业里习惯叫 OOBOut-Of-Band。这个区域不是拿来做普通数据存的一般用来放坏块标记、ECC 校验值、文件系统元数据。访问 spare 区域的方式和读写主数据区类似区别在于列地址要从 2048 开始算也就是 0x0800。列地址总共 12 位有效因为 2048 64所以 spare 第一个字节的位置是列地址 0x0800。下面这段代码是从某页 spare 区读 16 字节的示例static int w25n01_read_oob(struct spi_device *spi, int page, unsigned char *oob, size_t len) { u8 cmd; u8 addr[4]; int ret; cmd 0x13; /* Read */ addr[0] 0x00; addr[1] 0x00; addr[2] (page 8) 0xff; addr[3] page 0xff; spi_write(spi, cmd, 1); spi_write(spi, addr, 4); ret w25n01_wait_ready(spi, 2000); if (ret 0) return ret; cmd 0x03; /* Read Data */ addr[0] 0x08; /* 2084 0x0820? 不对应该是 2048 0x0800 */ addr[1] 0x00; spi_write(spi, cmd, 1); spi_write(spi, addr, 2); spi_read(spi, oob, len); return 0; }注意列地址 2048 换算成 16 进制是 0x0800高字节是 0x08低字节是 0x00。我见过有人写成 0x20 0x00把十进制和十六进制搞混了读出来的是主数据区后面的位置完全不对。这里再次提醒列地址是页内偏移地址计算一定要先明确单位。5. 坏块管理和 ECC能不能稳定运行就看这章5.1 出厂坏块标记在哪NAND 的特点是出厂就可能有坏块而且使用过程中还会出现新的坏块。W25N01GV 每块Block的第一个页的 spare 区域第一个字节出厂时如果被写成非 0xFF就表示这个块是坏块。不同厂商定义可能不同Winbond 一般是检查 page 0 的 spare 第 1 字节即 OOB offset 0。驱动的初始化流程里我建议启动时对整颗芯片做一次坏块扫描遍历所有块读每一块第一个页的 OOB 第一字节如果非 0xFF就标记到内存里的坏块表中。这个扫描过程在 1Gbit 芯片上1024 个块每块读一次大概几百毫秒可以接受。如果你为了节省启动时间不做全盘扫描至少要在第一次访问某个块之前检查它的标记。坏块表我推荐用位图1024 个块用 128 字节就能存下每次访问前查一下对应 bit。Linux 内核自带的 MTD 系统本来就有 Bad Block TableBBT机制裸机驱动就得自己维护这个位图。5.2 ECC 状态位不是帮你纠错这里要特别说清楚一个常见误解W25N01GV 的 ECC 状态位不等于芯片内置了完整的 ECC 检错纠错引擎。它提供的信息更接近“提醒”——芯片在搬运数据时检测到了某些比特位异常然后通过状态寄存器告诉你“这页数据有问题”。但它并不会把这页数据修正为原始正确内容。所以你仍然需要外部 ECC 方案。我的项目用的是主控自带的硬件 ECC 引擎每页 2048 字节生成若干字节的 BCH 校验码写入 OOB 区域读取时把主数据和 OOB 里的校验码一并交给 ECC 引擎验证发现不可纠正错误就标记坏块。如果你的主控没有硬件 ECC软件 ECC 也能用但 CPU 占用会比较高吞吐率上不去了。5.3 简单坏块处理策略我的策略分三层。第一层严禁写入坏块表里标记的块这是底线。第二层每次写页之后检查 P_FAIL如果失败立刻把这个块加入坏块表并从保留块区找一个好块替代数据。第三层每次读页之后看 ECC 状态如果频繁报错主动把整块数据搬走然后标记坏块。代码实现上不复杂static int w25n01_is_bad_block(struct w25n01_chip *chip, int block) { if (block chip-num_blocks) return 1; return (chip-bbt[block / 8] (block % 8)) 0x01; } static void w25n01_mark_bad_block(struct w25n01_chip *chip, int block) { chip-bbt[block / 8] | (1 (block % 8)); }注意标记坏块之后最好也把这个标记写回芯片本身也就是写坏块标记到页的 OOB 区域。虽然内存表够用但掉电重启后内存表就没了扫描代价高。出厂时芯片自带坏块标记新产生的坏块我们自己也要落盘不然每次启动都重复发现同一个坏块。6. 在 Linux 里适配 W25N01GV 的实操6.1 SPI 设备树节点怎么配如果你的项目跑 Linux而且内核版本比较新通常内核里的 spi-nand 子系统已经支持 Winbond 的 W25N01GV你只需要在设备树里把它描述清楚。常见配置如下spi0 { status okay; cs-gpios gpio1 0 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 spi0_pins; flash0 { compatible w25n01gv, spi-nand; reg 0; spi-max-frequency 50000000; spi-rx-bus-width 1; spi-tx-bus-width 1; #address-cells 1; #size-cells 1; partition0 { label uboot; reg 0x000000 0x100000; }; partition1 { label rootfs; reg 0x100000 0x7F00000; }; }; };这里关键点是 compatible 既有具体型号 w25n01gv也有通用 spi-nand。如果你的板子上的 Flash 内部 ID 匹配常见 Winbond ID驱动会自动 probe如果内核不识别就大概率是 ID 匹配表里没有你这个后缀的 Device ID需要你手动补充或者用 spi-nand 兜底。另外 spi-max-frequency 不要一次拉太高。W25N01GV 虽然理论上支持 50MHz 甚至更高但实际板级信号质量、线长、上拉电阻都会影响稳定性。我习惯先保守工作在 30MHz验证读写稳定后再慢慢往上调。6.2 内核识别不了怎么办如果设备树配好之后启动日志里根本没有 spi-nand 相关的 probe 信息第一步是确认 SPI 控制器有没有正常枚举设备。在 /sys/bus/spi/devices/ 下面看有没有对应节点如果没有通常是设备树 compatible 和 reg 没写对或者片选 GPIO 配置有问题。第二步把内核 spi-nand 驱动的调试打开看它有没有去读 ID。如果 ID 读到了但还是 probe 失败十有八九是 nanddev 初始化时校验 OOB size、page size 等参数不匹配。这个时候先检查你手里这颗芯片的具体参数比如有些批次 OOB 可能是 64 字节有些是 128 字节万一驱动按错误参数初始化后续读 OOB 全是错位。第三步如果内核版本太旧比如 4.x 早期内核的 spi-nand 子系统还不成熟可以考虑直接升级内核或者把厂商提供的 out-of-tree 驱动移植进来。我建议能升内核就升内核尽量别长期维护一个独有驱动。6.3 UBIFS 文件系统与系统裁剪建议SPI NAND 非常适合挂 UBI/UBIFS因为它考虑了 NAND 的坏块和掉电问题。设备树里如果分了多个 partitionU-Boot 的 mtdparts 参数也要同步。启动参数里 root 指定为 ubi0:rootfs例如setenv bootargs consolettyS0,115200 ubi.mtd1 rootubi0:rootfs rootfstypeubifs系统裁剪方面SPI NAND 不支持 XIPExecute In Place所以代码必须从 Flash 读入 RAM 再执行。如果你的内核镜像比较大要注意 DDR 空间占用。去掉不需要的 MTD 分区和文件系统模块能显著提升启动速度。实测下来同一颗 W25N01GV裁剪前后 rootfs 挂载时间能差出不少主要差在 UBI 扫描的卷数量和内核模块加载量。裁剪时优先去掉不用的 MTD 工具、所有 SPI NOR 驱动模块以及调试用的 misc 设备。7. 我实测遇到的坑和排查思路7.1 常见现象速查表表格里面是我自己调试以及帮别人看代码时最常遇到的问题基本覆盖了从 SPI 通信到 NAND 数据的典型故障现象常见原因排查方向读 ID 正常写入后读回全 FF没发写使能 0x06或 WEL 状态异常先检查写使能流程再检查 P_FAIL写入后读回错位数据列地址/行地址算错把线性地址当页号确认页号没有乘页大小擦除后数据还在块地址计算错误擦错块打印块地址核对页号除 64 的商OIP 轮询一直超时SPI 时钟极性不对或命令序列错抓逻辑分析仪核对命令字节数据偶发跳变ECC 错误没处理或电源噪声查看 SR2 的 ECC 位检查供电读取 OOB 数据错乱列地址没有从 0x0800 开始确认 spare 区列地址计算7.2 一次“读 ID 正常读写全 FF”的排查实录我调了一个下午的板子状态是 ID 能读出来写数据后读回全部是 FF。逻辑分析仪抓上发现命令和技术手册完全一致该写的 0x06、0x02、0x10 都发了该等 OIP 也等了但结果就是不对。最后发现是 SPI 控制器在连续两次 spi_write 调用之间自动把 CS 拉高又拉低了。W25N01GV 的 LOAD PROGRAM DATA 和 PROGRAM EXECUTE 虽然可以在不同 CS 周期内发送但某些情况下片选被切断会导致命令状态丢失。解决方案有两种一种是把多条命令拼在一个 spi_transfer 里发保持 CS 低电平另一种是确保 SPI 控制器驱动中CS 控制模式是 GPIO 手控而非硬件自动片选。我最终选择了把 0x06 单独发一次没问题但把 0x02 地址 数据 0x10 行地址尽量合成一次传输。如果你只是调裸机用 GPIO 模拟 CS 反而更可控。7.3 性能与稳定性优化点滴最后分享几个实测后的性能调优方向。页编程标称典型值 700 微秒但在我的板子上实测平均 1.2 毫秒左右最差到 2 毫秒所以超时时间不能卡太死。擦除命令较慢实测 3 到 5 毫秒批量擦除时可以先把要擦的块列表准备好逐个发 D8h 命令然后统一等待完成而不是发一个擦一个等一个这样能省一点交互时间。DMA 传输是另一个能立竿见影的优化点。2048 字节的数据通过 SPI 搬运如果主控 SPI 控制器支持 DMA页读写的 CPU 占用会大幅下降。我优化之后连续读大文件的 CPU 占用从 40% 降到了 10% 以内对整体系统响应帮助很明显。ECC 策略上不要把阈值卡得太死。如果一页出现一次 ECC 错误就立刻搬块可能导致频繁数据搬迁反而加快磨损。我实测发现偶尔一次 ECC 错误往往是瞬时干扰或者读扰动可以继续观察连续多次、或者 ECC 错误状态变得严重才是真正需要搬块的时候。我个人在实际调试中最大的体会是SPI NAND 的驱动本质上就是把“先搬缓冲区再操作阵列”这套思维刻进骨子里。W25N01GV 不算复杂但它和 SPI NOR 的思维模型差异很大很多坑都来自“惯性”。如果你正在调这颗芯片先把状态寄存器的读取函数写对把列地址和行地址分开打印验证再把整页读写跑通最后再考虑坏块和 ECC。按这个顺序来基本不会走弯路。