MCU Info Page: MIMXRT105x and 106x
This info page will cover NXP's MIMXRT105x and MIMXRT106x family of MCUs. These MCUs boast some of the highest clock rates of any Mbed-compatible processor on the market, as well as a huge array of capable peripherals. So, as long as you can handle their PCB requirements (complex power arrangement, external flash, large BGA package, etc) they're a very compelling option for your large and high-speed projects!
| CPU | Flash/Code Memory | RAM | Communication Peripherals | Other Features |
|---|---|---|---|---|
| Cortex-M7, clocked at up to 600 MHz |
Total: 4MiB (off of MCU) Available to user:* 3.94MiB |
Total: 30MiB (off of MCU) Available to user:* 29.98MiB |
|
|
*"Available to user" subtracts both regions of memory unusable by Mbed OS projects and the baseline memory used by a minimal build of Mbed OS.
NXP has created a fairly large family of MCUs with these chips, with only some small differences between them. Unfortunately, their docs aren't super good at explaining this. Here's a comparison table I've put together:
| Model | On-Chip Memory | Ethernet Count | XIP Flash Interface (FlexSPI) Count |
CAN | LCD Controller, GPU, and Camera Interface |
|---|---|---|---|---|---|
| MIMXRT1051 | 512MiB RAM | 1 | 1 | 2x Regular | No |
| MIMXRT1052 | 512MiB RAM | 1 | 1 | 2x Regular | Yes |
| MIMXRT1061 | 1MiB RAM | 2 | 2 | 2x Regular + 1x CAN FD | No |
| MIMXRT1062 | 1MiB RAM | 2 | 2 | 2x Regular + 1x CAN FD | Yes |
| MIMXRT1064 | 1MiB RAM + 4MiB Flash | 2 | 1 | 2x Regular + 1x CAN FD | Yes |
Basically, the MIMXRT1051 is the base model, and code compatible with it will run on any of the other chips. The other part numbers simply add features on top of that.
Note: There are also three different grades of these MCUs: 10xxD for consumer products, 10xxC for industrial products, and 10xxX for extended industrial applications. The D grade allows the full 600MHz frequency but has a limited temperature range. The C grade down-clocks to 528MHz but has a wider temperature range. Similarly, the X grade down-clocks to 500MHz but has an even wider temperature range.
The MIMXRT uses a fairly complex memory layout, and the way that the dev kit is set up only adds to this. However, you do gain the flexibility to use huge amounts of space in your Mbed program if you so desire!
Internally, the chip contains three RAM banks by default:
- 128kiB Instruction Tightly Coupled Memory (ITCM). This can be used to cache functions and execute them quicker than by running them out of flash. Functions can be placed here by preceding them with the
__attribute__((section("CodeQuickAccess")))attribute. This will caus ethe function to be loaded from flash into ITCM at boot, and then executed out of ITCM. - 128kiB Data Tightly Coupled Memory (DTCM). This can be used to store global data for the fastest possible access by the MCU core. Give declarations the
__attribute__((section("DataQuickAccess")))to place them here. - 256kiB OCRAM. This is a general-purpose memory bank that can be used to store anything. Currently the Mbed linker script does not place anything here.
Notice that I said "by default". That's because this memory is actually remappable! By changing fuses, you can adjust how the underlying storage is allocated between these three banks. Just remember that if you change the fuses, you'll have to modify the linker script to compensate...
On top of these banks, the MIMXRT106x devices add an additional, fixed 512MiB OCRAM2 bank to give you even more working area.
The MIMXRT1064, not content with that, includes a flash chip die within the processor package, giving you 4MiB of "internal" flash to work with.
The MIMXRT features lots of connectivity to external memories, and the dev kit does not disappoint in this respect.
As for RAM, the dev kit provides a 32MiB IS42S16160J-6BLI RAM chip connected to the SEMC (Smart External Memory Controller) peripheral. Mbed maps this as the main RAM for storing data, providing you a massive amount of space to work with in code.
For flash, the MIMXRT broadly supports two options: standard QSPI NOR flashes, and less standardized OSPI flashes (also referred to as HyperFlashes). The dev kit provides both: a 64MiB OSPI flash, the S26KS512SDPBHI02, and an IS25WP064AJBLE 8MiB QSPI flash. The OSPI flash is connected by default to the MCU's FlexSPI peripheral, and if you want to switch you'll have to move some resistors around on the PCB. See the MIMXRT1050-EVKB User Guide for details.
A note about names: Don't get confused! FlexSPI is the MIMXRT's interface for talking to SPI flashes. LPSPI is the peripheral for talking to regular SPI devices. And, last but not least, FlexIO is a configurable peripheral that can emulate, among other things, an SPI bus.
But what is it that makes these memory peripherals "flexible" and "smart", you ask? Why, that's because they can actually be reconfigured at runtime, before the code even boots!
The FlexSPI configuration data is stored in the first 512 bytes of the flash device (see MIMXRT reference manual section 9.6.1.2 for details). It contains the basic flash size and width information, as well as the command sequences that the hardware will use to start up the flash and read data from it. This structure is stored here in the Mbed code, and it is placed by the linker into the very start of flash.
If you want to switch your MCU to use the QSPI flash, you'll need to remove the HYPERFLASH_BOOT define using a custom target, which will cause the QSPI version of the flash config data to be used instead.
The SEMC configuration, meanwhile, is stored in a different section of the program: the DCD, or Device Configuration Data. This structure basically specifies an arbitrary series of memory writes that the MCU will execute before starting the program, and is usually used to configure the RAM and/or do other low-level setup. The DCD is stored as C code here, and can be generated/modified using NXP's MCUXpresso Config Tools application. As before, the linker script is configured to place this data into the first part of flash so that the MCU can find and execute it.
Note: It seems like it'd be worthwhile to create an Mbed target that allows one to disable the external SEMC memory and just use the MCU's internal memory, for ease of creating custom boards without a RAM chip. Currently this does not exist but a PR for it would be welcome!
Mbed OS uses all four channels of the Periodic Interrupt Timer (PIT) peripheral to implement the microsecond ticker. This peripheral is therefore unavailable for user code to use.
The MIMXRT uses a very unusual naming scheme for its GPIO pins, where pins are named according to their primary function:
- GPIO_AD_xx pins contain ADC inputs and the analog comparators
- GPIO_EMC_xx pins contain SEMC (the external RAM controller) inputs and outputs
- GPIO_SD_xx pins contain SD card (EMMC) inputs and outputs
- GPIO_Bxx is the catch-all IO port and doesn't have a specific theme
I appreciate what they were going for here, but I feel like it can make things more confusing by forcing you to remember a more complicated name...
- MIMXRT1051/52 Datasheet: IMXRT1050CEC.pdf
- MIMXRT1061/1062 Datasheet: IMXRT1060XCEC.pdf
- MIMXRT1064 Datasheet: IMXRT1064CEC.pdf
- MIMXRT105x Programmmer's Reference Manual: MIMXRT1050RM.pdf (registration required)
- MIMXRT1050-EVKB User Guide: MIMXRT1050EVKBHUG.pdf (registration required)
- MIMXRT1050-EVKB Design Files Rev B1 RT1050EVKB-DESIGNFILES-B1.zip
- MIMXRT1050-EVKB Schematic Rev A1 SPF-30168_A1.pdf