资讯动态

SD NAND Flash测试指南:从NAND原理到掉电可靠性验证

发布时间:2026/10/6 17:18:38 来源:尧图企业网站定制
这套流程我其实早就想整理一下。前阵子帮客户做存储方案选型对方拿着一片SD NAND Flash颗粒反复问这玩意儿和普通TF卡到底啥区别为什么有的板子上电就是识别不了测试的时候到底该测哪些项目这些问题看起来基础但真问到了产品落地的关键环节上。后来我干脆把整套判断逻辑和测试方法从头捋了一遍从Flash闪存底层原理一直到SD NAND Flash的可靠性验证写成了这篇文章一次性讲透。文章主要围绕两条线展开一条是打底知识也就是NAND Flash这种存储介质的工作原理为什么擦除操作这么特殊、寿命又是怎么被消耗的另一条是实操主线即拿到一片SD NAND Flash之后怎么科学地做容量验证、性能测试、数据完整性校验和掉电可靠性测试。适合嵌入式硬件工程师、固件工程师、以及对存储颗粒选型和验证有需求的测试工程师参考。1. Flash闪存基础测试之前绕不开的底层概念1.1 为什么要先搞懂Flash闪存的底层机制很多人觉得我测的是一个封装好的 SD NAND Flash 产品对外接口就是标准SD协议那我把底层NAND Flash的原理搞清楚是不是多此一举这个想法可以理解但实际踩过坑的人一定不这么认为。SD NAND Flash虽然内置了控制器对外表现得像一个即插即用的存储卡但它内部的数据存储介质依然是NAND Flash。整个产品最核心的可靠性指标比如擦写寿命、数据保持时间、掉电保护逻辑、坏块管理策略全部由NAND Flash的物理特性决定。你只有理解NAND Flash是拿什么存数据的、它最怕什么才能在测试出问题的时候快速定位是控制器固件的问题还是颗粒本身的特性所致。举一个真实例子我见过有人测试SD NAND发现写入同一个文件第二次比第一次慢了好几倍就直接判断产品有问题。实际上NAND Flash的写入机制决定了修改已有数据时必须先擦除旧数据这个擦除动作会引入额外延迟和垃圾回收开销。如果你不懂这个底层机制很容易把正常现象当成故障白白浪费调测时间。1.2 NAND Flash的存储单元类型SLC、MLC、TLC、QLCNAND Flash的基本存储单元是浮置栅晶体管靠浮栅中存储的电荷量来代表数据。一个单元能存多少bit决定了闪存的类型SLCSingle-Level Cell一个单元存1bit只有两种电荷状态对应0或1MLCMulti-Level Cell一个单元存2bit需要区分4种电荷状态TLCTriple-Level Cell一个单元存3bit需要区分8种电荷状态QLCQuad-Level Cell一个单元存4bit需要区分16种电荷状态不同单元类型在容量、寿命、性能上的差异非常大。为了直观对比我整理了一个表格单元类型每单元位数擦写寿命P/E Cycle读取速度写入速度相对成本SLC1bit50000~100000最快最快最高MLC2bit3000~10000较快较快中等TLC3bit1000~3000一般一般较低QLC4bit500~1000较慢较慢最低SD NAND Flash产品常见的是SLC或者pSLC模式把MLC/TLC颗粒当成SLC用这类产品主打高可靠性和长寿命在工业控制、车载电子、医疗设备上用得比较多。也有部分SD NAND使用TLC颗粒主打性价比适合消费类、对寿命要求不那么极端的场景。这里有个细节值得注意即使标称TLC的SD NAND很多厂商内部也会开启伪SLCpSLC模式将每个单元实际只存1bit。这样一来可靠性获得显著提升代价是实际可用容量变低。所以你在规格书上看到某个SD NAND标称2GB但实际上内部用的是4GB容量的TLC颗粒再用pSLC模式跑这种情况并不少见。测试时如果发现实际容量比标称值略高或者SPI/ID指令读出的内部die容量比实际可用容量大也不用太意外。1.3 读、写、擦三种基本操作和它们的关系NAND Flash有三种最核心的操作读Read、写Program、擦除Erase。这个程序设计和电脑上普通文件操作不一样它有几个硬性规则。第一写入之前必须先擦除。NAND Flash的存储单元初始状态是全部为1即0xFF写入操作只能把1变成0不能直接把0变成1。所以要把一个存储区域从0状态改回1状态必须要执行擦除操作。普通硬盘、U盘不用你操心这些细节但NAND Flash不行这是物理特性决定的。第二读和写的最小单位是Page页擦除的最小单位是Block块。一个Block通常包含多个Page比如一个Block有64个Page或128个Page每个Page大小常见的是4KB、8KB或16KB。这意味着你不能只擦除某个Page要擦就必须整个Block一起擦。第三由于写前先擦这个限制当你想要修改NAND Flash里已有的一部分数据时控制器必须把整个Block里的有效数据先搬移到新位置再把整个Block擦掉然后才能写入新数据。这个机制叫垃圾回收Garbage CollectionGC它会带来额外的写放大Write Amplification也就是实际物理写入的量比逻辑写入的量更大。理解了这些底层规则再回头看SD NAND Flash测试中遇到的现象就清晰多了为什么一个新的盘第一次写速度很快写满之后继续写反而变慢因为后台在做垃圾回收把数据搬来搬去。为什么随机小块写入比顺序大块写入慢得多因为小块写入更容易触发读-改-写和垃圾回收。为什么频繁掉电可能导致文件系统损坏因为GC和映射表更新过程被突然中断部分数据来不及落盘。这里补充一个我在测试中经常注意的点为了减少垃圾回收造成的性能抖动很多控制器会在空闲时间主动做后台GC。但测试过程中如果连续满负载写入没有给主控留出空闲时间就很容易触发性能跌落。所以做SD NAND性能测试时建议顺序写、随机写、空闲暂停、再续写这几类场景都要覆盖才能还原真实使用场景。1.4 寿命损耗和数据保持Flash逃不开的两个宿命NAND Flash的另一个特性是擦写次数有限。每擦一次浮栅晶体管氧化层就会被施加一次高电压逐渐累积损伤最终导致氧化层失效无法可靠存储电荷。这个擦写次数叫P/E CycleProgram/Erase Cycle就是前面表格里的寿命指标。在测试中我们通常不会真正把颗粒写到寿命耗尽再看结果那个时间成本太高了。更常用的方法是持续写入并校验观察写入/读取是否出现bit翻转错误Bit Flip检查ECC纠错消耗情况如果ECC纠错次数迅速上升说明颗粒状态不太健康用多片样品做短周期强化老化再根据P/E Cycle和老化时长线性外推寿命数据保持Data Retention是另一个容易被忽略的点。NAND Flash靠浮栅里的电荷状态来记忆数据而这些电荷会随着时间慢慢泄漏。温度越高、磨损次数越多电荷泄漏越快数据保持时间越短。车载和工业场景对数据保持要求很高通常要求85摄氏度下至少保存10年数据。这个指标很难在短时间内直接测出业界常用的做法是高温加速老化试验烤芯片一段时间等效模拟若干年的电荷泄漏再检查数据是否还能被正确读出来。SD NAND Flash由于内置了控制器它会在后台做数据刷新Data Refresh把快要出错的页重写到新位置从而延长数据保持时间。但刷新动作需要芯片能够正常上电工作。如果产品长期断电存放数据保持就完全依赖颗粒本身的物理特性了。2. SD NAND Flash产品形态与测试前认知2.1 SD NAND Flash到底是个什么东西SD NAND Flash全称是Self-Consistent SD NAND Flash Memory即内置了NAND Flash控制器和NAND Flash颗粒、对外提供标准SD接口的存储芯片。这样说可能不够直观。你把它理解成一块芯片封装里藏了一张微型TF卡就对了。它内部有一个控制芯片负责完成FTL闪存转换层Flash Translation Layer、坏块管理、磨损均衡、ECC纠错、垃圾回收等一系列复杂工作。用户端不需要写任何Flash驱动直接在电路板上挂SDIO接口或者通过SPI转SD卡模式就能像操作一张SD卡一样读写它。常见的封装形式有LGA-8、LGA-12、LGA-16等引脚少、尺寸小非常适合用在嵌入式主板、物联网模组、工业控制板卡上直接贴片生产省去了插拔卡座的机械结构。2.2 和eMMC、SPI NAND、TF卡的对比我经常被问到既然已经有这么多存储方案为什么还要单独选SD NAND Flash我把这个问题的对比表列出来看完就清楚了。对比维度SD NAND FlasheMMCSPI NAND FlashTF卡裸NANDRaw NAND对外接口SD协议SDIO/SPIeMMC协议8bit并行SPI接口SD协议可插拔并行NAND接口控制器内置内置无需主控支持内置无电路设计难度低中中低但有卡座高贴片集成度高可回流焊高BGA或eMMC封装高低可插拔高适合场景MCU/MPU小容量存储消费电子主力存储需要裸片降低成本消费类便携设备量产成本敏感方案可靠性特点内置坏块管理工业级选项多成熟可靠容量覆盖广依赖主机端FTL开发难度大插拔易接触不良开发难度最高从这个表格能看出SD NAND Flash的定位非常清晰给没有NAND控制器、不想做FTL开发的MCU/MPU主控提供一个开箱即用、贴片稳定、可靠性相对有保障的存储方案。2.3 测试前的物料与工具准备清单拿到SD NAND Flash样品后先别急着上机测试。我建议把测试环境搭好再动手否则结果很容易被环境因素污染出现误判。首先是读卡器选型。SD NAND Flash如果贴在你的转接板上一般会引出标准SD引脚或者microSD引脚你需要一个质量可靠的USB3.0读卡器。读卡器对测试结果影响有多大我实测过一个普通USB2.0读卡器和一款优质的USB3.0读卡器跑同一片SD NAND顺序读速度可能相差三倍以上。如果你拿低速读卡器测出来的数据去评估芯片真实性能结论就是错的。其次是测试软件。Windows平台我常用的有这几款CrystalDiskMark测顺序和随机读写性能结果直观可配置队列深度和块大小H2testw德国人写的容量真实性校验工具能有效识别扩容盘ATTO Disk Benchmark测不同块大小下的性能表现适合看小文件性能Flash Drive Tester / USB Flash Bench做长时间稳定性测试HD Tune看健康信息和坏道扫描部分功能对SD读卡器支持有限Linux平台则更灵活直接用dd、fio、md5sum、badblocks这些命令就能完成大部分测试。第三是确认产品规格书。这一步很多人会忽略但我觉得反而最重要。你必须先知道手里这片芯片标称的容量、接口速率等级、工作温度范围、最大读写电流才能设置合理的测试预期。比如一片标称Class 10速度等级的SD NAND你拿CrystalDiskMark去测顺序读得到25MB/s左右就正常别拿它跟UHS-I U3级别的跑分比。3. SD NAND Flash核心测试流程与实操3.1 基础识别与兼容性测试基础识别测试是上电后的第一件事主要验证芯片能不能被主机正常枚举和识别。在Windows上插上读卡器后先看我的电脑里是否出现了对应容量的盘符再右键属性看文件系统、容量、已用空间。这一步如果直接通过说明芯片至少能正常上电、初始化、响应SD协议命令。在Linux上我通常会这样操作# 查看是否识别到SD设备 dmesg | tail -20 # 查看块设备列表 lsblk # 查看分区表 fdisk -l /dev/sdX正常识别到的SD NAND会显示一个容量和你写入时的分区格式。比如标称8GB的芯片格式化后实际可用容量在7.2GB~7.6GB之间都是正常的。为什么会少一点因为容量换算单位不同厂商按1000进制标称文件系统按1024进制计算以及文件系统本身会占用部分元数据空间。兼容性测试建议至少覆盖以下几类主机环境不要只在自己手头那一台开发板上测带有原生SDIO接口的MCU/MPU比如STM32系列、i.MX系列通过SPI接口转SD模式的MCU电脑USB读卡器部分设备上的SDIO WiFi模组共存场景因为我见过不少案例芯片在某一个平台上一切正常换一个平台就识别失败大概率是主机端的初始化时序和芯片不完全匹配。SD NAND内部控制器对初始化命令有严格要求某些平台初始化时序不规范就容易挂。3.2 真实容量验证防扩容盘的关键手段SD NAND Flash市场鱼龙混杂尤其是非原厂渠道流通的芯片扩容风险是真实存在的。扩容的意思就是内部真实的NAND容量比标称小但控制器通过修改描述信息让主机误以为容量很大。当写入的数据量超过真实容量时数据就会悄悄丢失或者写入失败。识别扩容盘最可靠的方法不是看Windows显示多少容量而是做全容量写入校验。H2testw就是这个思路将盘格式化为FAT32或者exFAT按产品实际文件系统来打开H2testw选择目标盘符和测试模式写入校验点击Write Verify软件会把整个盘填满测试数据再逐个读出来比对测试完成后软件会报告可用空间大小和校验结果H2testw的校验原理其实很简单它生成一个带固定标记的数据文件将盘写满之后再从头到尾读出来比较。如果某个区域读出来和写进去的不一样说明该区域的存储单元无法可靠保存数据或者物理容量根本没有那么大。在Linux下可以用f3Fight Flash Fraud工具替代# 先写满 f3write /mnt/sd_card # 再读校验 f3read /mnt/sd_cardf3write生成的每个文件里都包含随机数据和对应校验和f3read逐一读取校验最后输出速度和校验结果。这里我要提醒一个重要细节做容量校验之前一定要确认你的读卡器支持该容量标准。比如一张标称64GB的SD NAND如果你的读卡器只支持SDHC最大32GB那么主机会把它识别成32GBH2testw也只能测到32GB这不代表芯片有问题。换一个支持SDXC的读卡器再验一次即可。3.3 读写性能测试怎么测、怎么解读性能测试的工具有很多但我建议不要只跑一个软件就下结论因为不同工具有不同的测试策略结果差异可能非常大。以CrystalDiskMark为例我常用的配置是测试次数5次取稳定值测试数据大小1GiB既能反映实际性能又不至于等待太久队列深度QD1和QD32各测一轮测试项目Seq Read/Write、4K Read/Write顺序读写主要反映了连续大数据场景下的性能比如视频录制、固件升级、日志批量导出。随机4K读写反映的是小文件、数据库、文件系统元数据这类场景的表现。Linux下用fio也能做类似测试举个例子# 顺序写测试 fio --nameseqwrite --filename/mnt/sd_card/testfile --rwwrite --bs1M --size512M --iodepth1 --direct1 # 随机4K写测试 fio --namerandwrite --filename/mnt/sd_card/testfile --rwrandwrite --bs4K --size256M --iodepth32 --direct1解读性能测试结果时有几点经验分享第一看顺序写数据时要注意是否存在明显的断崖式下降。正常SD NAND在长期连续写入时因为内部垃圾回收机制会在某个时间点出现短暂掉速这是控制器在做后台整理。但如果掉速幅度特别大、或者频繁出现说明控制器固件的GC策略可能有问题。第二4K随机写性能是小容量Flash的天然弱项。如果你发现4K随机写只有几百KB/s先别急着骂产品看看是不是文件系统格式和扇区对齐问题。SD NAND内部Page大小通常是16KB或者更多如果你用FAT32格式化且没有做扇区对齐4K随机写会非常慢。第三性能测试前最好对芯片做一次完整格式化确保文件系统结构干净。我习惯用SD卡官方工具或者Windows自带的格式化工具做一次默认格式化再开始测性能。3.4 数据完整性校验别以为写进去就万事大吉数据完整性校验和容量验证容易混为一谈但两者侧重不同。容量验证关注的是有没有那么多空间数据完整性校验关注的是写入的数据能不能被100%还原。最基础的做法是md5校验。把一批测试文件建议混合几个不同大小的文件包含小文件和大文件拷贝到SD NAND里计算每个文件的MD5值记录下来然后重新读出来再算一次MD5对比两次结果是否一致。Linux下可以一条命令完成# 写入后计算校验值 find /mnt/sd_card -type f -exec md5sum {} \; /tmp/checksums_before.txt # 卸载再重新挂载后再算一次 find /mnt/sd_card -type f -exec md5sum {} \; /tmp/checksums_after.txt # 对比 diff /tmp/checksums_before.txt /tmp/checksums_after.txt如果两次的MD5值完全一致说明至少在这次短时间存储中数据没有被篡改。更进一步的做法是长时间压力读写。我常用的一个压力测试方案是准备一批不同类型的数据文件文本文件、压缩包、图片、视频用脚本循环执行写入 - 校验 - 删除 - 再写入连续跑几个小时甚至过夜期间记录每次校验结果这个过程不仅能发现颗粒或者控制器是否存在偶发错误还能暴露发热降速、缓存策略失误等问题。在压力测试期间我建议每小时去看一次温度情况。如果芯片表面温度超过85摄氏度性能大概率会恶化数据出错概率也会增加。提示数据完整性校验一旦失败不要急着重启机器先保留现场信息。记录失败文件的路径、大小、写入时间看是否有规律。比如总是某个固定区域出错大概率是坏块管理有问题如果是随机分布可能是电源干扰或者颗粒本身不稳定。4. 可靠性测试与工业场景验证4.1 掉电安全测试绝不能跳过的一关SD NAND Flash大量用在工业控制、车载仪表、智能家电上这些场景最大的共同点是什么随时可能断电。如果设备正在写数据时突然断电会不会损坏文件系统会不会丢失已写入的数据掉电测试就是回答这些问题的。掉电测试的标准做法是让设备在多个不同时机被断电然后重新上电检查数据。具体步骤准备一个可远程控制的电源或者用串口继电器控制SD NAND供电通断编写循环脚本写入一批带编号的数据文件同步记录当前写入进度在写入期间随机触发断电重新上电后检查文件系统是否可挂载已写入文件是否完整日志是否最新反复执行上百次看是否有递增性损坏我在Linux下常用的自动化测试脚本逻辑大致如下# 循环写文件并掉电 while true; do dd if/dev/urandom of/mnt/sd_card/test_$(date %s).bin bs1M count64 # 写入完成后记录日志 echo write completed at $(date) /mnt/sd_card/test_log.txt sync done期间用继电器随机切断SD NAND的电源重新上电后检查文件系统完整性。掉电测试的判定标准要提前定好最理想的情况所有写入完成后掉电数据完全无损可接受的情况掉电瞬间正在写入的文件损坏但其他文件无损且文件系统能正常挂载不可接受的情况文件系统崩溃、分区表丢失、整个盘需要重新格式化需要注意SD NAND内部控制器虽然有一定的掉电保护机制但不同固件策略差异很大。有些控制器会把映射表频繁更新到NAND里掉电恢复能力强有些则主要靠缓存掉电瞬间数据容易丢。做掉电测试时重点关注反复掉电后芯片是否出现假死状态即重新上电没有任何响应必须做一次强制复位才能复活这种情况在嵌入式设备里非常致命。4.2 高低温测试与数据保持验证SD NAND Flash在工业场景下经常要面对极端温度。我之前遇到一个案例设备常温下工作完全正常但一到冬天户外环境零下20度就频繁丢数据最后排查出来就是芯片低温特性不过关控制器在低温下初始化时序异常。高低温测试需要用到温控箱或者至少是一个可控温度的恒温装置。测试项目一般包括高温存储测试85摄氏度下长时间断电存放之后回到常温检查数据是否保持低温存储测试零下40摄氏度断电存放回温后检查数据高温工作测试在85摄氏度环境下持续读写观察性能和稳定性低温工作测试在零下25摄氏度环境下持续读写观察能否正常初始化温度循环测试在高温和低温之间循环切换观察热胀冷缩是否导致焊点或封装异常我做高温存储测试时一般会特意做一个数据保持验证先给SD NAND写入一个已知数据文件并校验无误然后放入85摄氏度温箱断电存放24小时取出来散热到室温再上电脑校验MD5是否一致。如果这个测试都通过不了其他都不用谈了。注意高低温测试时读卡器或者转接板本身也可能出现不稳定测出来的异常未必来自芯片。建议把整个测试链路读卡器、线缆、转接板都放在温箱外只有芯片本体进温箱或者单独做一组纯读卡器温箱对照实验。4.3 寿命评估与坏块增长监控SD NAND Flash内部控制器承担了坏块管理任务用户端通常看不到坏块信息。但有些芯片厂商会开放SMART信息Self-Monitoring, Analysis and Reporting Technology通过特殊命令读取剩余寿命、擦写次数、重映射坏块数量等数据。能读到SMART信息是最好不过的事因为你可以直接量化评估芯片的寿命损耗速率记录初始擦写次数或者剩余寿命百分比每隔一段时间做一轮完整抹除重写每次记录擦写次数和坏块数量观察坏块增长率是否有突变如果芯片不开放SMART也可以用间接方式评估连续做高强度写擦循环每循环一定次数后做一次全盘数据完整校验看什么时候开始出现不可纠正的错误。这种方法比较费时间但对评估控制器固件质量很有价值。从实际测试数据来看正规的SLC SD NAND Flash通常在实际擦写次数达到2万次以前性能不会出现明显劣化坏块增长也会保持线性缓慢态势。如果某颗芯片在早期就出现大面积坏块跳增那基本可以判断颗粒来源或者控制器固件不靠谱。5. 常见问题与排查技巧实录5.1 写入大文件时卡死或者速度骤降这个问题我遇到得最多尤其是在所谓高性价比芯片上。现象是刚开始写入正常速度也能达到标称值但写了几百MB之后就突然掉速甚至写入长时间卡住不动。排查思路是这样的第一步排除主机端缓存因素。Windows写U盘有写缓存机制界面显示完成不一定真的写完。测试时应该右键设备选择安全删除硬件或者直接用sync命令确保数据落盘。第二步观察掉速发生的容量点。如果恰好是超过某个固定容量阈值比如512MB、1GB开始卡顿很可能内部缓存用完主控开始边写边做垃圾回收。这个属于控制器策略问题未必是故障。但如果掉速后长时间超过30秒无法恢复就要怀疑颗粒问题。第三步检查供电。小容量SD NAND本身功耗不大但读卡器供电质量不好、USB口供电不足或被其他大功率外设拖累都有可能导致写入异常。换一个供电更稳的USB口或者用带外部供电的读卡器复测。5.2 识别不到设备或者识别后容量为0这种情况通常不是芯片本身损坏而是接触或初始化类型问题。排查步骤检查转接板和读卡器之间接触是否良好SD NAND引脚小容易虚焊用酒精清洁SD NAND引脚和金手指排除氧化问题换一台电脑或者读卡器复测排除主机端兼容性如果芯片存在多个工作模式比如有SD模式也有SPI模式确认当前接线的模式选择引脚是否正确查看芯片规格书确认初始化时序要求。部分SD NAND需要主机端做上电延时直接快速上电可能导致芯片不响应还有一种情况是芯片内部固件损坏导致SD协议响应异常。如果是样品阶段遇到这个问题建议直接联系原厂FAE用原厂的量产工具尝试重新格式化或者重新烧录固件。5.3 文件系统反复损坏嵌入式设备上SD NAND文件系统反复损坏最常见的原因就是突然断电。虽然控制器做了掉电保护但文件系统层面比如FAT表、目录项依然可能在写入中途被断电命中。解决方向有三个第一优先选用嵌入式文件系统比如littlefs、spiffs它们针对掉电鲁棒性做了专门设计比通用FAT32更可靠。第二在应用层实现关键数据的双备份和校验机制。写过一条记录再写一条备份启动时校验主记录不行就切备份。第三如果只能用FAT32尽量用FAT表备份机制并定期用fsck检查文件系统健康状态。从我的经验来说SD NAND Flash内部控制器再厉害也解决不了文件系统层的问题主机端的软件设计还是要靠自己做可靠性增强。5.4 测出的速度和规格书差很远规格书上的速度一般是在理想测试条件下测出来的比如高性能读卡器、大块连续传输、高队列深度。实际产品在MCU平台上跑出来的速度往往只有标称的50%~70%这种情况不要急着判芯片不合格先对照测试条件逐项排查。常见原因包括读卡器接口版本不对USB2.0读卡器测USB3.0芯片MCU的SDIO接口没有开启4bit模式只用了1bit模式速度直接差4倍SPI模式本身吞吐率就低文件系统碎片化严重导致顺序读写退化成半随机访问芯片工作在工业级温度范围边缘主控降频保护把这些因素都排除一遍再对比规格书才有意义。5.5 自动化测试脚本的一次实操记录最后分享一个我最近在用的自动化测试思路。手头有几十片SD NAND样品要做批量测试靠手工一块一块插拔读卡器效率太低我就做了一个小规模的自动化测试框架用USB Hub连接多个读卡器每个读卡器插一片SD NAND写一个bash脚本循环检测每个挂载点对应的设备速率等级和容量对每片芯片依次执行容量校验、顺序写读、随机4K、掉电恢复测试把结果输出成CSV表格汇总查看核心逻辑相当简单#!/bin/bash # 简易批量测试脚本片段 for dev in /dev/sd?; do capacity$(blockdev --getsize64 $dev) # 顺序写测试 dd if/dev/zero of$dev bs1M count1024 convfsync 21 | tail -1 # 读测试 dd if$dev of/dev/null bs1M count1024 21 | tail -1 # 记录结果 echo $dev $capacity result_$(date %Y%m%d).csv done这套方法不见得多高级但胜在省人力、可复现、结果留痕。做了一大轮测试下来哪个批次、哪颗芯片、测了什么内容、结果如何全都清清楚楚比一个人在电脑前手工点一整天可强多了。最后再分享一个小经验SD NAND Flash这类产品的测试最容易出问题的往往不是芯片本身而是测试环境的不可控因素。读卡器、转接板、供电质量、测试软件参数、甚至电脑后台驻留程序都可能干扰测试结果。所以我建议你搭好测试环境后先用一片你确认没问题的样片跑通整个流程再开始批量测试。流程没验证之前省掉这一步后面返工的成本只会更高。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑