做穿戴设备的朋友应该都有这种感觉选一颗存储芯片比选主控还纠结。内部Flash只有那么几MB固件一膨胀、日志一累积、OTA包一下来马上见底。翻来覆去就是NOR、SD卡、eMMC三选一各有各的憋屈。看到Winbond华邦放出1Gb QspiNAND的消息我第一反应是这个容量和接口的组合正好卡在可穿戴和低功耗IoT设备最缺的那一档。这颗料到底解决了什么问题和老的NOR Flash方案差在哪量产时有哪些坑要提前填我用一篇完整的选型笔记讲清楚。1. 可穿戴与低功耗IoT的存储困局一颗料卡住整个产品1.1 小设备为什么比手机更难选存储手机选存储很简单上UFS、上eMMC容量越大越好在主控和PCB都扛得住。但可穿戴设备完全不是这个逻辑。手环、智能手表、血氧仪、温湿度传感器、资产追踪标签这些产品的PCB可能只有指甲盖大小电池容量几百毫安时主控往往是Cortex-M系列或者低端SoC根本没有SD/MMC控制器也不方便外挂eMMC。更麻烦的是小设备的固件和资源需求却在肉眼可见地膨胀。一个带图形界面的彩屏手环字库、图标资源、蓝牙协议栈、传感器算法库随随便便就吃掉几MB如果再叠加一个轻量级AI模型做心率或睡眠分析那几十MB也不够塞。早期那种内部Flash 512KB就够用的时代已经过去了。这时候就出现了一个尴尬的断层小容量NOR便宜但超过16MB、32MB之后价格直线上升大容量eMMC性能和容量都够但接口重、初始化慢、对低端主控不友好SD卡体积大、连接器不可靠、供电要求高放在穿戴设备里就是找罪受。这个断层正好是SPI接口的NAND Flash可以填补的位置。1.2 从能跑就行到能OTA升级的需求演进前几年大家做IoT设备存储方案很简单程序放内部Flash数据能不存就不存实在要存就外挂一颗几Mbit的EEPROM。但现在用户对设备的要求变了存储需求也跟着涨离线数据采集环境监测设备每隔几秒就要存一条带时间戳的记录一天能产生几十到几百KB数据跨越多天就需要MB级空间。固件OTA升级哪怕固件只有2MB升级时为了稳妥往往需要下载完整镜像到独立分区预留空间就要翻倍。日志与故障诊断设备出问题后厂商希望拿到运行日志这需要循环覆盖的日志分区。资源热更新彩屏设备的主题、字体、语音包经常需要从云端下发替换不能每次都用整包固件带着走。这些需求叠加在一起内部Flash根本扛不住。另一个关键是OTA策略现在主流做法是A/B分区或者下载区解压区。无论哪种设备端都需要一块比固件本体大得多的存储空间。我见过不少项目因为存储容量不够OTA只能设计成先擦后写一旦升级中途掉电或网络异常设备直接变砖。这是典型的省小钱花大钱。1.3 现有方案的尴尬不是不能用是别扭先说NOR Flash。Winbond的W25Q系列在行业里用得非常广8MB、16MB、32MB的SPI NOR在MCU项目里几乎是标配。NOR的优势是支持XIP片上执行、随机读取快、可靠性高坏块管理都省了。但到64MB以上NOR的价格就很不好看而且大容量NOR的写入速度并不快反复擦写寿命也有限。对要大容量存数据的需求NOR属于能用但性价比差。再说eMMC。它自带FTL闪存转换层有坏块管理、磨损均衡容量从4GB起步对应用层非常友好。但低功耗可穿戴设备的主控大概率没有eMMC控制器要用SDIO/MMC接口就得额外加芯片或选更贵的主控功耗和体积也不划算。eMMC的启动流程对MCU项目来说也太重。SD卡就更不用说了连接器电平转换供电管理折腾半天还不如直接在PCB上焊一颗Flash省心。所以市场其实一直缺一类产品容量在64MB到256MB之间、接口轻量、功耗低、价格适中开发难度又不会像裸调NAND那么高。Winbond的1Gb QspiNAND瞄的正是这个档位。2. QspiNAND到底是什么接口、颗粒结构和我为什么先看它2.1 名字拆解QSPI是接口NAND是本质先把这个名字拆开看。NAND是闪存颗粒的存储结构特点是按页写入、按块擦除、存在坏块、需要ECC纠错编码QSPI是Quad SPI的缩写也就是四线串行接口。合起来就是用四线SPI接口访问的NAND Flash注意它还是Flash不是带控制器的存储卡。很多人一看到NAND就发怵觉得要处理坏块、要算ECC、要搞磨损均衡太复杂。但QspiNAND这类产品的思路是把一部分管理功能尽量在颗粒内部做掉或者用更成熟的软件方案兜底把接口复杂度控制在MCU能接受的范围。这和直接贴一片BGA封装的大容量NAND完全不是一个量级的工作量。Winbond做QSPI接口存储是有积累的W25Q系列的NOR铺货量非常大生态很成熟。现在推出QspiNAND可以复用很多QSPI控制器的已有资源主控侧的命令格式和传输时序跟NOR有不少相似的地方这对嵌入式工程师来说学习成本会低很多。2.2 内部结构从Die到Page/Block把1Gb拆开看NAND的基本组织结构是一片DieDie里分多个PlanePlane里分多个BlockBlock里分多个Page。Page是读写的最小单位Block是擦除的最小单位。以常见的SPI NAND为例Page大小一般是2KB或4KBBlock通常包含64到128个Page。用1Gb来算一笔账1Gb等于128MB按4KB Page计算总共有32768个Page如果按每个Block 128个Page算就有256个Block。按2KB Page、64Page/Block算就是65536个Page、1024个Block。这个数量级是什么意思意味着单个Block坏了对整个容量影响非常小坏块替换策略不需要太复杂。但要注意NAND的Page不是随机访问的只能按顺序写入。比如一个4KB Page已经写了部分数据想再往同一个Page剩余位置塞数据多数颗粒不支持必须先擦除整个Block再重写。这在文件系统或FTL设计上是个关键约束。很多从NOR转过来的人在这里栽过跟头以为像操作EEPROM一样读改写同一个地址就行结果读出来全是FF写也写不进去。2.3 为什么不用NOR硬扛容量和写入速度的物理差距NOR和NAND的差异不是简单的容量不同而是底层存储单元的电气特性不同。NOR单元的读取速度快、支持随机访问但写入和擦除慢NAND单元的写入密度高、擦写快但读取速度相对NOR要慢一些而且不支持XIP。在可穿戴设备里代码执行通常放在内部Flash或外挂NOR里因为MCU可以XIP直接从NOR取指省掉先拷贝到RAM再执行这一步。但资源文件、日志、OTA包这类数据不需要XIP它们更适合放到NAND里NAND的顺序读写吞吐能力反而比NOR强大块数据搬运效率更高。所以一个很常见的合理架构是小容量NOR放Bootloader和关键代码QspiNAND放文件系统、日志、OTA镜像、资源包。NOR管代码执行NAND管数据存储各干各的活。不要指望用一颗QspiNAND替代NOR也不要指望NOR去承担大容量数据存储物理特性决定了这种分工。3. 1Gb容量能装什么从固件、日志到OTA镜像的容量账3.1 先把128MB拆开看1Gb听着不大但在可穿戴和IoT设备里已经不算小了。128MB做分区规划可以覆盖很多典型场景。我按一个带彩屏、有蓝牙、支持OTA的手环产品做示意分区用途容量说明Bootloader0.5MB启动入口尽量不更新固件A当前运行8MB包含RTOS、GUI、协议栈、算法固件BOTA备份8MBA/B升级用的双备份资源区32MB字库、图标、主题、语音日志区16MB循环覆盖的系统日志用户数据区32MB运动记录、健康数据、配置OTA下载缓冲16MB临时放下载的升级包文件系统元数据坏块替换区12.5MB预留损耗和FTL开销总占用125MB接近128MB这只是个示例布局实际产品未必需要A/B分区但可以看到128MB做资源热更新、日志回传和OTA冗余是足够从容的。如果只想要一块能塞固件日志的存储那64MB甚至32MB也够用但1Gb给我们留了余量。3.2 OTA升级容量怎么算OTA是最容易忽略容量的场景我来详细算一笔账。假设当前固件镜像为10MB云端下发的是压缩包假设压缩后8MB。如果做A/B分区需要两个固件分区各10MB加上下载缓冲8MB至少要28MB。如果只做单分区最简单的做法是先把压缩包下载到下载区校验成功后擦除固件区再把压缩包解压写入固件区。那也需要下载区8MB固件区10MB但中间擦除和写入过程中设备不能断电否则现场变砖。更稳妥的单分区做法是下载区8MB再加一个解压暂存区10MB解压并校验完整后再一次性写入固件区。这样中间任何一步失败固件区还是旧的可以回滚。这个方案需要28MB。和A/B方案所需的28MB其实很接近只是少一份运行固件的空间占用。128MB的QspiNAND做上面的OTA方案完全没压力。如果固件膨胀到20MB甚至30MB128MB依然够用。这也是我推荐把1Gb作为甜点容量的原因它既能覆盖今天的固件规模也留了未来两三个大版本的空间。3.3 日志和采集数据怎么攒对物联网数据采集场景来说存储容量直接决定了采集频率-回传周期这条曲线。拿一个环境监测设备举例传感器每10秒存一条32字节的记录一天产生约276KB。如果回传周期是一周一周就是1.93MB如果回传周期是一个月约8.3MB。如果设备本地缓冲是64MB可以存约7个月的周报数据或者2个月的日报数据这个量级对很多LoRa、NB-IoT设备来说非常舒服因为可以降低回传频率、省电、省流量。如果设备本地缓冲只有4MB那就得频繁回传还要在弱网情况下反复重传功耗和流量成本反而更高。但要注意NAND适合顺序写入日志系统最好设计成追加写模式不要频繁随机改写小区域否则磨损均衡做不好某些Block会提前报废。4. 功耗、抗掉电和寿命这颗料真正要过的三道坎4.1 低功耗场景下的电流怎么看QspiNAND的静态电流一般能做到很低但真正的功耗大头在读和写时。以主流SPI NAND颗粒为参考读操作电流可能在几十毫安级别写/擦除电流可能到几十甚至上百毫安。这个数字看起来吓人但实际运行中是脉冲式的持续时间短平均功耗完全可以控制。在低功耗系统里关键是平时让它睡眠用时快速唤醒。选择QspiNAND时要关注几个参数待机电流、深度掉电电流、从掉电模式唤醒的时间。如果主控经常进入sleepFlash也应该进入standby或deep power-down而不是一直保持active状态。有些颗粒支持深掉电模式电流可以降到个位数微安对年抛型纽扣电池设备很关键。另外要注意QSPI接口本身在高速翻转时也会有动态功耗。如果设备大多数时间处于睡眠状态偶尔被唤醒做一次数据记录那接口频率其实不用拉太高中等速率反而有利于降低功耗。对功耗敏感的产品可以欠压或者降低时钟频率来换功耗但要在性能和数据完整性之间找平衡。4.2 掉电保护NAND最容易被低估的软肋NAND写Page是一个编程动作时间相对长如果编程过程中掉电这个Page可能处于不确定状态轻则数据错重则损坏。很多开发者在实验室里发现不了这个问题因为电源稳定一到客户现场电池供电、触点接触不良、用户直接抠电池问题就全出来了。应对思路有几种我在产品里一般会组合使用硬件掉电检测MCU通过ADC或比较器检测电源跌落在电压低于阈值时立刻停止Flash操作并给关键的元数据区做标志。双备份关键区Bootloader、分区表、文件系统超级块这些关键区域做两份写入时先写备份再写主拷贝启动时校验主拷贝无效就回退。脏标志与日志在擦除/写入前先写一个操作中标志启动时看到这个标志就知道上次操作没完成做恢复流程。这些策略会让固件复杂不少但QspiNAND这类产品本来就是给有一定软件能力的团队用的。如果不想处理这些那大概率还是得回到NOR Flash的舒适区接受容量和价格的上限。4.3 寿命和ECC能用多久要会算NAND Flash有擦写寿命上限。SLC颗粒一般标称5万到10万次擦写MLC只有几千到一两万次。1Gb QspiNAND作为工业向产品大概率是SLC或等效SLC设计寿命相对乐观但也不能浪费。算一下寿命预期假设一台设备每天写入50MB日志128MB分区可用约80MB扣除文件系统开销和坏块预留。用简单的循环覆盖方式每天写约半个分区那每天的擦写次数在0.5到1次P/E之间。按5万次P/E算可以用50000天远超产品生命周期。但现实不会这么理想。如果应用频繁修改小文件比如每几秒就更新一下传感器当前值每次都要擦写同一个Block磨损就会集中。解决办法是使用带磨损均衡的文件系统或FTL层让写入均匀分布到所有Block。ECC是另一个绕不开的话题。NAND出厂就有坏块使用中还会产生新坏块所以读取时要做ECC纠错。有些SPI NAND颗粒内置了ECC主控只需读取状态寄存器判断是否发生不可纠错错误有些则需要主控自己做ECC。选型时一定要确认这一点否则后面驱动工作量会大很多。我的建议是优先选内置ECC的颗粒至少能省掉MCU侧大量运算开销也减少固件出bug的概率。5. 从选型到量产的坑驱动适配、坏块管理与PCB布局5.1 先确认主控QSPI控制器的能力别被支持QSPI骗了很多MCU宣传自己带QSPI接口但它到底支持什么命令、支持多大频率、有没有DMA、能不能双bank连续访问都得仔细看参考手册。我见过一个项目主控说支持QSPI结果只有单线SPI模式可用Quad模式压根没接线还有的主控对QSPI NAND的Page Program命令支持不完整只能通过普通SPI模式写速度直接掉回单线。所以在选型阶段第一步不是看Flash datasheet而是确认主控侧的QSPI控制器支持哪些命令序列支不支持读状态寄存器、写使能、页编程、块擦除、读ID这些基本操作。还可以做一个小测试板用逻辑分析仪抓一遍读ID和擦写命令确认时序没问题再继续。如果主控的QSPI控制器实在太弱也可以退一步用普通SPI模式跑QspiNAND只是吞吐会低一些。可穿戴设备的数据量通常不大不是所有场景都需要Quad模式跑满这个折中是可以接受的。5.2 坏块管理和磨损均衡到底谁来干这是QspiNAND项目里最大的分水岭。有的团队只用它存一次性写入的资源包坏块管理都不做擦写一次就不动了那确实简单但只要涉及动态写入和擦除就必须有坏块管理和磨损均衡。常见做法有三种方案A裸驱动自己做简单坏块表。出厂时扫描所有Block标记坏块维护一张表写入时跳过坏块。磨损均衡可能只做简单的轮询写适合日志类顺序写入场景。方案B使用带FTL的SPI NAND方案。部分颗粒内部会实现地址映射、坏块管理、磨损均衡对外提供类似逻辑扇区读写接口主控侧简单很多。Winbond在NOR上的W25Q生态很成熟NAND产品线也在往降低开发门槛方向走。如果有内置FTL的产品对中小团队非常友好。方案C使用文件系统组件比如LittleFS、SPIFFS或一些专门支持NAND的嵌入式文件系统。LittleFS自带磨损均衡和掉电保护但对NAND的坏块管理支持需要权衡很多文件系统是为NOR设计的对NAND的只能按页写、按块擦约束适配得并不好。我的经验是如果是资源包日志类的项目方案A够用且代码透明如果涉及文件管理、多目录、频繁增删那么方案C更合适如果想要开发速度快、又不想自己处理坏块那就找方案B的颗粒或者模块。5.3 硬件布局和电源小设备上的隐形坑存储芯片本身不大但在可穿戴设备的狭小PCB上摆放位置和电源滤波会影响整机稳定性。说几个我踩过的和见过的问题去耦电容不能省Flash在页编程时会有电流尖峰如果电源纹波太大可能导致写入错误。0.1uF和1uF的组合电容尽量靠近VCC引脚。QSPI走线要等长Quad模式下四根IO线最好保持等长避免高速翻转时信号偏移。对低主频应用影响不大但只要跑高频这点就要注意。远离天线区域Flash的走线和封装可能引入噪声干扰蓝牙或WiFi天线。布局时尽量把Flash放在天线辐射区之外中间加地过孔隔离。温度测试别省穿戴设备贴近皮肤温度可能到40多度户外设备可能在零下工作。NAND在不同温度下的读写行为和漏电率有差异量产前要做高低温读写测试。还有一个很多人忽略的点烧录。如果是小批量打样用编程器直接烧录没问题但量产时最好在产线上通过主控的烧录接口先把Bootloader和分区表写进去再让设备自己从云端拉取资源包和固件。这样能避免编程器座子在批量过程中带来的接触不良也方便生产后在线升级。6. 是不是所有低功耗设备都该换QspiNAND和NOR、eMMC的取舍6.1 三类方案的边界到底在哪先做一张对照表方便决策时一眼看清维度SPI NORQspiNANDeMMC典型容量1MB~128MB64MB~1Gb4GB~128GBXIP执行支持不支持不支持读随机访问快相对慢相对慢连续写吞吐中快快坏块管理不需要需要芯片内部已做磨损均衡一般不关注需要软件策略芯片内部已做接口复杂度低中高MMC/SDIO主控要求极低需要QSPI/SPI需要SD/MMC控制器典型成本中小容量便宜甜点容量性价比高大容量便宜但门槛高适合场景代码执行、小数据量日志、OTA、资源存储视频、大文件系统、Linux启动这张表最关键的是接口复杂度和主控要求这两行。如果你的主控根本没有SD/MMC控制器那eMMC直接出局如果你的固件需要XIP那NOR依然是刚需只是可以和大容量NAND共存。6.2 什么时候继续用NOR什么时候换QspiNAND我自己的判断逻辑是如果整个固件加资源不超过16MB且没有什么动态数据要存继续用NOR省事。如果固件超过16MB或者需要本地存几十MB的日志、资源包、OTA包那就认真考虑QspiNAND。如果要做Linux或RT-Thread 文件系统 本地数据库需要几百MB甚至几GB空间那直接上eMMC或SD NAND。所以QspiNAND不是万能的它是填补NOR容量不够、eMMC过重这个中间档位的产品。对可穿戴和低功耗IoT这种主控不强、空间不大、又要存不少数据的场景它的优势很明显。6.3 选型决策清单动手前先回答这10个问题在把QspiNAND放进BOM之前我会建议团队把这几个问题过一遍主控有没有可用的QSPI控制器支持哪些命令是否必须支持XIP如果是NOR不能完全替代。有没有掉电保护机制是否需要掉电标志和恢复流程数据写入模式是大块顺序写还是频繁小文件随机写有没有文件系统需求文件系统对NAND的适配是否成熟是否需要ECC颗粒内置还是主控算有没有多分区、A/B升级的需求产品工作温度范围是什么Flash是否满足BOM成本目标是多少同容量NOR和NAND价差是否能接受团队有没有FTL/坏块管理的开发经验这些问题不答完就不要急着画原理图。存储选型看似简单但它涉及固件架构、OTA策略、量产测试和售后运维是一家公司产品成熟度的分水岭。我见过不少团队前期低估这个决策的复杂度等到量产前才发现存储方案不可靠被迫返工那代价不是省下的几块钱芯片差价能补回来的。最后分享一个我自己的小习惯拿到任何一颗新Flash我不会先看datasheet里的性能表而是先写一个最简单的读ID擦除写入读回的裸机测试程序在最小系统板上跑一遍用示波器或者逻辑分析仪把时序抓下来确认主控和颗粒的握手没问题再开始设计产品功能。这一步能提前暴露绝大多数接口兼容性问题比任何仿真都管用。QspiNAND这种处在NOR和eMMC之间的中间派芯片尤其需要这种谨慎验证。如果验证通过它会是可穿戴和低功耗IoT设备里非常能打的一颗存储主力。