NXP RW612 OTA Firmware Update

If you are looking for a practical NXP RW612 OTA firmware update example, this article shows a simple "staging + copy" method on the NXP RW612 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.

Over-the-air (OTA) firmware updates let you ship fixes and features without asking users to plug in a debugger. On Wi-Fi MCUs like the NXP RW612, OTA is also one of the first things you want working 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, 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 is great 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 is 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, version rules, etc.).
4. Reboot into a small bootloader or early-boot update routine.
5. Copy the staged image over the active firmware region, update metadata, then boot the new firmware.

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.

RW612 OTA specifics - external flash and the 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 ROMAPI 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.

References for RW612 and FlexSPI ROM API (MCUXpresso SDK):

• RW612 datasheet (notes off-chip XIP flash and FlexSPI interface): https://www.nxp.com/docs/en/data-sheet/RW612.pdf
• FRDM-RW612 board user manual (mentions external serial flash on the board): https://www.mouser.com/pdfDocs/NXP_FRDM-RW612_UM.pdf
• MCUXpresso SDK ROMAPI driver reference (external NOR over FlexSPI): https://mcuxpresso.nxp.com/api_doc/dev/2349/a00044.html
• MCUXpresso SDK romapi examples index: https://mcuxpresso.nxp.com/mcuxsdk/25.03.00/html/examples/driver_examples/romapi/index.html
• MCUXpresso SDK romapi_flexspi example readme: https://mcuxpresso.nxp.com/mcuxsdk/25.03.00/html/examples/driver_examples/romapi/flexspi/readme.html
• MCUXpresso SDK fsl_romapi example readme: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/examples/driver_examples/fsl_romapi/readme.html

Practical layout tip for RW612 OTA: treat the external flash as your update playground. Reserve space for the active firmware, a staging region, and a small metadata area that records the update state. Keep the metadata redundant (two copies, versioned records, or a simple log) so you can survive an interrupted write.

Mongoose RW612 OTA example - staging + copy on FRDM-RW612

If you want something you can build and run quickly, Mongoose includes a working RW612 OTA implementation that demonstrates the staging + copy method on the FRDM-RW612 board. The walkthrough video is at the beginning of this article and the implementation lives in https://github.com/cesanta/mongoose/blob/master/src/ota_rw612.c.

High level, the Mongoose RW612 OTA example does three jobs:

1. Receive the new firmware image over the network.

   The transport can be HTTP, HTTPS, or whatever your product uses. In a typical Mongoose setup you stream the incoming bytes straight to the staging region in external flash so you do not need a giant RAM buffer.

2. Write the new image into the staging region using the FlexSPI ROM API.

   The OTA code erases the destination region (sector erase) and programs data (page program) as the download progresses. This is the part that is RW612-specific: you use the ROMAPI FlexSPI routines to safely erase and program the external serial NOR flash.

3. Copy staged firmware to the active region and switch over.

   After the image is fully written and verified, you reboot. Early in boot, the update routine copies the staged image to the active firmware region using the same FlexSPI ROM API. Finally, metadata is updated so the device knows the update completed, and the new firmware boots.

A few practical details that are worth copying into your own RW612 OTA design:

Stream to flash. Do not buffer the whole image in RAM. Erase in sector-sized chunks and program in page-sized chunks as data arrives.

Verify before you copy. At minimum store and check a CRC of the downloaded image. For production, verify a signature and enforce anti-rollback rules if needed.

Make the update state robust. Store update metadata in a small dedicated region (for example: "no update", "downloaded", "copy in progress", "done"). Consider writing metadata as an append-only record or keep two copies and alternate between them so you can recover from a power cut during the metadata update.

Handle power loss during the final copy. A common trick is to mark "copy in progress" before you start copying, then if the device reboots unexpectedly, the boot code can resume the copy from where it left off, or restart it safely. Another trick is to copy in fixed chunks and persist progress.

If you just want to see it working, start with the demo video, then open ota_rw612.c and trace the flow: where the image bytes land in external flash (staging), how the ROMAPI based erase and program calls are made, and how the staged image is copied over the active region during reboot.

That is RW612 OTA done in a way that is simple, resilient, and easy to productize.