简介：这是一份面向嵌入式驱动开发者的NAND Flash测试程序，围绕驱动与硬件交互中的基础读写测试、坏块检测、ECC校验、损耗均衡、页与块管理、性能测试和故障模拟等关键环节展开，适合正在调试NAND Flash驱动代码或希望系统学习闪存工作原理的工程师。压缩包共27个文件，大小约8.33MB，以4个h头文件和3个cpp源文件为主，配合Visual Studio工程配置（vcproj/sln）、编译中间文件（obj/pdb）及可执行exe，便于直接打开、编译和运行；“测试程序2”目录是较新版本或独立测试模块，覆盖了从数据一致性验证到异常恢复的完整测试链路。已有643人学习下载。阅读源码可以了解到坏块标记流程、页/块地址映射方式以及ECC纠错的具体实现，运行时还可通过故障模拟观察驱动程序的错误处理能力，是一份既能帮助定位驱动层问题、又能作为自研NAND Flash验证框架参考的实用工具。

1. 一个随手写的擦除函数，为什么能把整片 Flash 毁掉

第一次接触 NAND Flash 测试程序的人，十有八九会栽在同一个坑里：以为和 EEPROM 一样，可以随便对某个字节地址写数据、读数据。结果一个看似正常的擦除函数跑下去，整片数据没了，坏块表也被冲掉了，板子上的系统直接起不来。这不是玄学，而是 NAND 的物理脾气——按页读写、按块擦除，写操作只能把 1 变成 0，想改一个字节得先把整块擦掉。测试程序的价值就是把这套脾气封装成一套可靠的坏块管理、擦写读校验、ECC 检错和全片吞吐量统计流程。无论你是要验证一颗新拿到的颗粒，还是给产线做老化测试，这套代码都能让你看清这颗 Flash 的真实状态。文章里我会从架构讲起，拆到坏块扫描、特征数据比对、ECC 校验这几个核心模块，最后给出可跑的编译命令和后续改造的切入点。

2. 读懂 NAND Flash 的物理脾气：从字节读写到坏块管理

2.1 为什么不能用"字节"思维操作 NAND Flash

先看一组我常用来给新同事讲的结构参数。一颗常见的 2Gb 并行 NAND 颗粒，内部结构大概是这样的：

这里的核心约束是：读和写（编程）只能按页进行，一次最少操作一整页；擦除只能按块进行，一次最少擦掉一整块。更反直觉的是，NAND 的编程只能把 1 变成 0。你要把某个字节从 0 改回 1，需要的不是一条"写"指令，而是先擦除整个块，再重新编程。这就是为什么"字节思维"在 NAND 上完全行不通——测试程序如果按字节去比对、去修改，会在时序和逻辑上双重翻车。

理解了这一点，再看测试程序的设计目标就清楚了：它要做的不是验证某一个字节能否读写，而是验证整个介质在擦除、编程、读回三个闭环动作后的数据一致性，同时把坏块、位翻转这些介质特性量化出来。我把它拆成四个层次：驱动层负责和控制器寄存器打交道，坏块层负责扫描与表管理，测试引擎负责生成测试模式和比对，报告层负责把结果整理成人能看懂的日志。

位翻转是 NAND 的常态，不是异常。读数据时偶尔出现一个 bit 反了，这在 SLC 上概率低，MLC 上就明显了，TLC 上更不能不做 ECC。所以测试程序里必须区分两种情况：带 ECC 的保护性读，和不带 ECC 的裸读。前者模拟真实使用场景，后者用于暴露介质本身的缺陷。设计测试项时我会把"带 ECC 通过"和"裸读通过"分成两档结果，方便定位是 ECC 能力不足还是介质本身有问题。

2.2 测试程序的模块构成与文件组织

这套测试程序我习惯用 C 写，理由很简单：要直接操作寄存器、要控制时序，而且产线环境里跑在裸机或 RTOS 上的概率远大于跑在 Linux 上。代码按下面这个目录组织：

nand_test/ ├── Makefile ├── README.md ├── config/ │ └── nand_config.h /* 颗粒几何参数、测试项开关 */ ├── driver/ │ ├── nand_drv.c /* 页读写、块擦除、坏块读 */ │ ├── nand_drv.h │ ├── nand_hw.c /* 控制器的寄存器操作 */ │ └── nand_hw.h ├── test/ │ ├── test_engine.c /* 测试项注册与调度 */ │ ├── test_badblock.c /* 坏块扫描与表管理 */ │ ├── test_full.c /* 全片擦写读测试 */ │ ├── test_ecc.c /* ECC 能力验证 */ │ └── test_log.c /* 日志与统计输出 */ └── tools/ └── parse_log.py /* 上位机日志解析脚本 */

这个结构的好处是职责边界非常清楚。driver 目录里不关心你要测什么，它只回答三个问题：这一页能不能读、能不能写、这个块能不能擦。test 目录则完全不碰寄存器，它只做一件事：组织数据、做比对、下结论。config 里的头文件是所有模块的公共依赖，换一颗颗粒时只需要改这一个文件。

我在 test 目录里做了一个很简单的注册表机制：每个测试项是一个结构体，包含名字、初始化函数、执行函数、收尾函数。测试引擎按注册顺序逐个执行，任何一个测试项返回失败代码，引擎会记录下来继续跑下一个。这样做的好处后面会体现——产线想加一个高低温恢复测试，只需要新增一个文件再挂进注册表，不需要动引擎代码。

2.3 换颗粒时只改配置参数的技巧

换颗粒是测试程序最常见的维护场景。我从一开始就把所有和硬件强相关的量收进 nand_config.h：

/* nand_config.h —— 换颗粒时只改这里 */ #define NAND_PAGE_SIZE (2048 + 64) /* 2KB 数据 + 64B 备用 */ #define NAND_PAGES_PER_BLOCK 128 #define NAND_BLOCKS_PER_LUN 2048 #define NAND_PLANE_CNT 2 #define NAND_ECC_BYTES 8 /* 每 512B 冗余 8B */

这段配置头文件还有更微妙的地方。column 地址长度由页大小决定，row 地址长度由块数和每块页数决定。很多测试程序跑飞，不是算法写错了，而是地址拼接时位宽没对上，比如 2KB 页的 column 地址占 11 位，多写一位就会串到行地址上去。我会在 Makefile 里用编译期断言去检查这些位宽和实际颗粒参数是否一致，避免这种低级错误在产线爆雷，这种坑我从血泪里学来的代价不低。

测试程序本身也有一个我很在意的设计点：所有擦写读循环都做成"可拆分为独立步骤"的形式。也就是说，擦、写、读、比对四个动作不是一个大函数，而是各自可独立调用的接口，测试策略由上层组合。比如先擦再写再读回再比对，这是全片测试；只读不写，这是读取校验；只写不读，这是快速填充。同一套驱动能复用到多种场景，这也是为什么反复强调接口分层而不是上来就写一个大循环，后续维护的人会感谢你的。

3. 核心模块拆解：坏块扫描、擦写读校验与 ECC 检错的完整链路

3.1 驱动抽象层：把硬件差异挡在门外

测试引擎和硬件之间隔了一层函数指针结构体，这是整个程序里我最坚持的设计。

/* nand_drv.h —— 驱动抽象 */ typedef struct { int (*page_read)(uint32_t row, uint32_t col, uint8_t *buf, int len); int (*page_write)(uint32_t row, uint32_t col, const uint8_t *buf, int len); int (*block_erase)(uint32_t block); int (*is_bad)(uint32_t block); void (*mark_bad)(uint32_t block); } nand_ops_t; int nand_drv_init(nand_ops_t *ops, const nand_geom_t *geom);

这套函数指针的设计目的很单纯：test 目录里的代码永远不直接调用寄存器操作，而是调用这组接口。这样即使控制器换了、时序变了，测试逻辑一行都不用动。我一般会在这层再包一层参数合法性检查，比如页号超出范围、buffer 不是 4 字节对齐，这类问题越早拦截越省事。参数里的 row 对应块号乘每块页数再加页内偏移，col 对应页内字节偏移，len 是本次传输长度，这三个参数构成了一次读写请求的完整寻址信息。

3.2 坏块扫描与坏块表管理

NAND 出厂时就不是所有块都是好的。出厂坏块的标记位置在块内第 1 页（有些在 1、2 页都有）的备用区特定偏移处，值不是 0xFF 就视为坏块。扫描逻辑：

/* 扫描全片坏块，结果写入 bitmap */ static void scan_badblocks(nand_ops_t *ops, uint8_t *bbt, int block_cnt) { for (int blk = 0; blk < block_cnt; blk++) { uint8_t oob[64]; memset(oob, 0, sizeof(oob)); /* 读块首页备用区，偏移 5 处为出厂坏块标记 */ if (ops->page_read(blk * NAND_PAGES_PER_BLOCK, 0, oob, NAND_ECC_BYTES + 16) < 0) { continue; /* 读失败也当坏块处理，但先记日志 */ } if (oob[5] != 0xFF) { bbt[blk / 8] |= (1 << (blk % 8)); } } }

有个细节容易忽略：page_read 的 col 参数不是从数据区起点开始，而是要与 nand_drv_init 里约定的偏移一致。上述代码里我把 col 设为 0，读回的是数据区前 24 字节，再靠 OOB 偏移 5 判断。不同颗粒的坏块标记位置会有差异，有的在第 1 页，有的在第 1、2 页都写，我一般两个位置都检查，宁可多查一个页也不漏判。

坏块表我用一个 bit 来表示一个块的状态，而不是用一个字节，这样 2048 个块只需要 256 字节。这套 bitmap 不仅在扫描时用，测试过程中新发现的坏块也会实时置位，最后统一记录到测试报告里。注意：不要把坏块表存放在被测颗粒上，尤其是高低温老化测试，介质不可靠时这个表本身就可能是错的，这是要牢记的后悔药。

3.3 全片擦写读测试与特征数据生成

全片测试的核心逻辑是"擦除-写特征数据-读回验证"三步循环。特征数据我用的是伪随机序列而不是固定值：固定值如 0x00 或 0xFF 无法暴露相邻 bit 干扰问题，伪随机序列才能让每一位都有机会翻转。

/* 全片擦写读测试 */ static int full_rw_test(nand_ops_t *ops, uint8_t *bbt) { uint8_t wbuf[NAND_PAGE_SIZE], rbuf[NAND_PAGE_SIZE]; int fail_cnt = 0; for (int blk = 0; blk < NAND_BLOCKS_PER_LUN; blk++) { if (bbt[blk / 8] & (1 << (blk % 8))) continue; /* 跳过已知坏块 */ if (ops->block_erase(blk) != 0) { ops->mark_bad(blk); /* 擦除失败即坏块 */ fail_cnt++; continue; } for (int p = 0; p < NAND_PAGES_PER_BLOCK; p++) { gen_prbs(wbuf, NAND_PAGE_SIZE, blk, p); /* 按块/页生成不同序列 */ if (ops->page_write(blk * NAND_PAGES_PER_BLOCK + p, 0, wbuf, NAND_PAGE_SIZE) != 0) { ops->mark_bad(blk); break; } if (ops->page_read(blk * NAND_PAGES_PER_BLOCK + p, 0, rbuf, NAND_PAGE_SIZE) != 0 || memcmp(wbuf, rbuf, NAND_PAGE_SIZE) != 0) { ops->mark_bad(blk); /* 读回不一致即判坏 */ break; } } } return fail_cnt; }

这段代码是最容易在产线爆雷的地方，原因有三。第一，PRBS 的种子必须和块号、页号相关，否则换一块数据相同，干扰模式就测不出来。第二，读取后比对前必须确认是否走 ECC，而这里是裸读流程，故意不做 ECC——目的是暴露介质本身的问题；如果要做 ECC 校验，应该走另一套带校验的路径，而不是混在一起。第三，一块内任何一页失败，整块就会被标记为坏块，这是 NAND 的规矩，因为擦除是块粒度的，块内一页坏了整块都不可用。

伪随机序列生成这里，我直接用 32 位 LFSR，种子设为 (blk << 16) | p，保证不同位置数据不重复。注意 LFSR 生成的序列首尾循环是可预测的，但测试场景下我们不追求加密强度，只追求相邻页数据差异足够大，这已经足够暴露多数干扰问题。

3.4 ECC 校验与统计输出

裸读之后还要跑带 ECC 的流程，用来区分两类问题：裸读出错了但 ECC 能纠正，说明介质还能用；裸读出错了 ECC 也纠不回来，这页就是真坏了。我在测试引擎里为每个页记录三种计数：页读回成功、ECC 纠正次数、ECC 纠错失败次数。

/* 统计页状态 */ typedef struct { uint32_t total_pages; uint32_t ecc_corrected; /* 裸读有错但 ECC 可纠 */ uint32_t ecc_failed; /* ECC 无法修正 */ uint32_t read_failed; /* 控制器读操作直接失败 */ } page_stat_t;

日志输出端我会生成一行摘要，例如：

[PASS] block=0017 page=42 ecc_corrected=1 raw_bitflip=3 [FAIL] block=0091 page=07 ecc_corrected=0 raw_bitflip=7 reason=uncorrectable [SUMMARY] total_pages=262144 pass=262143 fail=1 ecc_corrected=57 fail_blocks=1

这里面的 raw_bitflip 是裸读时与期望数据逐位比对出来的翻转数，它是最能反映颗粒老化程度的数据。同一颗颗粒如果连续几轮测试 raw_bitflip 都是 0，说明余量很足；如果从 0 慢慢涨到 5、涨到 10，就得开始担心寿命了。这也是测试程序区别于普通文件系统的最重要一点——它能测量介质的老化趋势，而不只是判断"能用/不能用"。

4. 编译运行与结果解读：从交叉编译到日志判读

4.1 环境准备与编译流程

这个测试程序不依赖第三方库，只需要交叉编译工具链和一个能操作 NAND 控制器的板级平台。我一般用下面这套流程：

# 设置交叉编译环境，目标平台为某 32 位 ARM 主控 export CROSS_COMPILE=arm-none-eabi- export CC=${CROSS_COMPILE}gcc # 编译，release 模式下会带 -O2 和静态断言 make clean && make RELEASE=1 # 通过串口或 JTAG 把固件加载到板端执行

Makefile 里我只放了三个编译目标：release、debug、sim。sim 目标很关键——它在 PC 上用一个内存文件模拟 NAND 的页和块，让没有开发板的人也能先把测试逻辑跑通。我在编译期做了两个检查：一是检查 NAND_PAGE_SIZE 是否超过内部缓冲；二是检查 row/col 位宽是否溢出。这两类问题在板子上很难排查，在编译期拦住能省一整天，这是调试效率的关键。

# 不接硬件，直接用模拟器跑逻辑测试 make sim ./build/nand_test_sim --iterations 3

模拟器不是玩具。它会把每次擦写读的错误注入到一个可配置的比例里，用于验证坏块标记和 ECC 统计路径是否正常工作。我会在模拟器里故意注入某个块擦除失败，看最终报告里是否把它标成坏块，以此验证测试程序自身的正确性，相当于先给测试程序自己做一遍体检。

4.2 测试参数配置说明

所有可调参数都在 config/nand_config.h 里集中定义，我整理了一张常用参数表：

有一处我要特意说明：PRBS_SEED_BASE 默认值是固定常数，但产线跑第二轮时如果还用同一个种子，某些干扰场景可能复现不出来。我习惯把它改成随机种子，从板级定时器或 RTC 里取一个值，让每一轮的测试数据都不同，这样多轮老化测试覆盖到的模式更全面。

切换颗粒时，除了改上述参数，还要确认 OOB 偏移量、坏块标记位置、ECC 强度这三个和介质型号强相关的配置项。如果只改页大小其他不动，很容易出现"测试通过但换到产线就翻车"的情况——数据区和备用区的地址映射错位了，读回的数据从错误的列偏移开始比对，程序自己发现不了。

4.3 测试日志怎么看：从 PASS/FAIL 到吞吐统计

日志分三个等级：info 记录测试项开始结束；detail 记录每块每页的结果；error 记录失败和坏块事件。命令行参数可以控制日志级别，产线只需要看 error 和 summary。

吞吐数据在上位机解析：日志输出每轮耗时，我用 parse_log.py 汇总出有效写入吞吐、读取吞吐、擦除次数、写放大倍数。写放大倍数是个有意思的概念：擦除按块、写按页，如果频繁擦写小块数据，实际物理擦除量会远大于逻辑写入量。测试程序统计这个数值，可以帮助判断后续文件系统算法是否需要在 block 分配策略上做优化。

这里给一个日志判读的实操建议：只看 summary 行里 pass、fail 和 fail_blocks 三个数是不够的。如果 pass 接近满、fail 是 1，你得去翻 detail 看那一个块失败在哪一页、错误是读失败还是 ECC 失败。读失败大概率是硬件时序或电压问题，ECC 纠不回来大多是介质寿命问题，这两者的处理方式完全不同。

判据上我定了三条硬规则：裸读 raw_bitflip 超过 ECC 纠错能力一半的页要告警；单轮测试新增坏块超过总块数 1% 即判整片失效；连续三轮测试 raw_bitflip 呈上升趋势时建议降级使用。这三条规则直接写在 parse_log.py 里，产线只看最后一行结论即可。

5. 避坑清单：NAND Flash 测试程序跑完却不敢信的五个瞬间

折腾这套测试程序的时间里，我踩过的坑远比代码行数多。下面这五条是我每次给别人讲内部实现时必提的，每一条都对应过一个真实的翻车现场。

5.1 坏块表被当成好块写进了测试

现象：第二轮全片测试开始时，上一轮标记的坏块突然能读了，而且数据看起来正常，于是被视为好块参与测试，测试结果一片飘绿，实际上整片介质已经处于不可信状态。

原因：坏块表存储的位置正是在被测颗粒上，又恰好落在某一轮擦除范围内，测试程序在擦除全片时把坏块表也擦掉了，后续迭代自然把坏块当成好块处理。

解决：坏块表放两份，一份在板载非易失存储里，一份在测试开始时重新单独扫描。代码里我加了保护：任何全片擦除动作执行前，先把当前坏块表备份到板载存储，擦除完成后立刻从备份恢复并跳过所有标记块。

5.2 擦除后读回不是全 FF，差点误判整片报废

现象：擦除命令返回成功，但读回的页数据中有少量 bit 不是 1，第一反应是擦除电路坏了，整片都要不得了。

原因：部分控制器在擦除后不保证页数据立即可读，存在一个很小的电荷泄放窗口；另外老化的 NAND 颗粒擦除后可能残留少量电荷，需要经过短暂稳定时间才能呈现标准的全 FF 状态。

解决：擦除后加一个 10ms 的稳定延时，再读一次确认。不要把"擦除后必须读到全 FF"当成铁律，尤其是高低温测试场景。我现在在驱动里把这个延时做成可配置项，不同颗粒用不同值，默认 10ms，最慢的颗粒 50ms 也能稳过。

5.3 buffer 不是 4 字节对齐，偶发校验失败

现象：测试结果不稳定，同一块同一页有时通过有时失败，单独重读又全部通过，很像介质的问题，但换一颗新颗粒同样复现，排查方向一度跑偏。

原因：控制器 DMA 要求 buffer 地址对齐，未对齐时 DMA 搬运错位，数据落在相邻地址上。这类问题在 debug 版偶尔能过，release 版开 -O2 优化后才稳定暴露，是最典型的黑匣子问题。

解决：所有读写 buffer 在定义时声明为 4 字节对齐，或使用编译器的对齐属性，并把 misaligned 检测写在 nand_drv 接口层入口处。我在接口里加了一行断言，只要发现地址不对齐立刻打印 caller 的行号，后续再没人能悄悄传一个栈上裸数组进来。

5.4 裸读失败被误判为坏块，实际只是时序问题

现象：全片测试结束后坏块数量暴增，但把这些"坏块"重新单独擦写一遍又全部通过，坏块表里存了一堆假坏块。

原因：测试循环中写后立即读，控制器没有留出足够的 tWB/tRR 时序，读命令发出太快，第一页读回的是写完成前的残留信号。不同主控的自动等待能力差异很大，有的主控帮你等了，有的完全不管。

解决：写命令后插入最小间隔延时再发起读，测试代码不依赖控制器自动等待。时序相关参数我在配置里单独开了 TEST_TIMING_SAFE 开关，默认开启，只有确认主控自带等待机制时才关闭，为了那一点速度牺牲稳定性不值得。

5.5 PRBS 种子固定，多轮测试数据完全一样，干扰测不出来

现象：三轮老化测试的 raw_bitflip 始终是 0，看起来颗粒非常健康，但换产线负载后立刻出现丢数据，同一批颗粒报废率明显偏高。

原因：每轮测试生成的页数据完全相同，相邻页之间的耦合干扰在相同数据下不会触发。固定种子的 PRBS 本质上退化成了一种固定模式，早已失去随机性意义。

解决：每轮测试前从随机源更新 PRBS_SEED_BASE，并透明地把种子记录到日志头里，方便复现。从那以后我每次做老化测试，第一件事就是确认种子在变，这个习惯帮我拦下了至少三批有潜在问题的颗粒。

6. 二次开发思路：把测试程序改造成产线自动测试工具

6.1 换个入口：从裸机固件到串口命令行框架

如果只是自己调试，现有的 Makefile 编译烧写流程已经够用。但产线场景需要让操作员输入一条命令就完成全流程测试，这就要把 test_engine 的命令解析暴露成串口命令。具体要做的只是增加一个 uart_cmd.c 模块，把 test_engine.c 的注册表映射成字符串命令，比如输入run full执行全片测试，输入stat查看当前统计。

6.2 添加自定义测试项的代码骨架

产线经常要加新的测试策略，比如高低温保持测试。注册表机制让这件事变得很简单：

/* 新增高温保持测试 */ static int ht_hold_init(void) { /* 配置加热控制引脚、设置温度阈值 */ return 0; } static int ht_hold_run(void) { /* 执行 85 度保持 + 定时读回校验 */ return 0; } test_item_t test_ht_hold = { .name = "ht_hold", .init = ht_hold_init, .run = ht_hold_run, .cleanup = NULL, }; /* 在 test_engine.c 的 items[] 数组里加入 &test_hold 即可 */

新增测试项不需要改动引擎的调度逻辑，只需要实现 init、run、cleanup 三个函数并加入注册表。我在模拟器里会专门验证一件事：新测试项返回失败时，引擎是否能正确记录并继续执行后续测试项，避免一个测试项挂掉导致整条产线停摆。

6.3 验证方法：模拟器先行，真机后行

改造完成后，先在 sim 环境添加假数据，确认注册表、日志、统计都符合预期，再拿到板子上跑。模拟器挂了就别上真机，这是我的铁律。模拟器和真机差异最大的地方是时序，所以我会在模拟器里故意注入延时抖动，验证测试程序在时序波动时也能给出稳定的判据。

从接手这个测试程序到现在，我最大的改变是不再迷信一次的 PASS/FAIL。每一次测试结束，我都会强制自己看一眼 raw_bitflip 的趋势、坏块表的增长曲线、以及 PRBS 种子是否在变。这三样东西比一个 pass 结果更能说明问题，希望你跑起来以后，也能建立起这套读数据的习惯。希望帮到你。

本文还有配套的精品资源，点击获取