做嵌入式这几年，SPI NOR Flash的驱动我写过不少，按字节读、按扇区擦、查状态位等忙，对我来说基本属于家常便饭。直到第一次在项目里拿到 W25N01GV 这颗 SPI NAND，我本以为就是“大号 W25Q”，结果刚上手就被页编程的结果打脸：写进去再读出来，开头一段是新数据，后面全是旧内容，查状态寄存器还显示编程成功。后来翻数据手册、抓 SPI 波形、反复做读写对比，才彻底搞明白这颗芯片的脾气——所有读写都必须经过内部那 2KB 缓冲区，状态寄存器的读取协议也和 NOR 系列完全不一样。
这篇就把我在这颗芯片上踩过的坑、验证过的正确用法、以及从裸机驱动到 Linux MTD 框架的接入经验整理出来。如果你正在做 W25N01GV 或类似 SPI NAND（W25N01JV、W25M02 系列）的驱动，或者只是被“SPI NAND 缓冲区机制”这个概念绕晕了，这篇应该能帮你省下不少调试时间。
1. 先搞清楚 W25N01GV 是个什么芯片：规格与设计思路
1.1 为什么项目里会选 SPI NAND 而不是 SPI NOR
我以前习惯用 SPI NOR，最大的好处是接口简单、读随机地址无需缓冲区、支持 XIP 直接执行。但项目一旦需要存几十 MB 以上的固件、日志或文件系统，NOR 的每 MB 成本和擦写寿命就不太划算了。W25N01GV 这类 SPI NAND 的出现，本质上就是把传统并行 NAND 的大容量、页读写、块擦除特性，封装进标准 SPI 接口里，引脚数量少、PCB 走线简单、MCU 和主控都能直接外扩存储。
选择 W25N01GV 的典型场景是：容量需求在 64MB 到 128MB 之间，主控没有并行 NAND 控制器，但又不想为容量付出 NOR 的高成本。W25N01GV 的容量是 1Gbit，也就是 128MB，内部分为 1024 个块，每个块 64 页，每页 2048 字节主数据区加 64 字节 OOB/Spare 区。这个结构决定了它和 NOR 的寻址方式完全不是一个套路。
1.2 W25N01GV 核心参数速览
拿到芯片以后，我习惯先把数据手册里的关键参数整理成一张表，方便驱动开发和后续调试时随时对照：
| 参数项 | 数值/说明 |
|---|---|
| 容量 | 1Gbit（128MB），1024 个块 |
| 页大小 | 2048 字节主区 + 64 字节 OOB 区 |
| 块大小 | 64 页，共 128KB + 4KB OOB |
| 页编程时间 | 典型值不超过 2ms 左右，实测约 0.6~1.4ms |
| 块擦除时间 | 典型值不超过 10ms 左右 |
| SPI 频率 | 最高 104MHz（取决于读命令和供电），我实际跑 50MHz 很稳定 |
| 内部 ECC | 支持硬件 ECC，校正状态可通过状态寄存器读取 |
| 工作电压 | W25N01GV 是 1.8V 版本，3.3V 版本是 W25N01JV，选型时别搞混 |
重点提醒一句，W25N01GV 和 W25N01JV 在命令集和驱动逻辑上几乎一致，但电平不一样，板子设计时如果按 1.8V 做了，千万不能直接把 3.3V 版本贴上去，反过来也一样。这类低级错误最容易在项目转产时出现。
2. 2KB 缓冲区机制：被低估的关键设计
2.1 缓冲区决定了什么：读、写、擦除流程
W25N01GV 内部有一个大小为 2KB（严格说是覆盖整个页容量）的缓冲区，所有对存储阵列（Memory Array）的读写都得经过它。用一句话概括就是：芯片对外呈现的 SPI 接口并不直接连着存储阵列，而是先连到缓冲区，再由缓冲区与阵列之间按“页”搬运数据。
这个设计和 NOR Flash 的逻辑差异非常大。在 W25Q 系列里，你发一个 READ 命令加 24 位地址，数据就能直接出来；在 W25N01GV 里，读取一页数据通常要分两步——先把阵列中指定页的数据“搬运”到缓冲区，再从缓冲区把数据读出来。页编程则反过来，先把主机数据写入缓冲区，再执行一个“编程执行”命令，把缓冲区内容烧进阵列。
所以，缓冲区不只是缓存，它就是主数据通路。驱动开发时，所有关于“页内偏移”“OOB 访问”的地址计算，都要基于缓冲区的地址空间来考虑，而不是直接映射到整个芯片容量。
2.2 编程前不填充缓冲区会怎么样：最大教训
我第一次写页编程时走了捷径，想着只更新页里某一小段数据，就只往缓冲区发送了那一段，然后直接发 PROGRAM EXECUTE。结果读回整页发现，没更新的区域读出来居然是上一页的数据，而不是我预想中的 0xFF。
原因在于，PROGRAM LOAD 命令（0x02）只会把传入的数据写入缓冲区对应的列地址，缓冲区其他区域保持原先的内容。而缓冲区在上一次读写操作后，可能还残留着之前某页的数据。执行 PROGRAM EXECUTE 时，芯片会把整个 2KB 缓冲区都烧写进目标页的阵列区，于是残留数据就跟着写进去了。
正确做法是：在组装页数据时，用一个 2KB 的缓冲区数组，先把整页填成 0xFF，再把你需要更新的字段写入对应偏移位置，最后一次性把整页数据通过 PROGRAM LOAD 加载进芯片缓冲区，再执行 PROGRAM EXECUTE。如果确实只想改部分数据，也要先从阵列读回整页、在 RAM 里修改、再整页写回，绝不能只加载局部数据就执行编程。这个坑在 NOR 上完全不存在，但在所有 SPI NAND 上都会遇到。
2.3 读取时先在阵列与缓冲区之间“搬运”
读取操作的典型流程是：先发送 READ ARRAY（0x13）命令和行地址，等待状态寄存器的 BUSY 位清掉，再把列地址和 READ DATA（0x03）命令发出去，从缓冲区连续读数据。
需要注意，0x13 命令本身不带数据输出，它只负责把指定页从阵列搬到缓冲区。如果直接用 0x03 去读，不管你怎么给地址，读出来的都是缓冲区里的旧内容。我调试时有一次就是忘了发 0x13，结果读回来的数据永远是上一次操作的那一页，排了好久才发现是命令序列不对。
有的芯片型号还支持 0x23 这类“加载并输出”命令，一条命令完成搬运和读取。但这个命令在不同厂家的 SPI NAND 上兼容性并不一致，如果驱动要跨芯片复用，建议还是老老实实按照“先 0x13 加载，再 0x03 读取”的流程走，最稳妥。
3. 状态寄存器：怎么读、读哪些位、什么时候读
3.1 三个状态寄存器的位定义与含义
W25N01GV 一共有三个状态寄存器，分别用不同命令读取：
| 寄存器 | 读取命令 | 关键位 | 含义 |
|---|---|---|---|
| SR1 | 0x0F | bit0 | BUSY，1 表示忙，0 表示空闲 |
| SR1 | 0x0F | bit1 | WEL，写使能锁存位，1 表示允许写/擦除 |
| SR1 | 0x0F | bit5:2 | BP0~BP2，块保护位 |
| SR1 | 0x0F | bit6 | BP3，块保护扩展位 |
| SR1 | 0x0F | bit7 | SRP0，状态寄存器保护位 |
| SR2 | 0x1F | 低 5 位 | BP4、CMP、LB 等保护/锁定位 |
| SR3 | 0x5F | bit0 | P_Fail，页编程失败标志 |
| SR3 | 0x5F | bit1 | E_Fail，块擦除失败标志 |
| SR3 | 0x5F | bit4:5 | ECC 状态，00 无错误，01 有 1bit 错误已纠正 |
和 NOR 的 SReg 相比，这颗芯片多出来的关键是 SR3。NOR 写完了只需要等 BUSY 和 WEL，而 NAND 由于页编程、块擦除本身存在更高的失败概率，芯片会用 P_Fail/E_Fail 标志记录最近一次操作是否真的成功。忽略这两个位，就会出现“状态显示不忙，但数据实际没写对”的情况。
3.2 状态读取的时序细节
读 SR1 时发送 0x0F，之后在片选保持低电平期间，芯片会持续输出 SR1 的内容，相当于自动重复。很多现成代码喜欢这样写：
static int spi_nand_wait_busy(struct spi_device *spi, int timeout_ms) { u8 cmd = 0x0F; u8 sr1 = 0; while (timeout_ms--) { spi_write_then_read(spi, &cmd, 1, &sr1, 1); if (!(sr1 & 0x01)) return 0; udelay(1000); } return -ETIMEDOUT; }这个写法本身没问题，但有两个细节要注意：
一是片选。spi_write_then_read 会保证一次传输中片选只拉低一次。如果发命令和读字节拆成两次 spi_transfer，中间片选被拉高再拉低，读到的状态就有可能是旧值或错误值。
二是不要把 0xFF 当成异常。芯片空闲且无写保护时，SR1 读出来可能接近 0xFF（忙位为 0、WEL 为 0、保护位为默认值），有的调试者看到 0xFF 就以为是通信异常，实际是正常状态。要判断通信是否正常，更可靠的办法是读 JEDEC ID，而不是看状态寄存器。
3.3 P_Fail 与 E_Fail 必须检查
我后来在驱动里加了一个强制检查：每次页编程或者块擦除完成后，等 BUSY 清掉，紧接着读 SR3，检查 bit0 和 bit1。只要有一个为 1，就向上层报告写失败，并标记相关块为坏块候选。
从实际效果看，这个检查非常有必要。有一次我在做长时间连续写入测试时，发现某块区域擦除后读回还有残留数据，就是因为擦除过程中电压有点波动，E_Fail 位被置 1，但驱动没检查，上层完全无感知。添加状态检查后，问题立刻就能定位到具体块，而不是整盘数据越写越乱。
4. Linux 驱动接入：从裸机到 MTD 框架的落地
4.1 驱动方案选型：自研还是用内核框架
如果项目跑的是嵌入式 Linux，我强烈建议不要从零写一套完整 SPI NAND 驱动。内核从 4.x 开始已经有比较成熟的 spi-nand 框架，位置在 drivers/mtd/nand/spi/，它封装了页读写、块擦除、ECC、坏块表、MTD 分区等核心逻辑，我们需要做的通常只是确认平台 SPI 控制器的适配和设备树节点。
自研裸机驱动反而更适合 RTOS 或者 MCU 场景。W25N01GV 的命令集不复杂，裸机驱动完全可以自己写，但坏块管理、磨损均衡、ECC 校验这些重量级逻辑要从零搞，工程量大且容易出隐患。
所以我的建议是：Linux 场景尽量用内核框架，裸机场景才考虑手写命令序列。
4.2 关键函数实现与代码细节
即使框架帮我们做了大部分事情，实际调试时还是需要理解底层命令序列。下面是我在裸机上验证过的几个关键片段，逻辑同样适用于理解内核驱动行为。
读 JEDEC ID：
static int spi_nand_read_id(struct spi_device *spi) { u8 cmd = 0x9F; u8 id[4] = {0}; struct spi_transfer t = { .tx_buf = &cmd, .rx_buf = NULL, .len = 1, }; struct spi_message m; spi_message_init(&m); spi_message_add_tail(&t, &m); spi_sync(spi, &m); t.tx_buf = NULL; t.rx_buf = id; t.len = sizeof(id); spi_sync(spi, &m); pr_info("SPI NAND ID: %02x %02x %02x %02x\n", id[0], id[1], id[2], id[3]); return (id[0] == 0xEF && id[1] == 0xAA) ? 0 : -ENODEV; }注意这里 ID 建议读 4 个字节以上。W25N01GV 返回的第一个字节是厂商 ID（0xEF），第二个字节是设备 ID（0xAA），后面还会有容量等信息。如果只读 1 个字节，容易把厂商 ID 和设备 ID 搞混。
页编程函数：
static int spi_nand_page_program(struct spi_device *spi, u32 row, const u8 *data, size_t len) { u8 cmd; u8 sr1, sr3; u32 col = 0; struct spi_transfer xfer[3] = {0}; struct spi_message m; /* 1. 写使能 */ cmd = 0x06; spi_write_then_read(spi, &cmd, 1, NULL, 0); /* 2. PROGRAM LOAD 0x02，这里假设 data 已经是完整的 2KB 页数据 */ cmd = 0x02; xfer[0].tx_buf = &cmd; xfer[0].len = 1; /* 列地址 + 行地址，具体字节数按手册中地址长度定义 */ xfer[1].tx_buf = spi_nand_encode_addr(col, row); xfer[1].len = 3; xfer[2].tx_buf = data; xfer[2].len = len; spi_message_init(&m); spi_message_add_tail(&xfer[0], &m); spi_message_add_tail(&xfer[1], &m); spi_message_add_tail(&xfer[2], &m); spi_sync(spi, &m); /* 3. PROGRAM EXECUTE 0x10 */ cmd = 0x10; spi_write_then_read(spi, &cmd, 1, NULL, 0); /* 4. 等待 BUSY */ spi_nand_wait_busy(spi, 100); /* 5. 检查 SR3 */ cmd = 0x5F; spi_write_then_read(spi, &cmd, 1, &sr3, 1); if (sr3 & 0x03) { pr_err("program/erase fail, SR3=0x%02x\n", sr3); return -EIO; } return 0; }这段代码的重点不是照抄，而是理解顺序：写使能、加载数据、执行编程、等忙、查失败标志，五步缺一不可。尤其写使能，NAND 在每次页编程和块擦除之前都必须重新发 0x06，不能像 NOR 那样靠一次性写使能寄存器。
4.3 设备树与内核配置
在内核里使能 SPI NAND 支持，需要打开 CONFIG_MTD_SPI_NAND。设备树节点一般长这样：
&spi0 { status = "okay"; cs-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; nand@0 { compatible = "spi-nand"; reg = <0>; spi-max-frequency = <50000000>; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "boot"; reg = <0x0 0x0200000>; }; partition@1 { label = "rootfs"; reg = <0x0200000 0x7E00000>; }; }; };compatible 固定写 "spi-nand" 即可，框架会通过 JEDEC ID 自动匹配到具体芯片驱动。分区大小一定要按块对齐，SPI NAND 不支持按字节擦除，分区配置错了，UBI 挂载时会出现各种奇怪错误。
我遇到过最典型的问题是设备树里忘了配 spi-max-frequency，导致 SPI 控制器用默认低频跑，整盘吞吐量低到没法用。这个参数要根据实际 PCB 走线长度、主控 SPI 控制器能力和芯片规格综合设置，不要一味求高。
4.4 文件系统与坏块处理
W25N01GV 裸片出厂可能有坏块，而且使用过程中还会产生新坏块。Linux 下建议直接用 UBI 文件系统，配合 UBI 的坏块管理机制，驱动层不用自己维护坏块表。
使用 UBI 的步骤大致是：MTD 分区建好后，先做 UBI 格式化，再挂载为 UBIFS。第一次格式化时 UBI 会自动扫描擦除块，记录坏块。如果使用过程中发现坏块，UBI 也会自动重映射，不丢已有数据，只是可用容量会缩小。
在裸机或者 RTOS 场景下，坏块管理就得自己动手了。常见做法是：在每块第一页的 OOB 区首字节做坏块标记，读出为 0xFF 表示好块，非 0xFF 表示坏块。块擦除或页编程失败后，立即把对应块标记为坏块，并停止使用。
5. 排查经验：我踩过的坑和快速定位手段
5.1 常见问题速查表
把我在调试 W25N01GV 过程中遇到的高频问题整理成了表，每条都对应一个真实踩坑场景：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 读 ID 全是 0xFF | SPI 片选/时钟极性配置不对 | 检查 SPI 控制器 mode 和 cs-gpios |
| 页编程后读回旧数据 | 缓冲区未填充区域有残留 | 整页数据先填 0xFF 再加载 |
| 页编程后读回全 0xFF | 漏发写使能 0x06 或 WP 引脚拉低 | 每次编程前发 0x06，检查 WP 电平 |
| BUSY 状态一直为 1 | 片选被拉高，状态读取命令中断 | 确保命令+读字节在同一次 CS 低电平期间完成 |
| 擦除后读回不全是 0xFF | 擦除命令前没写使能，或行地址算错 | 确认地址按块对齐，发 0x06 后再擦除 |
| SR3 的 P_Fail/E_Fail 为 1 | 电压波动、坏块、时序不满足 | 标记坏块并做数据重写或上层补偿 |
| UBI 挂载报错 | 分区未按块对齐，或坏块标记错误 | 检查分区大小，重新擦除后格式化 |
5.2 关于坏块管理和 ECC 的一个建议
驱动开发阶段可以先用简单坏块表，但量产固件里我建议把坏块表和 ECC 检查都做上。W25N01GV 内部有硬件 ECC，读 SR3 能看到本次读取是否发生了 1bit 错误。如果 SR3 显示 ECC 纠正过错误，我通常会在驱动里返回一个“警告”状态给上层，让应用层决定是否重读或刷新数据。
一旦 SR3 报出不可纠正的 ECC 错误，这块数据大概率已经损坏，继续读出来的也是错值。这时候最稳妥的做法是直接从上一份备份或冗余区恢复数据，并把对应块标记为坏块。别指望靠多读几次碰运气，NAND 的错误纠正能力是有限的，越早发现越早隔离，整体系统才越可靠。
5.3 调试工具与日志手段
调试这类芯片，我强烈建议用逻辑分析仪抓一遍完整读写波形。别嫌麻烦，很多“间歇性读写失败”的问题，靠打印日志根本定位不了，但波形上一眼就能看出 CS 时序、命令顺序、地址字节长度哪里不对。
另一个实用技巧是加一个驱动自检命令：通过 debugfs 或 ioctl 触发“写固定数据到指定页、读回比对”的测试。我通常会在驱动里预留这种测试入口，代码稳定之前每次改动都跑一轮全地址范围的读写校验，比单纯靠应用层报错可靠得多。
日志方面，临时调试时可以在关键节点加 dev_info，但量产时一定要降级成 dev_dbg，否则大量 SPI 读写日志会把系统性能拖垮。经验值是：如果主控跑 50MHz SPI，每页读写过程中只要多打一行串口日志，吞吐量直接掉一半以上，这个问题在实时性要求高的场景特别明显。
最后再说一个容易被忽略的点：W25N01GV 的复位命令是 0xFF。如果驱动初始化时发现芯片状态不对，可以先软复位再重新读 ID，很多时候能免去给整板断电的麻烦。但要注意，软复位需要经过一段稳定时间，之后芯片内部缓冲区内容会变为不确定值，不要想当然地认为复位后缓冲区还是之前的数据。
