Live over-the-air system firmware updates to Flash

The long service life of products in the industrial and automotive sectors and the increasing availability of connectivity in these products compel IoT device manufacturers to address reliability and security problems or to implement feature enhancements via a process generally known as the Over-The-Air (OTA) update of the system firmware. OTA updating helps maintain the user’s satisfaction with the product, eliminates the high cost of commissioning service personnel to perform on-site updates, or in the case of the automotive sector avoids issuing costly vehicle recalls.

Furthermore, OTA updates must be done reliably while minimizing the need for planned or unplanned downtime. This means the process for downloading and installing OTA updates has to be made free of foreseeable risk. On the other hand, cost pressure and the need for faster time-to-market require that the OTA capability be implemented simply and quickly, which generally calls for the ability to upgrade an existing design with little or no changes. It is also important to note that OTA has become a general term for firmware updating via either wireless or wired (Internet Protocol) methods.

The way Flash storage is implemented for the OTA function has an impact on its cost, design complexity, and performance. Various approaches have been adopted, each of which offers various advantages and drawbacks. This article explores several such design techniques, and explains how the use of Winbond’s SpiStack® memory provides unique benefits when implementing the OTA function in existing hardware designs.


Using Existing Flash Provision for OTA Updates

A typical embedded system for IoT consists of a chipset supported by DRAM and an external non-volatile NOR Flash memory for code storage. After initial boot-up, through the process of ‘code shadowing’ the code in the Flash memory is decompressed and uploaded to DRAM for execution by the chipset. OTA functionality can sometimes be added without changing this hardware configuration.

In this system architecture, OTA updates may be performed by stopping normal operation temporarily, downloading and authenticating the new firmware version to the DRAM, and transferring it one sector or block at a time to the NOR Flash through a series of erase and program operations. This is the OTA method commonly applied, for instance, by set-top boxes for system updates in the middle of the night, when it is assumed that the viewer can tolerate a temporary suspension of service as well as a warning not to disconnect the power supply (see Figure 1).

DRAM-based firmware updates to a set-top box require a warning to the user not to unplug the device from the power supply. (Image credit: Hyderabaduser, under Creative Commons licence.)

Fig. 1: DRAM-based firmware updates to a set-top box require a warning to the user not to unplug the device from the power supply. (Image credit: Hyderabaduser, under Creative Commons licence.)


This method is inappropriate for industrial and automotive applications and for any mission-critical equipment for two reasons. First, it will often be costly, inconvenient or unacceptable to suspend operation for routine maintenance.

Second, this method entails an unacceptable risk of failure. In the event of an unexpected power outage during the updating process, the new firmware image stored in DRAM would instantly be lost. The previous firmware image may have been partially erased from the Flash device, but the new image may only be partially written. This could mean the system would be left with incomplete firmware, or with parts of two different firmware images stored in Flash. At the next system start-up, in the best case, the system will not operate properly, and more likely, the system will fail to boot, rendering the device unusable.

The small risk of such a failure might be acceptable for a low-end consumer device. And this method can have a cost advantage, as it may requires no additional storage capacity dedicated to the OTA function.

The risk of failure would be unacceptable for industrial equipment or for vehicles – applications in which expectations of quality and reliability are much higher than in low-end consumer devices. These applications require an updating method in which the current firmware version is maintained until new firmware is successfully downloaded and stored.


OTA With Expanded Flash Storage

A straightforward method for storing a new firmware version without first erasing the current image is to increase the amount of Flash storage available. This usually means doubling the capacity of the Flash to allow for both the current and the new versions to be simultaneously stored in the same device, however, only one of the two version is deemed active.

An address offset mechanism determines the active code image for execution. This can be supported either by the host chipset, or in software. The purpose is to alter the program counter to point to one of the two versions of the firmware image for execution. When a new firmware image has been successfully updated, which in Flash parlance involves erase and program operations, the address offset is adjusted so that subsequent code execution will be directed towards the new firmware image; the portion of the Flash capacity occupied by the old image is then available for subsequent updates.

This method eliminates the risk of the system failing to boot or malfunctioning when a code update operation is interrupted by a power interruption. And, since only one Flash device is used, and the Flash is unavailable for read operations during the code update, the system  cannot maintain continuous availability.

To put this in perspective, for a typical 256Mb (32MB) NOR Flash device, erasing a 64kB block can take up to 2s in the worst case – and there are 512 such blocks. Therefore, the system designer might need to allocate hundreds of seconds to the update process: this period of downtime is too long for many applications. Even applications that execute out of DRAM need to access the Flash memory on a regular basis, and such a long period of Flash downtime is not acceptable.


Separate Flash Memory Used for Code Storage for OTA Firmware

The ability to update while continuing to make the Flash memory available for read operations requires the provision of a separate memory device for the new firmware version, parallel to the existing firmware.

An obvious way to achieve this is to duplicate the main Flash used for code storage. A redundant Flash device sits alongside the primary Flash, and remains inactive except when called on to store the new image during an OTA update event. After the new image is successfully programmed, this redundant Flash will be designated as the primary Flash. The previous primary Flash will then be made redundant and inactive.

This method is safe, reliable and entails no risk of system failure. For this reason it is popular in systems that demand a high level of reliability and availability. Such an approach, however, has a higher bill-of-materials cost, and requires more board space, a new layout, and the use of an additional signal from the chipset to control the redundant Flash device. As designers face constant pressure to cut costs other approaches can achieve the same benefits at lower cost and with less complexity.

As stated above, an embedded system which needs OTA capability will normally include an external NOR Flash device for code storage. One solution to the problem is to create a partition within the NOR flash, producing a bank of memory blocks to support program/erase operations, and a separate bank to support read operations, both on the same die.

This is the architecture of a type of device known as Read While Write Flash. They are essentially two devices merged into one die and put in one package. Unfortunately, basic characteristics of Flash memory technology militate against this combination. Program/erase operations run at high voltage and current, and are very noisy. To execute read operations simultaneously without data corruption, the chip needs elaborate internal isolation, and in practice, noise invariably compromises performance and reduces operating frequency. Such an architecture also requires duplication of internal data paths and latches to enable concurrent operations. These additional circuits take up die area and drive up the cost of the product.

In practice, Read While Write Flash devices have fallen out of favour due to the use of a less common bus interface which requires change to the board layout. Furthermore, very few chipsets support such special bus interface, limiting choices for system designers. While the use of Read While Write Flash supports the storage of two code images as well as providing read access from one image while updating the other, such benefits are negated by higher cost, design changes, and limited chipset availability.


SpiStack Stacked Dies for OTA

The challenges of supporting OTA implementation on a single Flash device, two Flash devices or Read While Write Flash have led Winbond to introduce a version of its SpiStackTM product which stacks two identical Flash dies in a single package, using a single Chip Enable signal (/CS). At the hardware abstraction level, it appears to be a single Flash device. The selection of one of the two dies is managed by the system software.

With this architecture, one die can perform program/erase operations while the other performs read operations simultaneously. Because the memory capacity is provided in two separate dies, noise problems are eliminated and concurrent operation can be executed at high speed.

Various Flash manufacturers have developed stacked-die offerings: the advantage of stacking Flash dies is that higher densities can be offered in the same package as that in which single-die Flash products are housed. This means that, for instance, an embedded system which uses a single-die 256Mbit NOR Flash device for code storage housed in an 8mm x 6mm WSON package can be replaced by  a 512Mbit SpiStack device in the same package. The two-die device will support Read While Write operation for OTA updating without suspension of read operations and with no risk of losing the existing firmware image in the event of an unexpected power interruption.

This meets the important requirements of industrial and automotive systems. But how are the two dies controlled by the host chipset? If a Chip Select (/CS) signal from the chipset is required for each die, there will be one more pin on the Flash device – so an 8-pin package will be replaced by a higher pin count package in order to support the extra pin connection to the chipset.

Replacing an 8-pin Flash with a higher pin count Flash device calls for a board re-design. And for some systems, there is no spare pin at the chipset available to drive the /CS signal to the second die. So while the stacked die option appears attractive, if it requires an additional /CS pin, it will be at best inconvenient to integrate into the system design, and at worst impossible.


the C2h Chip Select command uses a unique ID for each die in a SpiStack multi-chip package.

Fig. 2: the C2h Chip Select command uses a unique ID for each die in a SpiStack multi-chip package. (Image credit: Winbond)


To avoid this problem, Winbond developed the software Chip Select technique implemented in its SpiStackTM products, through a special C2h command.  This software command directs the Chip Select operation from one die to the other based on an 8-bit Die ID (see Figure 2). Both dies interface to the host chipset over the same pin connections. This means there is no need for an extra pin, so no need for a board re-design when upgrading to support OTA updating capability, and no need to occupy an additional /CS pin (see Figure 3). Instead, the operating system uses a global variable and an area in the Flash to track which die is currently active.

implementing the Chip Select function in software requires only one Chip Select (CS) pin.

Fig. 3: implementing the Chip Select function in software requires only one Chip Select (CS) pin. (Image credit: Winbond)


SpiStack technology is available in the form of the W25M512JVxxx and W25M512JW products. Other combinations are also available on request for NOR (and NAND) Flash, and in industry-standard packages and pin-outs, including WSON8 and BGA24.


The Ideal Way to Implement OTA Updates

The implementation of OTA updating in industrial and automotive systems calls for a memory architecture which supports continued operation while updatingand with storage of the updated firmware in non-volatile memory while retaining the previous firmware image. The ideal way to implement this feature without the need for a board re-design while maintaining system operation at high speed is to use a redundant die-stacking approach with software control of the Chip Select (/CS) pin – a solution enabled by the SpiStackTM family of products from Winbond.

Datasheets please click W25M512JVxxx and  W25M512JW for more details.

by Jackson Huang, Senior Director of Marketing, Winbond Electronics America

Jackson Huang is the Senior Director of Technical Marketing at Winbond.  With over 25 years of experience in marketing for automotive, consumer, and industrial products, Jackson focuses in managing and driving critical marketing functions to achieve revenue and market share goals.  Prior to joining Winbond Jackson was the Vice President of Marketing for Product Marketing, Segment Marketing, and Ecosystems Development at Cypress and Spansion.  Jackson held various marketing management positions at Trident Microsystems and Advanced Micro Devices for SoC and memory products.  Prior to moving to technology marketing, Jackson was a senior engineer at Fujitsu Microelectronics and Watkins Johnson where he worked on 32 bit MCUs and radar signal processing systems. Jackson is the co-inventor of three flash patents and holds a BS in electrical engineering from the University of Michigan Ann Arbor and MBA in marketing and international business from Santa Clara University.


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

Technical Articles

Contact us

Copyright © Winbond All Rights Reserved.

This website uses cookies to ensure you get the best experience on our website. Learn more