The NXP i.MX RT Crossover MCU Positioning

The i.MX RT line is NXP’s crossover family. Each part runs an application-class Cortex-M7 at hundreds of megahertz, sometimes past a gigahertz, with the simple boot and bare-metal programming of a microcontroller. It sits in the space between a general-purpose MCU and a Linux application processor. That position is the whole point of the part.

What a crossover MCU is

A crossover MCU solves a recurring problem. A design grows past what a general-purpose microcontroller can do, in raw clock speed, in memory, or in graphics. The next class up is a full application processor that runs Linux, on a bigger board, with a longer boot and a heavier power budget. NXP built the i.MX RT to land in the space between the two. It carries the speed of the larger class inside a part that boots and programs like a microcontroller. NXP brought the first i.MX RT parts out in 2017 and named the category at the same time. The name stuck. Other vendors now group their own high-speed, externally-flashed parts under it. The shape of the answer is the same across all of them: high-end compute that a small team programs like any microcontroller.

The idea has a precise shape. The processor is an Arm Cortex-M7, the same core family ST puts in the STM32H7 and Microchip puts in the SAM E. NXP clocks it high, from 500 MHz on the entry parts to 1 GHz on the flagship. The core is a true microcontroller core, so it starts in microseconds, runs from interrupt to interrupt with hard real-time timing, and needs no operating system underneath it. Clocked at a gigahertz, the M7 turns in compute a general-purpose MCU cannot reach, on the order of several thousand CoreMark. Measured on integer work, the numbers sit in entry application-processor range. The rest of the picture is everything around the core: no MMU running a general operating system, no DRAM controller as a hard requirement, and a deterministic interrupt path the application class trades away.

The part that surprises a newcomer is the memory. An i.MX RT carries no on-chip program flash. The code lives in an external flash chip and runs from it through a fast serial bus, an arrangement the trade calls execute-in-place. On-chip there is a large block of fast SRAM, from 128 KB on the small parts to 2 MB on the flagship, with a slice of it set aside as tightly-coupled memory for the code that has to run at full speed. The SRAM is the working memory. On many parts a developer splits it between general use and tightly-coupled banks at build time. The flexibility matters, since the balance between cache-backed external code and on-chip critical code is set per design. A part with 1 MB of SRAM can hold a large working set entirely on-chip, leaving the external flash to carry the bulk program and any read-only data.

That memory choice is the whole trick. Leaving flash off the die lets NXP push the process to a fast, dense node and clock the core high, at a low cost per part. The external flash can be sized to the job, from a few megabytes to many, far past what fits on a normal microcontroller. In exchange, the part needs a boot step that copies or maps the code, and it depends on that external chip. The tools and the silicon handle both as a matter of course. The boot ROM supports several external memory types, so a design chooses the flash to fit its cost and speed. The bus has two common speeds. A serial NOR flash on a Quad SPI bus is the everyday pick. An Octal or HyperBus flash runs faster, for a program that needs the bandwidth. The same controller can map an external SDRAM as well, for a working set larger than the on-chip SRAM.

So the crossover is not a faster microcontroller and not a smaller application processor. It is a third category, sitting between the two. A design reaches for one when a general-purpose MCU has run out of headroom. A Linux processor brings the compute, on a bigger board, with a longer boot and a heavier power budget. The part is for the design caught in that gap, with no comfortable home in either class. The rest of this page fills in that one idea: the family, the memory model, the jobs it does, and the parts it sits next to.

The i.MX RT family, entry to flagship

The family runs as a ladder. At the bottom, the i.MX RT1010 puts a 500 MHz Cortex-M7 in a small, low-cost package, aimed at audio and simple control. The mid-range RT1060 climbs to 600 MHz with a megabyte of SRAM and a deep set of peripherals, two Ethernet controllers, USB, CAN-FD, and a graphics interface among them. The RT1064 carries the one exception to the no-flash rule: a stacked 4 MB flash sits inside the package, so the speed comes with the flash already on board. Between the entry and the mid-range sit the RT1020 and RT1050, filling out the clock and peripheral steps so a design moves up by small increments. NXP also runs a second crossover branch, the RT500 and RT600, built on a Cortex-M33 paired with a Cadence Tensilica audio DSP. Those parts aim at always-on voice and audio machine-learning work, where the DSP carries the signal load. The whole range shares one toolchain and one programming model, so a move within it stays cheap.

At the top sits the RT1170. NXP put two cores on it, a Cortex-M7 at 1 GHz and a Cortex-M4 at 400 MHz, and called it the first crossover MCU to reach a gigahertz. It carries 2 MB of SRAM, a 2D graphics accelerator, and a hardware security block NXP calls EdgeLock. The two cores split the work, one carrying the heavy application load, the other the always-on real-time housekeeping at low power. The split is the same idea ST and others use on dual-core parts, applied to the crossover class. A graphics-heavy product maps its work across the two: the GUI and application stack on the M7, the sensor polling, motor timing, or communications stack on the M4. The M4 keeps running when the M7 sleeps, so the average power stays low on a battery or always-on product. EdgeLock adds a separate security domain, with key storage and a hardware root of trust the application code cannot reach directly.

Running from external memory

The execute-in-place arrangement deserves a closer look, since it shapes how an i.MX RT design is built. At reset, a small boot ROM inside the chip reads the external flash over the serial bus and sets up the system. From there the core fetches instructions straight from that flash, with a cache in front of it to hide the latency. The flash sits on a Quad or Octal SPI bus, fast enough that a well-cached program runs at close to full core speed. The cache sits between the core and the slow external bus, holding recently-used code and data on-chip. When the data is cached, the fetch returns in a cycle or two. When it is not, the core reaches out to the flash over the serial bus, an order of magnitude slower, the reason critical code goes elsewhere. The FlexSPI controller that drives the flash supports several protocols and both single and dual flash chips, so a design tunes the memory bandwidth to the job.

The Cortex-M7 at the centre of the part fits this work exactly. Arm designed the Cortex-M7 as a six-stage, dual-issue superscalar core, able to start two instructions at once, with optional instruction and data caches and tightly-coupled memories. Those caches and TCMs are what let a part with no local flash still hit hard real-time deadlines. Code that must never wait for the external bus is placed in the TCM, where it runs at full speed every time. The data caches help the same way on buffers and tables a program touches often. The result is a part that holds its gigahertz clock on real code, well past the first cache miss. Arm’s design is the reason the trick works: the M7 sits behind caches and feeds from them by design, which is exactly what the no-internal-flash arrangement asks of it.

Security rides on the same external-memory design. Code stored off-chip could be read or swapped, so the i.MX RT parts carry a hardware path that checks and decrypts the flash image on the way in. Two features handle it. The secure-boot chain verifies a signature before the code runs. The encrypted-XIP feature decrypts instructions on the fly as the core fetches them. A product that has to protect its firmware gets the machinery on the chip. The fuses inside the part hold the keys and the boot configuration, blown once at provisioning. NXP supplies tools that handle the signing and the key loading, so a small team can stand up secure boot from ready-made pieces. The same path covers a secure firmware update in the field, with each new image checked before it is allowed to run. For a connected product, the security story is part of why the i.MX RT reaches markets a bare microcontroller cannot.

The arrangement asks for a little board work in return. The external flash takes its own footprint, its own routing on a fast bus, and its own place in the bill of materials. A design that has only ever used a flash-on-chip microcontroller plans for that part early. The payoff is a memory size set by the external socket, large enough for a graphics-heavy or data-heavy product to stretch out. The board cost of that extra chip is small next to the capability it unlocks. A serial flash in a small package adds cents and a few square millimetres. The routing follows the rules for any fast serial bus, with length matching and clean returns, which the EVK layouts show by example. A team treats the flash as a permanent member of the design, qualified and second-sourced like any other critical part.

Where the crossover earns its place

The i.MX RT shows its value in a few clear jobs. A colour touchscreen interface is the common one, where the graphics accelerator and the memory bandwidth drive a smooth GUI. Audio products use the fast core and the rich audio interfaces for low-latency processing. Motor and power control use the speed for tight, fast loops across several axes. Edge machine-learning work runs neural-network models on the M7, fast enough for vision and audio inference, at a microcontroller’s cost and boot time. Each of these sits in the same gap, in the band the crossover owns. A point-of-sale terminal, a smart thermostat, a handheld medical readout, an industrial panel, a voice front-end: each one wants a sharp display or fast signal work on a fixed budget. The crossover gives them a colour UI, room for a model or a codec, and a boot fast enough that the product feels instant. A small team programs it with ordinary microcontroller skills. The list grows as displays and on-device inference reach further down into everyday products.

Above the MCU, below the processor

The clearest way to place the i.MX RT is by its neighbours. Just below it sits the high-end microcontroller, the STM32H7 and its peers, a Cortex-M7 with on-chip flash at a few hundred megahertz. An i.MX RT goes further on clock speed and on memory size, since the external flash lifts the ceiling the on-chip flash sets. A design picks the crossover when the high-end MCU has run out of exactly those two things. The numbers behind that line are concrete. The high-end MCU tops out near a few hundred megahertz and a couple of megabytes of on-chip flash. The crossover starts where that ceiling ends, running to a gigahertz, with external flash in the tens of megabytes. If a design fits the smaller envelope, it stays on the MCU, where one chip and on-chip code keep the board simplest. If it needs the larger envelope, the crossover is the smallest, cheapest step up.

Just above it sits the application processor, the i.MX 6 and i.MX 8 and their like, parts that run Linux on a Cortex-A core. That class brings more raw compute and a full software stack, on a multi-layer board with external DRAM, a power-management chip, and a boot measured in seconds. If a product needs that compute and that software, the processor is the right tool. If it needs fast deterministic control and a quick boot on a simple board, the crossover fits. The boot time and the power tell the same story. An i.MX RT runs application code within milliseconds of power-on. A sleep mode drops it to microamps between events. A product that switches on instantly, or that lives on a battery, reads those two numbers as the deciding ones.

Many positioning mistakes come from skipping a step. They fall into two shapes. One team reaches for an application processor it does not need and takes on a Linux build, a bigger board, and a longer schedule. Another pushes a general-purpose MCU past its limits and loses the fight for clock speed and memory. The i.MX RT suits a design that has read both limits honestly and landed in the middle. The honest read is two questions. Does an ordinary microcontroller have the speed, the memory, and the graphics the product needs? Does the product need a general operating system and the software that runs on one? A no to the first and a no to the second points straight at the crossover. The i.MX RT is the part that answers that exact pair.

The bare-metal model and its tools

Development on an i.MX RT follows the microcontroller model. NXP’s MCUXpresso suite covers it, the same IDE, SDK, and config tools that serve the LPC and Kinetis lines, so a team already on NXP carries its flow straight across. A new project starts from a chip-support package and example code, builds with GCC or a commercial compiler, and debugs over a standard SWD probe. The external flash is programmed through the same tools, with the boot configuration handled by a setup the SDK generates. The config tools carry over from the rest of the MCUXpresso world. A graphical pin, clock, and peripheral editor writes the setup code. The SDK ships hundreds of driver and middleware examples, from a blinking LED to a USB stack or a graphics library. A team that has shipped an LPC or a Kinetis design opens the same windows and reads the same APIs, so the learning sits in the new peripherals, the graphics path, and the boot.

The model has one habit a newcomer should know. Because the code runs from external flash through a cache, a developer learns to place timing-critical routines in the tightly-coupled memory, where the cache never gets in the way. The SDK and the part’s documentation spell out how. A team that respects that one rule gets hard real-time behaviour at application-processor speed. That combination is the whole reason the crossover class exists. The linker script is where that habit shows. A developer marks the hot functions and the interrupt handlers to load into the TCM. The rest runs cached from external flash. NXP’s examples set this up already, so a first project gets the placement right from the start. Past that one rule, the part feels like any other Cortex-M7: the same compiler, the same debugger, the same RTOS choices, FreeRTOS or Zephyr or bare-metal. The crossover earns its name in that pairing: a microcontroller’s programming model, an application processor’s compute.