在物联网越来越普及的现在，产品使用寿命是一个非常重要的课题。尤其在工业应用、汽车工业领域中，设备制造商通常都采用实时在线韧体更新 (OTA) 来延长产品周期，并藉此同时解决可靠性和安全问题。OTA更新有助于保持用户对产品的满意度，降低工程师执行现场更新的高成本，在车用领域更可避免采用昂贵的车辆召回方式来对车载系统进行升级。
OTA必须在下载和安装更新的过程中，尽量避免发生任何可预见的风险，才能有效地减少停机维修的机会。 在成本压力和上市时间的需求下，通常希望能在现有系统架构下，或是经由些许修改后，可以简单快速地实施OTA功能。而OTA也已成为通过无线或有线（Internet协议）方法进行韧体更新的通用术语。
在闪存上实现OTA功能会影响其成本，设计复杂性和性能。 目前存在许多种实现的方法，而每种方法都有其优点和缺点。本文将探讨几种这样的设计技术，并解释了在现有硬件设计中实现OTA功能时，如何使用Winbond的SpiStack® 内存提供独特的优势。
使用现有闪存来实现OTA
典型的物联网嵌入式系统中，包括了支持DRAM的主控芯片和用于存储程序代码的非挥发性NOR闪存。在初始启动之后，透过“code shadowing”的过程，闪存中的程序代码被解压缩并上传到DRAM以供芯片组执行。在某些状况下我们可以在不更改此硬件配置的情况下添加OTA功能。
在此系统架构中，可以通过暂时停止正常操作，将新版本的韧体下载并认证到DRAM中，并通过一系列擦除和编程操作一次将一个区块传送到NOR闪存来执行OTA更新。 这是通常应用的OTA方法，举例来说，假设观众可以容忍暂时停止服务以及不断电警告（见图1）就能够在半夜进行机顶盒的系统更新。
图1: 机顶盒的韧体更新，需要警告用户不要将设备断电. (Image credit: Hyderabaduser, under Creative Commons licence.)
但有两个原因使得此方法不适用于工业、车用、以及其他重要任务的设备。 第一，暂停日常维护操作通常是昂贵、不方便、或不可接受的。
第二，这种方法包含了不可接受的失败风险。如果在更新过程中意外断电，存储在DRAM中的新韧体数据将立即消失。闪存可能已擦除了旧版的韧体数据，但新版的韧体数据可能仅有一部分写入。这意味着系统将只存在着不完整的韧体，或闪存中存储了两个不同韧体数据的一小部分。在下一次系统启动时，在最好的情况下，系统将无法正常运行，但更有可能的是因系统无法启动而导致设备无法使用。
对于一般消费性产品而言，这种故障的小风险可能是可以接受的。因为它可能不需要专用于OTA功能的额外存储空间，使得这方法具有成本上的优势。
对于工业设备或车用领域而言，失败的风险是不可接受的 – 其对于质量与可靠性的期望，远高于一般消费产品。对于这些应用领域来说，需要其他的更新方法，能够保持旧版的韧体数据，直到成功下载和存储新版的韧体资料。
使用延伸储存空间的闪存来实现OTA
在不先擦除当前韧体数据的情况下储存新版韧体数据的一个简单的方法是增加可用的闪存容量。这通常意味着只能将闪存的容量加倍，来满足当前版本和新版本同时存储在同一设备中。
我们可藉由地址偏移机制来确定要执行的活动代码映像。这可以由主控芯片组或软件支持。目的是改变程序计数器以指向两个版本韧体数据之一以供执行。当成功更新新版本韧体数据时，闪存执行擦除和编程操作，并调整地址偏移量将代码执行指向新的韧体数据；至于旧韧体数据所在的闪存区域，可用于未来的更新。
此方法解决了当韧体更新操作被电源中断影响时，系统无法启动或发生故障的风险。由于仅使用一个闪存，并且在韧体更新期间，闪存不可用于读取操作，因此系统无法保持随时可用的状态。
为了正确看待这一点，考虑在最差的情况下擦除64kB区块可能需要2秒，而一般的256Mb（32MB）NOR闪存有512个这样的区块。 因此，系统设计人员可能需要为更新过程分配数百秒。对于许多应用程序而言，这段停机时间太长。更别说执行DRAM的应用程序也需要定期访问闪存，因此这种长时间的闪存停机时间是不可接受的。
使用各别闪存来实现OTA
为了能让闪存在进行更新的同时能继续读取操作，需要在现有韧体之外为新版本韧体提供单独且平行的存储设备。
实现此目的的一个显而易见的方法是复制存放在主闪存的程序代码到额外的闪存空间。在OTA更新时，用这一块额外的空间来存储新程序代码，并保持非激活状态。 成功编程新程序代码后，这新的存放空间将被激活并指定为主闪存。 而先前的主闪存将被改指定为冗余闪存且非激活。
此方法安全可靠，不存在系统故障风险。因此，它在需要高度可靠性和可用性的系统中很受欢迎。然而这种方法具有更高的材料成本，并且需要更多的电路板空间、新的布局，以及使用来自芯片组的附加信号来控制冗余的闪存设备。由于设计人员持续面临着降低成本的压力，我们有其他方法可以以更低的成本和更低的复杂性实现相同的优势。
如上所述，需要OTA能力的嵌入式系统通常包括用于存储程序代码的外部NOR闪存。 该问题的一个解决方案是在NOR闪存内创建一个分区，产生一组存储器块以支持编程/擦除操作，以及一个单独的存储区以支持读取操作，两者都在同一个芯片上。
这是一种称为Read While Write 的闪存结构。 它们基本上是两个控制电路合并到一个芯片中。 不幸的是，闪存技术的基本特征阻碍了这种组合。因为编程/擦除操作在高电压和电流下运行，有很大的噪声。实际上，噪声总是会影响性能并降低工作频率。为了在没有数据损坏的情况下同时执行读取操作，芯片需要精心的内部隔离。此种架构还需要复制内部数据路径和锁存器以实现同时操作。这些额外的电路设计通常需要更多的芯片面积并增加了产品的成本。
实际上，由于生产的成本较高，使得Read While Write 闪存已经失宠。此外，仅少数供货商支持这种特殊的闪存，因此限制了采购人员的选择。 虽然使用Read While Write 闪存支持储存两个韧体程序代码，且在更新一个程序代码时支持对另一个程序代码的读取，但更高的成本、设计更改、和有限的芯片组可用性抵消了这些优势。
使用SpiStack堆栈芯片内存来实现OTA
在单个闪存、两个闪存、或Read While Write闪存上支持OTA实现的挑战促使华邦推出SpiStackTM产品，该产品使用单个Chip Select（/CS）信号将两个相同的闪存芯片堆栈在一个封装中。在硬件外观上，它看似是一个单一的闪存，透过系统软件选择两个芯片其中之一来使用。
利用这种架构，一个芯片可以执行编程/擦除操作，而另一个芯片可以同时执行读取操作。 因为储存空间由两个单独的芯片提供，所以消除了噪声问题并且可以高速执行并行操作。
许多闪存制造商已经开发出堆栈芯片产品：堆栈闪存芯片的优势在于可以在与单芯片闪存相同的封装中提供更高的储存容量。例如，使用单芯片256Mbit NOR闪存进行代码存储的嵌入式系统采用8mm x 6mm WSON封装，可以在同一封装中替换为512Mbit SpiStack组件。双芯片组件将支持读写操作以进行OTA更新，而不需暂停读取操作，并且当电源意外中断时不会有丢失现有韧体数据的风险。
这种方式虽然大大地符合工业和车用系统的重要要求。但要如何由主芯片控制这两个内存芯片？ 如果每个内存芯片都需要来自主芯片的Chip Select（/ CS）信号，则此闪存上将需要增加一个引脚 - 因此8引脚封装将被更高的引脚数封装替换，以支持额外的引脚连接到主芯片。
将8引脚闪存改用更高引脚数的闪存需要重新设计电路板。对于某些系统，主芯片上没有备用引脚可将/ CS信号驱动第二个内存芯片。因此，虽然堆栈芯片选项看起来很有吸引力，但如果它需要额外的/ CS引脚，不仅仅是不方便整合到系统设计中，甚至会无法整合到系统设计中。
图2: 在SpiStack中使用C2h芯片选择指令搭配Die ID来做芯片选择 (Image credit: Winbond)
为了避免这个问题，华邦在SpiStack产品上开发了利用特殊的软件指令C2h来做芯片选择的技术。该软件指令根据8位Die ID将芯片选择操作从一个芯片引导到另一个芯片（参见图2）。 两个芯片通过相同的引脚与主芯片连接，这意味着无需额外的引脚，因此不需要重新设计电路板来支持OTA更新功能，也无需占用额外的/ CS引脚（参见图3）。
Fig. 3: 在软件中实现内存芯片选择功能，主控芯片就只需一个芯片选择（/CS）引脚.
图3 :(Image credit: Winbond)
技术目前在NOR内存上有W25M512JV和W25M512JW这两种大容量产品。 其他NOR（或NOR和NAND）闪存组合也可根据要求提供。SpiStack使用普及于产业中的标准封装和引脚，其中包括了WSON8和BGA24。
结论
在工业和车用系统中实施OTA更新需要一种能够在更新时连续操作内存的架构，并且在保留先前韧体程序代码的同时，将更新的韧体程序代码储存在非挥发性内存中。在保持系统高速运行的同时，实现OTA更新功能，而无需重新设计电路板。达到这些要求的理想方法是使用冗余内存芯片堆栈方法，并使用软件选择命令 (C2h) 来控制复数内存芯片的选择。而能提供这种解决方案的内存，就是华邦的SpiStackTM系列产品！
有关W25M512JVxxx和W25M512JW产品的规格书，请访问：www.winbond.com
Image credit – set-top box firmware update image
Hyderabaduser (https://commons.wikimedia.org/wiki/File:Set-top_box_firmware_being_updated.jpg), “Set-top box firmware being updated“, https://creativecommons.org/licenses/by-sa/3.0/legalcode