Here is how design engineers can implement over-the-air (OTA) firmware updates for a microcontroller using the "staging + copy" method.

Here is how design engineers can implement over-the-air (OTA) firmware updates for a microcontroller using the “staging + copy” method. The microcontroller—NXP’s RW612 in this design case study—relies on external serial flash. The article highlights the use of NXP’s ROM-resident FlexSPI API to safely erase and program the flash without bricking the device.

Figure 1 RW612 is a wireless microcontroller with an Arm Cortex-M33 application core. Source: NXP

For a practical application of OTA implementation, check the complete video tutorial that explains how to implement a remote firmware update. In this video, we use the NXP FRDM-RW612 development board with Mongoose Wizard, but the same method applies to virtually any other NXP microcontroller.

OTA firmware update

If you are looking for a practical OTA firmware update example, this article shows a simple “staging + copy” method on the NXP RW612 microcontroller using external FlexSPI flash. It matches what the FRDM-RW612 board setup looks like in real life, and it points to the exact Mongoose source file (ota_rw612.c) that implements the flow.

Figure 2 The FRDM-RW612 development board is designed for rapid prototyping with the RW61x family of wireless microcontrollers. Source: NXP

OTA firmware updates let you ship fixes and features without asking users to plug in a debugger. On Wi-Fi MCUs, such as NXP RW612, OTA is also one of the first things you want because it unlocks faster iteration during development.

There is no single “correct” OTA design. Different products pick different strategies depending on flash size, how paranoid you are about power loss, and how strict your security requirements are. Here are a few common patterns you will see in the wild:

• In-place update (single slot): Download the new firmware and overwrite the currently running image. This uses the least flash, but it has the highest risk; if power is lost while you erase or program, you may brick the device unless a bootloader can recover.
• Staging + copy: Download the new image into a staging area (an “inactive” region), verify it, and then copy it over the active firmware region. This is a very common and practical method because the device keeps running the old firmware while the download happens, and you only switch after you have a complete, verified image.
• A/B (dual slot): Split flash into two full firmware slots and select which one to boot. It’s viable when you can afford the space, because rollback can be as simple as flipping a flag. It does, however, require enough flash for two complete images plus metadata.
• Delta updates: Download only the binary diff from the old version to the new version and reconstruct on the device. Great for saving bandwidth, but the tooling and edge cases can get complicated fast.

In this article, we focus on the staging + copy approach because it’s easy to reason about, does not require two complete bootable slots, and maps nicely onto RW612 designs with external serial flash.

A minimal staging + copy flow looks like this:

1. Reserve a staging region in external flash plus a tiny metadata area.
2. While running the current firmware, download the new firmware into the staging region.
3. Verify the staged image (signature and/or CRC, size checks, and version rules).
4. Reboot into a small bootloader or early-boot update routine.
5. Copy the staged image over the active firmware region, update metadata, and then boot the new firmware.

Here is a practical note: the easiest way to create a staging area is to split the external flash into two partitions. You keep the active firmware in the first partition and use the second partition as the staging area for the download. After verification, you copy from the second partition back into the active region during reboot.

If power is lost during the download, you still have the old firmware. If power is lost during the final copy, a well-designed bootloader can retry the copy or fall back to a known-good image (depending on your layout and policy). Either way, the goal is the same: avoid bricking devices.

External flash and FlexSPI ROM API

A key RW612 detail that influences OTA design: RW612 does not have built-in internal flash for your application image. Instead, designs typically use external serial NOR flash connected over FlexSPI. The FRDM-RW612 development board, for example, includes external serial flash (Winbond) on the board. That means your OTA code ultimately needs to erase and program external NOR flash.

The nice part is that NXP provides a ROM-resident API that can operate that flash through FlexSPI. In the MCUXpresso SDK documentation, you will see this described as the ROM API driver for external NOR flash connected to the FlexSPI controller, with support for initialize, program, and erase operations.

Why a ROM API matters: when you update flash, you want the programming logic to be as reliable as possible. ROM-resident routines are not stored in external flash, so they can still run safely while you are erasing and programming the external device.