写下这些内容的时候我刚从产线回来手里还握着那张烧录记录表。起因是客户用SSC335做网络摄像机项目产线上三天烧了两千片SPI NAND Flash空片结果有十几片上电起不来返修率看着不高但每一片都要拆机重烧工时和口碑都亏在里面。查到最后问题不在颗粒本身而在烧录环节的几个细节上。这让我想把SigmaStar SSC335系列空片烧录这件事完整写一写从工具准备、固件格式、烧录操作到现场避坑一次性讲透给正在做安防IPC方案、量产导入或者刚接手产线烧录的工程师一份能直接照着用的实战手册。1. 为什么SSC335这种方案要从空片烧录开始1.1 SPI NAND在SSC335方案里的定位SSC335是SigmaStar面向入门级网络摄像机、门铃、猫眼等场景的主力SoC片内没有大容量非易失存储系统软件全部放在外部Flash里。和早期的SPI NOR Flash相比SPI NAND Flash在同样封装尺寸下能提供大得多的容量单位成本也更低。当前主流项目里128MB和256MB的SPI NAND是常见配置可以放下Linux内核、根文件系统、应用程序和视频录像的临时缓存。SSC335的BootROM原生支持从SPI NAND启动所以整个方案只需要一颗NAND颗粒加一颗DDR物料成本非常紧凑。但NAND颗粒和NOR颗粒有本质区别。NAND天生存在坏块读写还要依赖纠错算法搞不清楚这些烧录出来的板子就会时好时坏。SPI NAND虽然把坏块管理和ECC封装到了颗粒内部或者控制器逻辑中但它仍然不是普通工程师印象里那种“写进去就能读出来”的存储介质。理解这一点是理解空片烧录所有细节的前提。1.2 空片烧录与贴片后烧录的本质区别空片烧录指的是Flash颗粒在贴到PCB之前先用离线编程器把固件写入。与之对应的是贴片后烧录也叫在线烧录板子贴完以后通过U-Boot、串口或者网络把固件写进Flash。两者看起来只是工序顺序不同实际对生产流程的影响差得远。空片烧录最大的优势是返修成本低。一片Flash烧坏了退回物料库重新烧就是几秒钟的事贴到板上以后出了问题要拆机、吹焊、清洁、重贴损工损料。对于SSC335这种BOM成本卡得很紧的项目空片烧录是量产首选。但它也有明显门槛离线编程器加适配座子是一笔设备投入而且烧录时看不到SoC的交互全靠编程器软件的校验结果把关工具选型和操作规范就更重要。在线烧录虽然省了编程器设备钱但每一片都要占用产线工位时间首件调试时用可以真正跑量还是空片烧录更稳。2. 空片烧录前的工具清单与硬件环境检查2.1 离线编程器选型与固件适配文件准备SPI NAND离线编程器市面上选择不少工业级常见的是DediProg系列国产的力创、悠景也有对应型号开源一点的还有NeoProgrammer这类DIY方案。选型时我只看三个硬指标能不能自动识别Flash ID、支不支持SPI NAND的完整坏块管理和ECC算法、软件界面能不能锁定烧录配置防止误操作。产线用的设备不建议省这个钱烧录器不稳定造成的隐性返工成本远远超过设备本身的差价。固件文件这块比很多人想象的要复杂。SSC335 SDK编译出来的产物通常不是一个单文件而是一组分区镜像。常规项目里可能有IPL引导、U-Boot、内核、根文件系统、参数分区等好几个部分。离线烧录前必须把这些分区按目标板的分区表拼接成一个完整镜像或者按编号逐个烧写到对应偏移地址。我见过不少第一次导入项目的硬件工程师拿到SDK里散落的bin文件直接拖进编程器烧完上电一点反应都没有问题就出在这里。2.2 连接器和引脚电平最容易出问题的前三项空片烧录需要把Flash颗粒放进编程器的适配座。SPI NAND常见封装有WSON8、VFBGA、TSOP48等不同封装要配不同座子。座子安装颗粒时要注意方向标记大多数座子右上角有圆点或斜角标识对应Flash第1脚。不要凭手感硬压位置偏了会导致某几个引脚虚接烧录时随机报错。引脚电平是另一个高频坑。SPI NAND的工作电压有1.8V和3.3V两种规格SSC335的IO电压与NAND的VCC必须匹配。编程器软件里一般有VCC设置项选错之后表面看ID能识别写入时却会随机校验失败。有经验的产线技术员会养成的习惯是换一个新料号颗粒时先查数据手册确认VCC再核对编程器座子上的电压跳线或软件配置两边一致了才开始烧录。另外WP#和HOLD#这两个引脚在正常烧录时必须处于无效状态即WP#拉高、HOLD#拉高否则会出现写了半天数据根本没进去的诡异现象。多数编程器座子内部已经做了正确的上拉处理但如果用的是自制转接板这几根线必须单独检查。2.3 Flash ID识别烧录前十分钟必须做的事编程器识别Flash ID这件事看着机械却能提前暴露大部分问题。把颗粒装进座子软件点“读取ID”正常情况下会返回一串十六进制ID并自动匹配到具体型号。如果ID读不出来或者与丝印型号不一致先不要怀疑颗粒是坏的按这个顺序排查颗粒是否放平、引脚是否对准、座子是否老化、VCC是否设置正确。我遇到过一种情况批号新的颗粒丝印和旧的一样读出的ID却变了。后来一查原厂升级了内部Die容量和协议完全兼容但ID码段变了。这时候不要强行绕过ID检测应该用编程器软件里“添加器件”的方式把这个新ID识别进去并做一次完整读写校验确认兼容性。量产中每换一个批次的颗粒都要重新确认ID和适配关系这个动作要写进产线的首件确认流程。3. 编程器上的一次烧录全程擦除、写入、校验怎么配合3.1 固件的构成与烧录地址规划以我接触过的SSC335项目来看SPI NAND上的分区规划大致类似下面这样具体以SDK发布为准不同项目差异很大分区名称起始地址典型大小内容说明IPL/SPL0x000000256KB-512KB一级引导BootROM加载U-Boot0x1000001MB-2MB二级引导和指令环境U-Boot环境变量0x30000064KB-128KBbootargs、启动参数Kernel0x4000006MB-8MBLinux内核镜像Rootfs0xC00000剩余全部只读根文件系统/APP这张表最重要的信息是IPL的起始地址必须是0x0。SSC335的BootROM上电后会从这个地址开始读取NAND内容如果这里放的不是有效引导头后面一切都是空谈。实际项目中有些开发为了方便会把U-Boot放到更高地址而IPL很小容易出现烧录文件偏移设置错误。离线烧录前用十六进制工具打开你要烧录的总镜像确认偏移0x0处的数据是预期的引导头而不是空白或者文件系统信息这一步能省掉后面大量排障时间。3.2 烧录操作的完整步骤在编程器上烧一片空片标准流程是这样的。第一步软件里选择对应Flash型号确认ID正确。第二步加载拼接好的烧录镜像文件确认缓冲区大小与Flash容量匹配。第三步设置烧录起始地址为0x0同时确认“整片擦除”和“烧录后校验”两个选项打开。第四步点开始编程器会先执行擦除再逐页写入最后整片校验。第五步校验通过后取下颗粒在料盘或防静电袋上记录批次和烧录时间。擦除这一步要特别说一下。NAND的擦除单位是块不是字节SPI NAND虽然内部有控制器但擦除操作一旦执行整块内容全部变0xFF。空片本身已经是擦除状态理论上可以跳过擦除直接写但我建议量产时不要省这一步。原因是NAND在仓储过程中可能出现个别位翻转编程器在写之前主动擦一遍相当于把颗粒状态强制归零能减少后续上电后的潜在不稳定。开校验这个选项同理虽然会让单片烧录时间变长但产线上的“漏网之鱼”主要靠它拦住。烧录完成后编程器软件一般会给出类似“Verify OK”或“Operation Pass”的提示。这里有个细节很多人忽略软件提示成功代表的是“写入数据和源文件一致”不代表“这些数据在SSC335上能正常启动”。颗粒写入OK和系统启动OK之间还隔着一个分区表匹配的问题。3.3 校验通过不等于烧录成功要判断烧录真的成功唯一的金标准是把颗粒贴到板上整机跑起来。产线里经常出现“编程器全过上电全挂”的批量事故多数是固件拼接阶段就有问题比如分区表是从别的项目抄来的、Kernel实际大小超出了预留空间、或者根文件系统制作时漏掉了必要库文件。这些错误编程器根本不知道它只认数据一致性。所以我在产线导入阶段一定会安排“首件验证”动作调试阶段烧录3-5片贴到主板上逐片确认串口日志、网络启动、视频出流都正常之后才允许批量烧录。如果哪个环节不对回到固件拼接阶段修改而不是在烧录参数上反复试。固件本身的问题靠调整编程器设置是永远调不出来的。4. 上电验证与串口日志定位烧录结果不能只靠编程器4.1 从串口日志判断启动走到了哪一步SSC335主板默认会通过调试串口输出启动日志接上USB转串口工具波特率一般是115200具体以板卡设计为准。上电瞬间能看到BootROM打印、DDR初始化信息、NAND控制器识别结果接着是U-Boot版本信息、内核解压启动、根文件系统挂载、应用程序拉起。日志停在哪一步问题就定位在哪一段。如果日志完全没有输出先不要怀疑Flash烧录按这个顺序查主板供电是否正常、串口TX/RX是否接反、串口工具电平是否匹配、SoC的启动引脚拨码是否正确。SSC335这类方案的启动模式一般由硬件引脚决定如果被拉成了从SD卡或USB启动哪怕Flash里固件完全正确系统也走不到NAND启动这条路上。4.2 常见启动失败现象与根因对照把我在现场见过最多的几个现象整理成一张表给大家排查时当索引现象大概率原因处理方向完全无串口输出供电、串口接线、启动引脚配置错误先查硬件最小系统再查Flash串口有输出但停在DDR初始化颗粒贴装不良或供电不稳定补焊或更换Flash检查DDR供电BootROM无法识别NANDFlash型号不匹配、片选/时钟信号问题核对颗粒型号与ID检查贴装U-Boot阶段反复重启环境变量分区数据损坏重新擦除参数分区确认烧录地址内核启动时挂载根文件系统失败Rootfs分区偏移错误或坏块过多检查分区表确认ECC策略启动正常但应用程序报存储错误数据分区未格式化或坏块管理异常重新擦除用户数据区并格式化这张表的价值在于大多数人遇到“上电不起”第一反应是“Flash没烧好”实际上三分之一以上的情况是硬件或分区配置问题。先看日志能走到哪一步再决定要不要重烧Flash排障效率会高很多。4.3 在U-Boot里主动验证Flash内容如果板子能进U-Boot验证Flash就非常简单。在U-Boot命令行下可以用nand info命令读取NAND容量和参数用nand dump或nand read命令查看指定地址的数据。比如我想确认Kernel分区里是不是真的有内核先看SDK分区表里Kernel对应的偏移地址然后执行读取操作把数据加载到内存中再用校验和或直接对比的方式确认。这里还有一条很实用的经验开发阶段拿到一个新的固件拼接文件后先在U-Boot下用升级命令烧一遍再读出来与原始文件做md5比对。如果md5一致说明板子这条NAND读写链路是健康的之后再用离线编程器烧同样的内容上电验证一次链路就完全闭环了。以后产线再出问题就能把“板子读写链路”和“编程器烧录质量”这两个变量分开判断。5. 我踩过的坑五个典型的现场故障与完整排查链路5.1 烧了十片坏三片最后一查是座子老化有一阵子产线反馈烧录作业员“手法不好”十片里总有几片校验失败重夹一次又好了。我一开始也以为是操作问题让拉长盯着作业。后来发现故障率和座子使用次数明显相关换上备用座子问题立刻消失。拆开旧座子仔细看触点已经有轻微磨损痕迹引脚与颗粒的接触压力不够了。这个坑的教训是编程器座子是耗材不是固定资产。量产量大的项目座子触点是有使用寿命的一般几千次之后就会出现偶发接触不良。更麻烦的是这种接触不良不是每次都报错有时候表现为写入某几个Byte失败有时候是校验时随机差异极具迷惑性。现在我会在产线备两套座子轮换使用并规定每换一个烧录批次就记录当班次烧录数量累计到一定量就强制更换不省这个钱。5.2 插件ID不匹配查到最后是颗粒批号变更另一个印象深刻的项目颗粒从旧批号切换到新批号后编程器软件弹窗“ID mismatch”。产线技术员的第一反应是“这批料有问题”差点把整批货退回代理商。我拿数据手册一查发现新批号是原厂Die迭代后的版本电气参数和时序完全兼容只是ID码段变了。在编程器里更新芯片数据库之后烧录验证一切正常。这件事提醒我颗粒原厂更新Die是非常普遍的事情丝印型号不变、ID变了的案例并不少见。遇到ID不匹配先不要否定颗粒按这个顺序确认查数据手册确认新ID归属、对比新旧版本差异、用已知好片做对比烧录验证。如果验证通过就把新ID添加进量产配置文件并记录变更日期和验证结果。把这些信息同步给采购和仓库能避免下一批来料时重复踩坑。5.3 固件校验通过上电却反复重启这个问题折腾了我差不多一周。离线编程器每一片都报校验OK贴上板子串口能输出U-Boot版本信息但紧接着就重启如此循环完全没有进入内核的迹象。看日志U-Boot反复重启总是卡在读取环境变量之后。一开始怀疑是Flash坏块问题换了几颗全新颗粒症状一模一样把矛头指向固件本身。后来用十六进制工具逐段查看固件镜像发现一个被我忽视的细节SDK发布包里的“总镜像”在地址0x0处放的不是IPL而是U-Boot之后的一段填充数据。开发调试时用的烧录脚本会自动把IPL写到0x0、U-Boot写到偏移地址脚本隐藏了这个顺序。我在离线编程器里直接烧总镜像等于把IPL放错了位置——具体说IPL被埋在了总镜像的末尾BootROM去0x0读引导头当然读不到。解决方法是重新按分区表把镜像拆开分别烧写到对应位置。这个项目之后我定了一条规矩凡是SDK给的“一键烧录包”必须先核对文件内部结构和分区表的对应关系再决定离线编程器怎么烧。5.4 擦除不彻底参数分区残留导致配置错乱还有一次问题更隐蔽。烧录本身没问题启动也正常但设备网络参数总是随机丢失表现为一段时间后IP地址回到默认值或者分辨率设置被复原。查了很久最后是在U-Boot里看了下参数分区的数据发现里面残留了上上批板卡调试时的旧环境变量。原因出在离线编程器的擦除策略上。量产时为了省时间有些人会把“整片擦除”关掉只擦除要写入数据的分区甚至只做写入不擦除。而SPI NAND的擦除以块为单位如果新固件的参数分区比原来的小旧数据就会残留在分区末尾SSC335的U-Boot在启动时读取环境变量又以固定长度为准残留数据被读进去就导致配置错乱。从那以后我只允许两种量产烧录方式整片擦除后整片写入或者按明确分区地址先擦后写绝不允许“直接写入不擦除”。这点必须写进产线的作业指导书因为它不是每次都会出错但一旦出货后出问题追溯成本极高。5.5 批量烧录偶发校验失败最后锁定信号完整性某项目在量产爬坡阶段产线反馈“烧录器校验失败率突然从千分之一涨到百分之三”。换座子、换编程器、换颗粒都没能根治。后来在现场蹲了半天注意到一个反常现象每天上午第一个小时的故障率最高而且车间里空压机一启动故障率明显上升。排查到最后问题的根源有两个。一是编程器的连接线束在长距离走线时与动力线靠得太近空压机启动时引入电磁干扰造成SPI时钟和数据线上的信号毛刺二是当天上午车间温度低座子塑料件收缩接触压力略微下降两种因素叠加把偶发问题放大了。处理方法是重新规划烧录工位的走线信号线全部换成带屏蔽的短连线并给座子加了恒温加热垫故障率回到千分之一以下。这个案子的教训很直接烧录工的电磁环境和机械环境和烧录器本身一样关键。6. 量产阶段的提速思路与数据管理建议6.1 单片烧录时间怎么压下来烧录一片SPI NAND的时间主要花在写入和校验两个环节上。一片128MB的颗粒在主流编程器上跑一遍全片写入加校验大约需要几分钟具体取决于编程器的写入速度和是否开启校验。想提速有几个聪明的办法。第一个办法是“只烧必要分区”。如果整片容量256MB而实际固件只有60MB没必要把剩余空间也写一遍只要确保未使用区域是擦除状态即可。编程器软件里可以设置烧录范围只覆盖有效分区写入时间直接和固件大小成正比。第二个办法是不要在每次量产时都改配置把已经验证过的工程文件保存为模板下次打开直接加载既减少设置时间也降低人为误触概率。第三个办法是给关键工位配双编程器一个在烧录另一个在装卸料交替作业把人工等待时间完全掩盖掉。6.2 固件版本、烧录记录与可追溯性管理量产最怕的是“出货之后不知道哪批板子烧的是哪个版本固件”。返场维护时如果有烧录记录直接按批次锁定范围和版本定向召回如果没有记录就只能大海捞针。离线编程器软件一般都带操作日志和统计功能可以导出每片烧录的时间、结果、操作员、设备编号等信息。我的习惯是每次固件更新时不仅保存固件文件还要把烧录工程配置一起保存命名格式包含项目名、固件版本号、日期和烧录器软件版本。产线每天结束时导出一份烧录报表按批次归档。这样万一某批次出了问题可以精确回溯到“这批用了哪个固件文件、哪台编程器、哪个座子、哪位操作员”排查范围一下子就缩小了。平时多花五分钟做的记录返工时省的是几十倍的工时这笔账一定要算清楚。最后说一个我自己的习惯。每次拿到新版本的固件包我不会急着导入编程器量产而是先在电脑上把固件文件用十六进制工具从头到尾翻一遍重点看分区表声明的各个分区的起始标记是否正确。这个动作只需要几分钟却能避免把整个产线带到沟里。烧录这件事看着是体力活真正的门槛全在源头那几个决定里。把这几个决定做对产线才能稳定、可复制地出好货。
写下这些内容的时候我刚从产线回来手里还握着那张烧录记录表。起因是客户用SSC335做网络摄像机项目产线上三天烧了两千片SPI NAND Flash空片结果有十几片上电起不来返修率看着不高但每一片都要拆机重烧工时和口碑都亏在里面。查到最后问题不在颗粒本身而在烧录环节的几个细节上。这让我想把SigmaStar SSC335系列空片烧录这件事完整写一写从工具准备、固件格式、烧录操作到现场避坑一次性讲透给正在做安防IPC方案、量产导入或者刚接手产线烧录的工程师一份能直接照着用的实战手册。1. 为什么SSC335这种方案要从空片烧录开始1.1 SPI NAND在SSC335方案里的定位SSC335是SigmaStar面向入门级网络摄像机、门铃、猫眼等场景的主力SoC片内没有大容量非易失存储系统软件全部放在外部Flash里。和早期的SPI NOR Flash相比SPI NAND Flash在同样封装尺寸下能提供大得多的容量单位成本也更低。当前主流项目里128MB和256MB的SPI NAND是常见配置可以放下Linux内核、根文件系统、应用程序和视频录像的临时缓存。SSC335的BootROM原生支持从SPI NAND启动所以整个方案只需要一颗NAND颗粒加一颗DDR物料成本非常紧凑。但NAND颗粒和NOR颗粒有本质区别。NAND天生存在坏块读写还要依赖纠错算法搞不清楚这些烧录出来的板子就会时好时坏。SPI NAND虽然把坏块管理和ECC封装到了颗粒内部或者控制器逻辑中但它仍然不是普通工程师印象里那种“写进去就能读出来”的存储介质。理解这一点是理解空片烧录所有细节的前提。1.2 空片烧录与贴片后烧录的本质区别空片烧录指的是Flash颗粒在贴到PCB之前先用离线编程器把固件写入。与之对应的是贴片后烧录也叫在线烧录板子贴完以后通过U-Boot、串口或者网络把固件写进Flash。两者看起来只是工序顺序不同实际对生产流程的影响差得远。空片烧录最大的优势是返修成本低。一片Flash烧坏了退回物料库重新烧就是几秒钟的事贴到板上以后出了问题要拆机、吹焊、清洁、重贴损工损料。对于SSC335这种BOM成本卡得很紧的项目空片烧录是量产首选。但它也有明显门槛离线编程器加适配座子是一笔设备投入而且烧录时看不到SoC的交互全靠编程器软件的校验结果把关工具选型和操作规范就更重要。在线烧录虽然省了编程器设备钱但每一片都要占用产线工位时间首件调试时用可以真正跑量还是空片烧录更稳。2. 空片烧录前的工具清单与硬件环境检查2.1 离线编程器选型与固件适配文件准备SPI NAND离线编程器市面上选择不少工业级常见的是DediProg系列国产的力创、悠景也有对应型号开源一点的还有NeoProgrammer这类DIY方案。选型时我只看三个硬指标能不能自动识别Flash ID、支不支持SPI NAND的完整坏块管理和ECC算法、软件界面能不能锁定烧录配置防止误操作。产线用的设备不建议省这个钱烧录器不稳定造成的隐性返工成本远远超过设备本身的差价。固件文件这块比很多人想象的要复杂。SSC335 SDK编译出来的产物通常不是一个单文件而是一组分区镜像。常规项目里可能有IPL引导、U-Boot、内核、根文件系统、参数分区等好几个部分。离线烧录前必须把这些分区按目标板的分区表拼接成一个完整镜像或者按编号逐个烧写到对应偏移地址。我见过不少第一次导入项目的硬件工程师拿到SDK里散落的bin文件直接拖进编程器烧完上电一点反应都没有问题就出在这里。2.2 连接器和引脚电平最容易出问题的前三项空片烧录需要把Flash颗粒放进编程器的适配座。SPI NAND常见封装有WSON8、VFBGA、TSOP48等不同封装要配不同座子。座子安装颗粒时要注意方向标记大多数座子右上角有圆点或斜角标识对应Flash第1脚。不要凭手感硬压位置偏了会导致某几个引脚虚接烧录时随机报错。引脚电平是另一个高频坑。SPI NAND的工作电压有1.8V和3.3V两种规格SSC335的IO电压与NAND的VCC必须匹配。编程器软件里一般有VCC设置项选错之后表面看ID能识别写入时却会随机校验失败。有经验的产线技术员会养成的习惯是换一个新料号颗粒时先查数据手册确认VCC再核对编程器座子上的电压跳线或软件配置两边一致了才开始烧录。另外WP#和HOLD#这两个引脚在正常烧录时必须处于无效状态即WP#拉高、HOLD#拉高否则会出现写了半天数据根本没进去的诡异现象。多数编程器座子内部已经做了正确的上拉处理但如果用的是自制转接板这几根线必须单独检查。2.3 Flash ID识别烧录前十分钟必须做的事编程器识别Flash ID这件事看着机械却能提前暴露大部分问题。把颗粒装进座子软件点“读取ID”正常情况下会返回一串十六进制ID并自动匹配到具体型号。如果ID读不出来或者与丝印型号不一致先不要怀疑颗粒是坏的按这个顺序排查颗粒是否放平、引脚是否对准、座子是否老化、VCC是否设置正确。我遇到过一种情况批号新的颗粒丝印和旧的一样读出的ID却变了。后来一查原厂升级了内部Die容量和协议完全兼容但ID码段变了。这时候不要强行绕过ID检测应该用编程器软件里“添加器件”的方式把这个新ID识别进去并做一次完整读写校验确认兼容性。量产中每换一个批次的颗粒都要重新确认ID和适配关系这个动作要写进产线的首件确认流程。3. 编程器上的一次烧录全程擦除、写入、校验怎么配合3.1 固件的构成与烧录地址规划以我接触过的SSC335项目来看SPI NAND上的分区规划大致类似下面这样具体以SDK发布为准不同项目差异很大分区名称起始地址典型大小内容说明IPL/SPL0x000000256KB-512KB一级引导BootROM加载U-Boot0x1000001MB-2MB二级引导和指令环境U-Boot环境变量0x30000064KB-128KBbootargs、启动参数Kernel0x4000006MB-8MBLinux内核镜像Rootfs0xC00000剩余全部只读根文件系统/APP这张表最重要的信息是IPL的起始地址必须是0x0。SSC335的BootROM上电后会从这个地址开始读取NAND内容如果这里放的不是有效引导头后面一切都是空谈。实际项目中有些开发为了方便会把U-Boot放到更高地址而IPL很小容易出现烧录文件偏移设置错误。离线烧录前用十六进制工具打开你要烧录的总镜像确认偏移0x0处的数据是预期的引导头而不是空白或者文件系统信息这一步能省掉后面大量排障时间。3.2 烧录操作的完整步骤在编程器上烧一片空片标准流程是这样的。第一步软件里选择对应Flash型号确认ID正确。第二步加载拼接好的烧录镜像文件确认缓冲区大小与Flash容量匹配。第三步设置烧录起始地址为0x0同时确认“整片擦除”和“烧录后校验”两个选项打开。第四步点开始编程器会先执行擦除再逐页写入最后整片校验。第五步校验通过后取下颗粒在料盘或防静电袋上记录批次和烧录时间。擦除这一步要特别说一下。NAND的擦除单位是块不是字节SPI NAND虽然内部有控制器但擦除操作一旦执行整块内容全部变0xFF。空片本身已经是擦除状态理论上可以跳过擦除直接写但我建议量产时不要省这一步。原因是NAND在仓储过程中可能出现个别位翻转编程器在写之前主动擦一遍相当于把颗粒状态强制归零能减少后续上电后的潜在不稳定。开校验这个选项同理虽然会让单片烧录时间变长但产线上的“漏网之鱼”主要靠它拦住。烧录完成后编程器软件一般会给出类似“Verify OK”或“Operation Pass”的提示。这里有个细节很多人忽略软件提示成功代表的是“写入数据和源文件一致”不代表“这些数据在SSC335上能正常启动”。颗粒写入OK和系统启动OK之间还隔着一个分区表匹配的问题。3.3 校验通过不等于烧录成功要判断烧录真的成功唯一的金标准是把颗粒贴到板上整机跑起来。产线里经常出现“编程器全过上电全挂”的批量事故多数是固件拼接阶段就有问题比如分区表是从别的项目抄来的、Kernel实际大小超出了预留空间、或者根文件系统制作时漏掉了必要库文件。这些错误编程器根本不知道它只认数据一致性。所以我在产线导入阶段一定会安排“首件验证”动作调试阶段烧录3-5片贴到主板上逐片确认串口日志、网络启动、视频出流都正常之后才允许批量烧录。如果哪个环节不对回到固件拼接阶段修改而不是在烧录参数上反复试。固件本身的问题靠调整编程器设置是永远调不出来的。4. 上电验证与串口日志定位烧录结果不能只靠编程器4.1 从串口日志判断启动走到了哪一步SSC335主板默认会通过调试串口输出启动日志接上USB转串口工具波特率一般是115200具体以板卡设计为准。上电瞬间能看到BootROM打印、DDR初始化信息、NAND控制器识别结果接着是U-Boot版本信息、内核解压启动、根文件系统挂载、应用程序拉起。日志停在哪一步问题就定位在哪一段。如果日志完全没有输出先不要怀疑Flash烧录按这个顺序查主板供电是否正常、串口TX/RX是否接反、串口工具电平是否匹配、SoC的启动引脚拨码是否正确。SSC335这类方案的启动模式一般由硬件引脚决定如果被拉成了从SD卡或USB启动哪怕Flash里固件完全正确系统也走不到NAND启动这条路上。4.2 常见启动失败现象与根因对照把我在现场见过最多的几个现象整理成一张表给大家排查时当索引现象大概率原因处理方向完全无串口输出供电、串口接线、启动引脚配置错误先查硬件最小系统再查Flash串口有输出但停在DDR初始化颗粒贴装不良或供电不稳定补焊或更换Flash检查DDR供电BootROM无法识别NANDFlash型号不匹配、片选/时钟信号问题核对颗粒型号与ID检查贴装U-Boot阶段反复重启环境变量分区数据损坏重新擦除参数分区确认烧录地址内核启动时挂载根文件系统失败Rootfs分区偏移错误或坏块过多检查分区表确认ECC策略启动正常但应用程序报存储错误数据分区未格式化或坏块管理异常重新擦除用户数据区并格式化这张表的价值在于大多数人遇到“上电不起”第一反应是“Flash没烧好”实际上三分之一以上的情况是硬件或分区配置问题。先看日志能走到哪一步再决定要不要重烧Flash排障效率会高很多。4.3 在U-Boot里主动验证Flash内容如果板子能进U-Boot验证Flash就非常简单。在U-Boot命令行下可以用nand info命令读取NAND容量和参数用nand dump或nand read命令查看指定地址的数据。比如我想确认Kernel分区里是不是真的有内核先看SDK分区表里Kernel对应的偏移地址然后执行读取操作把数据加载到内存中再用校验和或直接对比的方式确认。这里还有一条很实用的经验开发阶段拿到一个新的固件拼接文件后先在U-Boot下用升级命令烧一遍再读出来与原始文件做md5比对。如果md5一致说明板子这条NAND读写链路是健康的之后再用离线编程器烧同样的内容上电验证一次链路就完全闭环了。以后产线再出问题就能把“板子读写链路”和“编程器烧录质量”这两个变量分开判断。5. 我踩过的坑五个典型的现场故障与完整排查链路5.1 烧了十片坏三片最后一查是座子老化有一阵子产线反馈烧录作业员“手法不好”十片里总有几片校验失败重夹一次又好了。我一开始也以为是操作问题让拉长盯着作业。后来发现故障率和座子使用次数明显相关换上备用座子问题立刻消失。拆开旧座子仔细看触点已经有轻微磨损痕迹引脚与颗粒的接触压力不够了。这个坑的教训是编程器座子是耗材不是固定资产。量产量大的项目座子触点是有使用寿命的一般几千次之后就会出现偶发接触不良。更麻烦的是这种接触不良不是每次都报错有时候表现为写入某几个Byte失败有时候是校验时随机差异极具迷惑性。现在我会在产线备两套座子轮换使用并规定每换一个烧录批次就记录当班次烧录数量累计到一定量就强制更换不省这个钱。5.2 插件ID不匹配查到最后是颗粒批号变更另一个印象深刻的项目颗粒从旧批号切换到新批号后编程器软件弹窗“ID mismatch”。产线技术员的第一反应是“这批料有问题”差点把整批货退回代理商。我拿数据手册一查发现新批号是原厂Die迭代后的版本电气参数和时序完全兼容只是ID码段变了。在编程器里更新芯片数据库之后烧录验证一切正常。这件事提醒我颗粒原厂更新Die是非常普遍的事情丝印型号不变、ID变了的案例并不少见。遇到ID不匹配先不要否定颗粒按这个顺序确认查数据手册确认新ID归属、对比新旧版本差异、用已知好片做对比烧录验证。如果验证通过就把新ID添加进量产配置文件并记录变更日期和验证结果。把这些信息同步给采购和仓库能避免下一批来料时重复踩坑。5.3 固件校验通过上电却反复重启这个问题折腾了我差不多一周。离线编程器每一片都报校验OK贴上板子串口能输出U-Boot版本信息但紧接着就重启如此循环完全没有进入内核的迹象。看日志U-Boot反复重启总是卡在读取环境变量之后。一开始怀疑是Flash坏块问题换了几颗全新颗粒症状一模一样把矛头指向固件本身。后来用十六进制工具逐段查看固件镜像发现一个被我忽视的细节SDK发布包里的“总镜像”在地址0x0处放的不是IPL而是U-Boot之后的一段填充数据。开发调试时用的烧录脚本会自动把IPL写到0x0、U-Boot写到偏移地址脚本隐藏了这个顺序。我在离线编程器里直接烧总镜像等于把IPL放错了位置——具体说IPL被埋在了总镜像的末尾BootROM去0x0读引导头当然读不到。解决方法是重新按分区表把镜像拆开分别烧写到对应位置。这个项目之后我定了一条规矩凡是SDK给的“一键烧录包”必须先核对文件内部结构和分区表的对应关系再决定离线编程器怎么烧。5.4 擦除不彻底参数分区残留导致配置错乱还有一次问题更隐蔽。烧录本身没问题启动也正常但设备网络参数总是随机丢失表现为一段时间后IP地址回到默认值或者分辨率设置被复原。查了很久最后是在U-Boot里看了下参数分区的数据发现里面残留了上上批板卡调试时的旧环境变量。原因出在离线编程器的擦除策略上。量产时为了省时间有些人会把“整片擦除”关掉只擦除要写入数据的分区甚至只做写入不擦除。而SPI NAND的擦除以块为单位如果新固件的参数分区比原来的小旧数据就会残留在分区末尾SSC335的U-Boot在启动时读取环境变量又以固定长度为准残留数据被读进去就导致配置错乱。从那以后我只允许两种量产烧录方式整片擦除后整片写入或者按明确分区地址先擦后写绝不允许“直接写入不擦除”。这点必须写进产线的作业指导书因为它不是每次都会出错但一旦出货后出问题追溯成本极高。5.5 批量烧录偶发校验失败最后锁定信号完整性某项目在量产爬坡阶段产线反馈“烧录器校验失败率突然从千分之一涨到百分之三”。换座子、换编程器、换颗粒都没能根治。后来在现场蹲了半天注意到一个反常现象每天上午第一个小时的故障率最高而且车间里空压机一启动故障率明显上升。排查到最后问题的根源有两个。一是编程器的连接线束在长距离走线时与动力线靠得太近空压机启动时引入电磁干扰造成SPI时钟和数据线上的信号毛刺二是当天上午车间温度低座子塑料件收缩接触压力略微下降两种因素叠加把偶发问题放大了。处理方法是重新规划烧录工位的走线信号线全部换成带屏蔽的短连线并给座子加了恒温加热垫故障率回到千分之一以下。这个案子的教训很直接烧录工的电磁环境和机械环境和烧录器本身一样关键。6. 量产阶段的提速思路与数据管理建议6.1 单片烧录时间怎么压下来烧录一片SPI NAND的时间主要花在写入和校验两个环节上。一片128MB的颗粒在主流编程器上跑一遍全片写入加校验大约需要几分钟具体取决于编程器的写入速度和是否开启校验。想提速有几个聪明的办法。第一个办法是“只烧必要分区”。如果整片容量256MB而实际固件只有60MB没必要把剩余空间也写一遍只要确保未使用区域是擦除状态即可。编程器软件里可以设置烧录范围只覆盖有效分区写入时间直接和固件大小成正比。第二个办法是不要在每次量产时都改配置把已经验证过的工程文件保存为模板下次打开直接加载既减少设置时间也降低人为误触概率。第三个办法是给关键工位配双编程器一个在烧录另一个在装卸料交替作业把人工等待时间完全掩盖掉。6.2 固件版本、烧录记录与可追溯性管理量产最怕的是“出货之后不知道哪批板子烧的是哪个版本固件”。返场维护时如果有烧录记录直接按批次锁定范围和版本定向召回如果没有记录就只能大海捞针。离线编程器软件一般都带操作日志和统计功能可以导出每片烧录的时间、结果、操作员、设备编号等信息。我的习惯是每次固件更新时不仅保存固件文件还要把烧录工程配置一起保存命名格式包含项目名、固件版本号、日期和烧录器软件版本。产线每天结束时导出一份烧录报表按批次归档。这样万一某批次出了问题可以精确回溯到“这批用了哪个固件文件、哪台编程器、哪个座子、哪位操作员”排查范围一下子就缩小了。平时多花五分钟做的记录返工时省的是几十倍的工时这笔账一定要算清楚。最后说一个我自己的习惯。每次拿到新版本的固件包我不会急着导入编程器量产而是先在电脑上把固件文件用十六进制工具从头到尾翻一遍重点看分区表声明的各个分区的起始标记是否正确。这个动作只需要几分钟却能避免把整个产线带到沟里。烧录这件事看着是体力活真正的门槛全在源头那几个决定里。把这几个决定做对产线才能稳定、可复制地出好货。
