要说这两年可穿戴设备和低功耗物联网圈子里最不缺的就是各种存储方案的宣传。但前阵子Winbond华邦推出的那颗1Gb QspiNAND还是让我多看了几眼。原因很简单这颗料卡的位置太特殊了——它正好落在NOR Flash和传统大容量NAND之间一个让不少硬件工程师纠结了很久的空白地带。我这几年做的几款低功耗数据记录设备和穿戴类原型都在这个存储选型上反复折腾过。NOR吧容量顶到512Mb就有点肉疼价格也开始不友好上并口NAND或者eMMC吧对一颗MCU主控来说又有点用力过猛封装、引脚、初始化流程全都变复杂。所以当看到Winbond用QSPI接口把1Gb NAND做出来的时候我第一反应是这个方向终于有正经大厂接盘了。这篇文章就围绕这颗料聊聊我看到的细节、适合的场景以及如果你也想在项目里用它从选型到落地可能会踩到哪些坑。1. 可穿戴与低功耗物联网的存储困局1.1 小容量NOR与大容量NAND之间的尴尬空档很多做消费电子或者传感器的朋友可能都有这种体感一颗设备里真正需要存的东西其实没有想象中那么多但也绝对不少。以我做过的一个便携式环境监测记录仪为例它每秒采样一组温湿度加气压数据附带简单的时间戳一天下来大概产生1.5MB左右的数据。如果用户要求本地保留30天的历史记录那就要约45MB的存储空间按可用容量换算成Nor Flash至少得512Mb起步这还不够塞日志和固件备份。NOR Flash的好处是接口简单、随机读取快、启动友好但到了大容量这个档位单位成本会明显上升而且写入速度偏慢擦除块又大频繁写日志的时候性能捉襟见肘。反过来看传统的并行NAND或者eMMC容量确实够大性能也强但对于大部分采用单芯片MCU或者低功耗SoC的方案来说引出8位甚至16位并行数据线实在不现实焊盘密度、PCB走线、驱动复杂度都会跟着涨。这个中间地带以前不是没人做但方案比较零散。有拿SPI NOR硬扛的有硬上SD卡座子的还有用外部串行SRAM加电池做临时缓存的。Winbond这颗1Gb QspiNAND本质上就是用大家最熟悉的QSPI接口把NAND的大容量和价格优势带进了原本属于NOR的领地。对做可穿戴设备、智能门锁、行车记录仪、工业传感器记录器的工程师来说多了一个非常务实的中间选项。1.2 为什么QSPI接口在这个领域仍然吃香有人可能会问现在SPI NOR慢慢被淘汰QSPI是不是也老掉牙了实际上恰恰相反。QSPIQuad SPI或者说标准SPI及其扩展模式在今天的中低端嵌入式系统里依然是绝对主流。原因无非这几点引脚少普遍只需6根线CLK、CS、DI、DO、WP、HOLDMCU几乎都有硬件外设支持PCB布局压力小走线随便拉不像并行总线那样讲究等长驱动简单很多RTOS和MCU SDK自带标准MTD驱动移植成本很低。而QspiNAND这个产品形态等于把NAND控制器的活儿部分挪到了芯片内部。芯片本身通过标准QSPI协议跟主控通信主控不需要了解NAND内部那些复杂的命令序列、块管理、ECC校验细节只要像操作一块大号的NOR一样调用读写擦除接口就行。对于那些不想升级到eMMC、又嫌NOR贵的团队这是一个很舒服的折中。从我实际调试过的QspiNAND芯片来看这类器件的页大小通常是2KB块大小128KB或256KB容量到1Gb之后整体结构和普通并行NAND基本一致。不同之处在于厂商在芯片内部做了不少逻辑转换将并行NAND那套物理寻址和状态查询机制封装成了更友好的SPI命令集。Winbond这颗1Gb QspiNAND应该是延续了自家W25N系列的设计思路接口兼容性好很多老驱动改改参数就能用。2. 1Gb QspiNAND的核心细节解析2.1 容量、封装与电气参数Winbond这颗1Gb QspiNAND编号上应该还是归在W25N系列里延续这个家族一贯的命名习惯。1Gb意味着裸容量是128MB但实际用户可用容量会因为坏块管理、ECC冗余等原因打一点折扣。对于前面说的环境记录仪场景128MB足够存下两三个月的日志外加好几份固件备份这个空间余量对产品设计来说非常舒服。封装方面这类QspiNAND通用性很强常见的有8引脚WSON、16引脚SOP有些还会出KGD或者晶圆形式方便模组厂做堆叠封装。WSON封装在可穿戴设备里很受欢迎因为体积小、热阻低手工焊接虽然稍微麻烦一点但产线回流焊良率很稳定。我建议做穿戴设备的团队优先选WSON8封装它在PCB上占的面积大约只有SOP8的60%对于空间抠到毫米级的智能手环主板来说这个差别很关键。电气参数上QspiNAND的工作电压通常是1.8V或3.3VWinbond这颗料本身应该支持双电压版本。低功耗设备经常要跟一颗1.8V的MCU协同工作如果能直接对接省去电平转换芯片整体待机功耗能下降不少。我之前有一个项目因为NOR是3.3V的被迫加了一颗电平转换器待机电流白白多了好几个微安。对于主打长待机的穿戴设备来说这种“看似微不足道”的电流最后都会变成电池续航表上的硬伤。2.2 低功耗设计的功夫在细节里说到低功耗很多人的第一反应是看数据手册里的待机电流和掉电模式。但真正做低功耗系统久了就知道存储芯片的功耗大头往往不在静态电流而在动态读写和状态切换的瞬态功耗。QspiNAND如果支持深度掉电模式Deep Power Down设计者可以把它当成一个外设开关来用平时让MCU休眠也让Flash睡下去只有需要写日志或者OTA升级的时候才拉起来。我查过这颗料公开资料里提到的特性它应该保留了W25N系列一贯的低功耗设计逻辑。例如页编程电流和擦除电流都有明确的上限待机电流在微安级深度掉电模式下还能进一步压到更低。对于一颗要连续跑几年的传感器节点来说这个待机指标很关键。不过这里要提醒大家芯片标称的待机电流通常是在室温、稳定电源下测出来的如果你的系统电源纹波大或者片选引脚悬空没处理实际待机电流可能会比标称值高出不少。另外一个细节是QspiNAND因为是NAND结构写操作前往往需要先擦除。擦除操作是所有操作里功耗最大的瞬间如果电池供电能力弱可能会把系统电压瞬间拉低导致MCU复位或者数据写坏。我在自己的设计里通常会在主供电路上加一个小容量的钽电容或者超级电容专门用来吸收擦除瞬间的电流尖峰这个方法成本很低但效果非常明显。2.3 可靠性设计ECC、坏块管理与寿命NAND和NOR最大的不同在于NAND天生就有坏块和位翻转的问题。NOR Flash可以做到按字节随机读写基本不需要复杂的坏块管理NAND则必须面对出厂坏块、使用中新增坏块、以及数据保持期间可能出现的位翻转。Winbond的QspiNAND一般会内置一部分ECC能力。以W25N系列为例芯片内部支持1-bit ECC或者硬件ECC校验配合主机端的坏块管理策略能够显著降低数据损坏概率。对于1Gb这颗料我建议在软件层面做到两点一是建立坏块表在格式化或者批量写入前扫描一遍全片标记出厂坏块二是在写入路径上做CRC或软件ECC校验双保险。虽然芯片内置了ECC但主控端如果完全不关心读回的数据是否正确万一遇到多bit翻转数据依然会出错。寿命方面1Gb QspiNAND的擦写次数通常在10万次左右这个数字在工业级和消费级之间有差异。对于频繁写入日志的设备来说10万次擦写意味着如果你每小时擦写一次大概能用11年听起来是够的。但真正做产品时不能这么算术因为NAND的擦写损耗不是均匀的如果你的文件系统把某些块当作频繁更新的元数据区这些块的寿命会远早于其他块耗尽。这个问题我在后文的实操部分会详细说这里先提个醒file system层一定要有磨损均衡机制不然标称寿命再高也是纸上谈兵。3. 从选型到落地的完整实操路径3.1 第一步评估存储需求不要盲目上容量选型之前我习惯先列一张存储需求表把MCU固件镜像大小、设备配置项、用户数据日志大小、OTA暂存区、以及文件系统元数据开销都写清楚。特别是做可穿戴设备时OTA升级往往是存储容量的最大消耗者因为你需要同时保留当前固件和新固件两个副本防止升级中途断电变砖。用我之前做的智能手环来算一笔账固件镜像约512KB当前运行版本加上OTA下载的暂存版本就是1MB设备配置和数据日志预留8MB文件系统元数据、坏块替换区和磨损均衡预留区再占2MB最后还要留出约25%的可用空间余量避免文件系统碎片化后无空间可用。这么一算至少需要14MB以上的用户可用空间对应的大概是128Mb到256Mb。如果你的固件大一点或者日志保留时间长一点马上就会逼近512Mb甚至更高。到了这个需求区间1Gb QspiNAND就非常合理了它既不会像512Mb NOR那样价格离谱又不像上eMMC那样要动整个硬件架构。这里还要多说一句做产品千万别只看“当前需求”。一款设备从立项到量产往往会有几次OTA包体积膨胀、日志字段加多的迭代。如果一开始容量选得太狠后面改版要动硬件那成本就大了。稍微留出30%到50%的容量余量是我个人的惯例。3.2 第二步驱动层适配要点拿到一颗新的QspiNAND第一步自然是跑通基本读写。以STM32系列MCU为例标准做法是利用MCU自带的QuadSPI外设配合STM32CubeMX生成的驱动框架把Flash作为一个内存映射设备来访问。Winbond的QspiNAND在QSPI协议栈上可以复用W25Q系列NOR的很多操作基础但NAND特有的命令比如Page Program、Block Erase、Read Status等需要单独适配。我习惯把驱动分为三层最底层是硬件QSPI读写函数完成最基本的命令收发中间层是NAND命令封装比如读ID、读状态、页读、页写、块擦除最上层是基于中间层实现的MTD设备驱动交给文件系统或者直接按块读写使用。三层分离的好处是以后换不同品牌的QspiNAND只需要改中间层的命令映射其他两层基本不用动。调试过程中有一个点需要特别留意QspiNAND的页大小和块大小。Winbond这颗1Gb QspiNAND大概率是2KB页、128KB块和常见的并行NAND不完全一样。你的驱动、文件系统、地址换算逻辑都必须基于实际参数来不能用0.5KB页的旧习惯。很多刚接触NAND的工程师会在这里翻车明明写进去的数据读出来却是乱的一查发现是页地址计算错位。3.3 第三步文件系统选型与分区设计对于小容量NAND文件系统的选择很有讲究。如果平台是Linux那标准选择自然是UBIFS它专为NAND设计自带磨损均衡、坏块管理和掉电恢复。但如果你的设备是RTOS或者裸机环境就得自己实现一套简单可靠的记录策略或者用现成的小型文件系统。我在RTOS项目里常用的是一个极简方案把Flash分成两个逻辑区。一个区存放系统参数每次更新就写到下一个空闲页并用固定的magic number标记有效数据另一个区存放日志数据采用环形写入方式每页只追加写写满一个块再擦除。这种方式不需要完整的文件系统逻辑简单崩溃恢复也容易而且天然实现了基础的磨损均衡。缺点是空间利用率低但在1Gb这种容量下浪费一点空间换可靠性完全值得。如果你确实想用完整文件系统LittleFS是个不错的选择它在小容量Flash上表现优异支持掉电保护。不过LittleFS标准版是针对NOR或者EEPROM设计的用在NAND上会有一点问题因为NAND的擦除粒度是块且写入只能顺序写页。后来社区有一些针对NAND优化的分支你可以找找看。总体我的建议是能不用复杂文件系统就不用当你在写嵌入式代码时简单直接的方案往往最抗造。4. 常见问题与排查技巧实录4.1 擦写次数耗尽的处理策略QspiNAND用久了总会遇到块擦写失败或者数据校验失败的情况。很多时候不是芯片坏了而是某个块的寿命到头了。如果你在主控端实现了一套坏块管理机制就有机会在写失败或者读校验失败时把这个块标记为坏块然后从备用块池里分配一个新块。我的做法是每次擦除操作后读回状态寄存器如果出现擦除失败标志立刻将这个块的地址加入坏块表并对外报“该逻辑块写入失败”让上层文件系统重新映射。每次块擦除成功之后我会顺手记录一下这个块所在分区的擦除次数当某个区块的平均擦除次数明显高于其他区时就触发一次数据搬迁把热点数据挪到冷区来均衡损耗。这个策略听起来简单但实际做的时候有一个容易被忽视的坑坏块表本身也要存储在Flash里如果它正好存储在一个频繁更新的坏块上整个系统就“失忆”了。解决办法是把坏块表保存两份分别放在Flash的头部和尾部每次更新交替写入并且每份表都带CRC校验。万一其中一份损坏另一份还能救回来。4.2 掉电保护的设计建议低功耗设备最容易出现的数据事故就是写日志写到一半突然没电。NAND页编程过程中掉电轻则当前页数据无效重则可能影响同一个块的其他页数据。所以掉电保护是这类方案里无论如何都躲不开的问题。我在硬件层面会加一个电源监测电路一旦检测到系统电压跌落到阈值MCU立刻进入紧急处理流程停止一切任务、把正在写的日志缓存到RAM里、等待电源稳定后重新上电再把缓存中的数据补写。这个过程要求在电压真正跌到MCU无法工作之前完成所以储能电容要选得足够大我一般会按照“能撑10ms”的标准来算容量。软件层面也要配合每次写日志不要直接写满一页而是先把数据组织到RAM缓冲区凑满一页或者超过512字节连续数据后才一次性写入Flash。如果掉电发生在写入过程中下一次上电初始化时先进行全片扫描检查所有日志页的CRC发现无效页就跳过并把可恢复的数据重新组织到空闲区。这套方案的代价是多占一点RAM和启动扫描时间但能极大降低日志丢失的概率。4.3 与NOR并存时的启动流程划分有些设备为了兼顾启动速度和数据容量会同时放一颗小容量NOR和一颗大容量QspiNAND。NOR负责存放引导程序、固件头部和关键配置QspiNAND负责放文件系统、日志和OTA包。这种组合在可穿戴和物联网关里都很常见。这里容易出现的问题是启动流程规划不当。MCU上电后首先要从NOR里加载引导程序然后引导程序去QspiNAND里读取固件镜像或者OTA包再加载到RAM运行。这个过程中QspiNAND的初始化代码必须放在NOR引导阶段而不是主应用阶段。否则一旦固件升级过程中出现意外主应用崩了引导程序又不会初始化NAND设备就真变砖了。我的建议是把整个启动流程画成状态机引导程序从NOR读配置决定是从NAND加载固件A还是固件B或者进入恢复模式等待串口/OTA命令。QspiNAND驱动要精简到能在引导阶段运行并且要处理坏块表读取失败、NAND无法识别等异常情况。这个设计做好了设备基本就能实现“永远不会变砖”的自我恢复能力。另外还有一点我把OTA升级的暂存区固定放在QspiNAND末尾的独立分区里跟文件系统分区隔离开。下载新固件包时先写入暂存区校验通过后复制到主备份区最后更新bootloader里的启动标志。整个升级过程中即使中途断电旧的固件仍然完整保留在另一个区域下次上电还能正常启动。这套思路在多个项目里验证下来非常稳。5. 选型之外的几个现实提醒5.1 供货与兼容性要考虑的坑再好的芯片如果供货不稳或者交期太长产品照样难产。做量产前我一定会确认三件事这颗料的现货渠道、交期周期、以及是否有第二供应商备胎。Winbond在NOR和SPI NAND市场占有率都不低这颗1Gb QspiNAND如果按照W25N系列的老路走兼容型号应该不少比如其他大厂也有类似接口和容量的产品驱动层改动理论上不会太大。但别高兴太早不同品牌的QspiNAND虽然命令集大同小异但状态寄存器的位定义、坏块的标记方式、ECC能力可能差很多。所以我在选型阶段就建议做一个兼容层抽象把Flash驱动里所有跟具体芯片相关的参数都抽出来放到一个配置文件里。这样换料的时候只需要改配置文件和少量底层命令映射应用层代码一行都不用动。这个习惯帮我避免过好几次备料短缺的麻烦。5.2 成本与功耗的权衡思路有些朋友可能会问都到128MB容量了为什么不直接上eMMC确实eMMC的容量更大、接口标准化程度更高、驱动也成熟。但我个人觉得在很多低功耗场景里eMMC有两个问题绕不开一是eMMC的初始化流程比较重上电时要走完整的MMC协议协商功耗启动瞬间不友好二是eMMC封装的引脚密度高对PCB工艺要求也更高两层板基本很难走顺。相比之下QspiNAND的启动功耗更低引脚更少可以用简单的两层板搞定。如果你的主控本身支持QSPI外设基本上不用增加额外BOM就能接上。在成本敏感、功耗敏感、又不追求超大容量的穿戴和IoT场景里这个方案是比eMMC更务实的存在。当然如果你的设备需要高清视频录制、本地AI模型存储或者动辄几个GB的媒体文件那QspiNAND的128MB确实不够看还是老老实实上eMMC或者UFS。选型这件事从来没有最好的芯片只有最适合自己场景的芯片。6. 实测与上手体验记录6.1 实际读写性能参考我在一颗主频170MHz的Cortex-M4 MCU上测过类似的QspiNAND方案QSPI时钟跑到80MHz理论带宽大概40MB/s。实际连续读速度能到3MB/s左右页写入速度大概0.8MB/s块擦除速度约0.5MB/s。这些数字看起来不算亮眼但对于日志记录和OTA场景完全够用。你要真拿它跟eMMC跑顺序读比4K随机读写那是找错对象了。如果你在项目里遇到写入速度不达标的情况我建议先检查QSPI时序配置是否最优然后确认驱动是否在每次读写之间做了不必要的状态轮询。很多驱动为了省事每写一页都去轮询状态寄存器导致颗粒间的命令间隔拉得好长。正确的做法是开启QSPI外设的中断或者DMA写命令发出后让CPU去干别的事等DMA完成中断再回来检查状态。我优化过一次驱动同样的硬件写入吞吐直接翻了快一倍。6.2 与常见MCU平台的搭配建议如果你用STM32选带OctoSPI外设的新型号会更从容因为它的命令队列和自动轮询功能对NAND操作非常友好。如果是ESP32、GD32这类常用平台它们的QSPI控制器相对基础要多花点时间在协议状态机上但也不是不能跑。RT1052、i.MX RT系列就更简单了这些平台自带FlexSPI映射访问性能很强跑QspiNAND毫无压力。最后提醒一句无论用哪个平台上电时务必先读一次JEDEC ID通常通过0x9F命令确认当前连接的Flash型号和预期一致。这个动作能帮你提前发现贴片贴错料、焊接虚焊、SPI走线干扰等低级错误。别问我怎么知道的在产线上栽过一次跟头之后这已经变成我的默认流程了。6.3 一个小结式的心得我个人在实际调试中的体会是Winbond这颗1Gb QspiNAND最值得关注的价值不在于某几项参数有多亮眼而在于它把大容量存储、低功耗、简单接口这三个需求平衡到了一个实用点上。它不会让普通消费产品突然拥有服务器级的海量存储但它在可穿戴设备和电池供电的IoT终端里刚好能解决那个“多一杯装不下少一杯不够用”的老大难问题。最后再分享一个小技巧如果你在设计初期拿不准容量和接口方案可以先用一颗开发板把整个软件框架写起来在驱动层预留好容量和地址换算参数等实际硬件打样好了再烧录验证。等软件稳定了再回归到硬件选型上心里就有底得多。存储方案这东西最怕的不是选错而是不敢选、拖着不决策。