NXP i.MX RT

The i.MX RT series of chips from NXP Semiconductors is based around an ARM Cortex-M7 core running at 500 MHz, 600 MHz or 1 GHz based on particular MCUs

Supported MCUs

The following list includes MCUs from i.MX RT series and indicates whether they are supported in NuttX

MCU	Support	Core	Frequency
RT500	No	Cortex-M33	200 MHz
RT600	No	Cortex-M33	300 MHz
RT700	No	Cortex-M33	325 MHz
RT1010	No	Cortex-M7	500 MHz
RT1015	No	Cortex-M7	500 MHz
RT1020	Yes	Cortex-M7	500 MHz
RT1024	No	Cortex-M7	500 MHz
RT1050	Yes	Cortex-M7	600 MHz
RT1060	Yes	Cortex-M7	600 MHz
RT1064	Yes	Cortex-M7	600 MHz
RT1160	No	Cortex-M7 + M4	600 Mhz + 240 MHz
RT1170	Yes (Only M7)	Cortex-M7 + M4	1 GHz + 400 MHz
RT1180	Yes	Cortex-M7 + M33	800 Mhz + 300 MHz

i.MX RT118x

The i.MX RT118x family is supported on both the Cortex-M33 and Cortex-M7 cores. The Cortex-M33 is the boot core; it can run NuttX directly, or it can run a small bootloader that releases the Cortex-M7 to run a separate NuttX image.

The current clock configuration runs the Cortex-M7 at 798 MHz and the Cortex-M33 at 266 MHz due to ARM_PLL and divider setting limitations.

RT118x uses the generation 3 clock configuration driver for the clock roots found on this family. It also uses the generation 3 IOMUXC driver for the RT118x pinmux layout and GPIO mode selection.

RT118x uses the RGPIO driver and the matching RGPIO interrupt driver instead of the legacy i.MX RT GPIO block. The version 2 eDMA driver is selected for the newer RT118x eDMA IP.

The EdgeLock Enclave driver provides the messaging path used for RT118x ELE firmware, and the TRDC driver configures access to RT118x memory and peripheral resources. The Cortex-M7 release helper is used by Cortex-M33 firmware to set the Cortex-M7 boot vector and start the M7 core.

Data and Instruction Cache

Supported i.MX RT MCUs provide separate instruction and data caches. The data cache is configured as write-back by default where supported, but it can be changed to write-through via Kconfig.

Write-back data cache generally provides better performance than write-through, but care must be taken because not all peripheral drivers and DMA users may be safe with write-through caching unless proper cache maintenance is implemented.

Some devices in the i.MX RT10xx series do not support write-through data cache reliably due to an Arm erratum. On those parts, write-back should be used instead.

Newer devices, such as the i.MX RT1170, support write-through data cache operation correctly.

Tickless OS

With Tickless OS, the periodic, timer interrupt is eliminated and replaced with a one-shot, interval timer, that becomes event driven instead of polled. This allows to run the MCU with higher resolution without using more of the CPU bandwidth processing useless interrupts.

Only tickless via an alarm is currently supported for i.MX RT MCU, which can be selected by CONFIG_SCHED_TICKLESS_ALARM option. CONFIG_USEC_PER_TICK option determines the resolution of time reported by clock_systime_ticks() and the resolution of times that can be set for certain delays including watchdog timers and delayed work. It is important that value set in CONFIG_USEC_PER_TICK represents the frequency of GPT timer that runs the tickless mode. Clock source of the timer is 16.6 MHz, which is then divided by the prescaler value from 1 to 4096. Possible values for CONFIG_USEC_PER_TICK are 10 or 100 for example.

Peripheral Support

The following list indicates peripherals supported in NuttX:

Peripheral	Support
ACMP	No
ADC	Yes
CAN	Yes
CSI	No
DAC	No
eLCDIF	Yes
ENC	Yes
ENET	Yes
FlexIO	Yes
GPIO	Yes
I2S	Yes
PWM	Yes
SAI	No
SPDIF	No
SPI	Yes
UART	Yes
uSDHC	Yes
USB	Yes

ACMP

The circout for comparing two analog input voltages designed to operate across the full range of supply voltage (rail-to-rail operation).

ADC

ADC driver with the successive approximation analog/digital converter. The lower-half of this driver is initialize by calling imxrt_adcinitialize().

ADC module can use either continuous trigger (next conversion is started as soon as the previous is finished) or hardware trigger. This option is selected by IMXRT_ADCx_ETC (x = 1, 2) config option. If IMXRT_ADCx_ETC = -1 then continuous trigger is used. If corresponding XBAR number is put in IMXRT_ADCx_ETC then that signal is used to trigger the ADC conversion (for example PWM signal can be used as a source). For PWM XBAR options please refer to PWM chapter of this documentation.

Hardware triggering is currently limited to maximum of 8 channels. HW trigger is automatically disabled if there are more than 8 channels.

DMA is currently not supported for ADC modules.

CAN

FlexCAN driver is supported in MCUs i.MX RT1020 and higher. i.MX RT106x have both classical CAN and also one CAN FD while i.MX RT1170 have 3 CAN FD peripherals. FlexCAN driver in imxrt works beyond SocketCAN driver layout. The lower-half of this driver is initialize by calling imxrt_cannitialize().

There is an booting option that automatically provides initialization of network interface in the early stages of booting and therefore calling imxrt_cannitialize() via board specific logic is not necessary. This however works only when there is only one interface in the chip. For running more interfaces (like CAN and Ethernet), network late initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific logic must call lower-half part of drivers.

CSI

CMOS Sensor interface which enables the chip to connect directly to external CMOS image sensors.

DAC

Digital/analog converter for external signal is only supported in i.MX RT1170 MCU. It is 12 bit lower power, general purpose DAC.

eLCDIF

The enhanced Liquid Crystal Display interface (LCDIF) is a general purpose display controller.

ENC

The enhanced quadrature encoder/decoder module supported in i.MX RT1015 and higher. The lower-half of this driver is initialize by calling imxrt_qeinitialize().

ENET

Ethernet driver supported in i.MX RT1020 and higher. The lower-half of this driver is initialize by calling imxrt_netnitialize().

There is an booting option that automatically provides initialization of network interface in the early stages of booting and therefore calling imxrt_cannitialize() via board specific logic is not necessary. This however works only when there is only one interface in the chip. For running more interfaces (like CAN and Ethernet), network late initialization must be turn on by CONFIG_NETDEV_LATEINIT and board specific logic must call lower-half part of drivers.

FlexIO

A configurable module providing a range of functionality like emulation of a variety of serial/parallel communication protocols, flexible 16-bit timers or programmable logic blocks. This module is supported in i.MX RT1010 and higher.

GPIO

Pins can be configured using imxrt_config_gpio() function. Writing to pins is done by imxrt_gpio_write() function and reading is done by imxrt_gpio_read().

MCUs i.MX RT1060 and higher includes both standard speed GPIOs (1-5) and high speed GPIOS (6-9). Regular and high speed GPIO share the same pins (GPIO1 is with GPIO6 etc), therefore IOMUXC_GPR_GPR26-29 registers are used to determine what module is used for the GPIO pins.

I2C

Inter-Integrated Circout module supporting an interface to an I2C bus as master and/or as a slave. The lower-half of this driver is initialize by calling imxrt_i2cbus_initialize().

PWM

Pulse width modulator supported in i.MX RT1010 and higher. Multiple channels option is available. Output on pin B is currently supported only as a complementary option to pin A. The lower-half of this driver is initialize by calling imxrt_pwminitialize().

PWM module can be synchronized by an external signal. The external signal used for synchronization is selected by IMXRT_FLEXPWMx_MODx_SYNC_SRC config option. The number in IMXRT_FLEXPWMx_MODx_SYNC_SRC corresponds with the XBAR number. Following numbers can be used for synchronization of PWMs with other PWM module when using iMXRT1020, iMXRT1050 or iMXRT1060.

PWM1 Module 1 = 40
PWM1 Module 2 = 41
PWM1 Module 3 = 42
PWM1 Module 4 = 43
PWM2 Module 1 = 44
PWM2 Module 2 = 45
PWM2 Module 3 = 46
PWM2 Module 4 = 47
PWM3 Module 1 = 48
PWM3 Module 2 = 49
PWM3 Module 3 = 50
PWM3 Module 4 = 51
PWM4 Module 1 = 52
PWM4 Module 2 = 53
PWM4 Module 3 = 54
PWM4 Module 4 = 55

iMXRT1170 has different XBAR connections:

PWM1 Module 1 = 74
PWM1 Module 2 = 75
PWM1 Module 3 = 76
PWM1 Module 4 = 77
PWM2 Module 1 = 78
PWM2 Module 2 = 79
PWM2 Module 3 = 80
PWM2 Module 4 = 81
PWM3 Module 1 = 82
PWM3 Module 2 = 83
PWM3 Module 3 = 84
PWM3 Module 4 = 85
PWM4 Module 1 = 86
PWM4 Module 2 = 87
PWM4 Module 3 = 88
PWM4 Module 4 = 89

Option IMXRT_FLEXPWMx_MODx_TRIG allows the module to generate a trigger signal. The trigger is generated on timer capture of either period or duty cycle value based on the configuration.

SAI

Synchronous audio interface provided by I2C module. Supported in i.MX RT1015 and higher.

SPDIF

Sony/Philips digital interface audio block. It is a stereo transceiver that allows the processor to receive and transmit digital audio. Supported in i.MX RT1010 and higher.

SPI

Serial Peripheral interface module that supports an interface to an SPI bus as a master and/or a slave. The lower-half of this driver is initialize by calling imxrt_lpsibus_initialize().

UART

Universal Asynchronous Receiver/Transmitter module. UART is initialized automatically during MCU boot.

uSDHC

The uSDHC driver provides SD/MMC support and is available on the i.MX RT118x. The i.MX RT1180 EVK NSH configuration enables USDHC1 for its onboard MicroSD socket.

USB

Console communication over USB is supported via CDC-ACM. Only USB Device is currently supported for i.MX RT in NuttX

Multicore: RT1170 CM4 over RPTUN

The i.MX RT1170 pairs the Cortex-M7 with a Cortex-M4. NuttX runs on the CM7 and can load, release and hold a firmware on the CM4 through the NuttX RPTUN device on top of the OpenAMP framework (CONFIG_IMXRT_RPTUN, which selects CONFIG_RPTUN_LOADER). The CM4 firmware is the virtio device side and provides the resource table in its ELF image; it may be bare metal. The table must carry a carveout resource for the shared window after the table: NuttX 13 rptun places the vrings and the rpmsg buffers in it and refuses the device without it, NuttX 12.12 rptun parses it and lays out the window on its own.

The board registers the remote with imxrt_rptun_init(), passing the remote name, the ELF path, the address environment (CM4 device addresses to CM7 physical addresses), the boot vector and whether to autostart. The option is offered only on parts with a CM4 (IMXRT_HAVE_CM4) and selects DEV_SIMPLE_ADDRENV for libmetal. The driver:

Programs the boot vector into IOMUXC_LPSR_GPR0/1 and reads it back.
Releases the core with SRC_SCR.BT_RELEASE_M4. The slice stays under reset until its first release and cannot be held again afterwards: a software reset of the slice is a pulse after which the core restarts from the boot vector. To stop the core the driver writes a wfi loop over the start of the image and pulses the reset, so the core parks there until the next start reloads the image. A reset completion is awaited only when restarting a core that was already released.
Keeps a CM4 lockup local by setting SRC_SRMR so it does not reset the whole chip.
Exchanges virtqueue kicks with the CM4 on MU-A channel 0. Neither side reads the mailbox word; a kick into a full mailbox is coalesced with the pending one and the receiver rescans every virtqueue. The CM4 firmware must therefore read MU-B RR0 before it scans, so that a kick coalesced during the scan is covered by it.
Starts the remote from rptun_initialize() when the board sets autostart; otherwise RPTUNIOC_START on /dev/rptun/<name> or rptun_boot() starts it.

The fmu-v6xrt:rptun configuration is the reference user: imxrt_cm4_initialize() in the board bring-up registers /dev/rptun/cm4 with the memory map below, maps the shared window non-cacheable and leaves the core held. Copy an ELF built for the CM4 to the SD card as CONFIG_FMU_V6XRT_CM4_FIRMWARE (/mnt/sd/cm4.elf), then from nsh:

mount -t vfat /dev/mmcsd0 /mnt/sd
rptun start /dev/rptun/cm4
rptun ping /dev/rptun/cm4 100 64 3 0

Memory map rules the board must follow:

The CM7 reaches the CM4 TCM through the LMEM backdoor window at IMXRT_OCRAM_M4_BASE. Only the first 128 KB of that window, the CM4 code TCM, is reachable; writes to the second half do not reach the system TCM. The resource table, vrings and rpmsg buffers must live in the code TCM.
The CM4 boots from the backdoor alias of its code TCM (0x20200000), as NXP MCMGR does; the CM4-native 0x1FFE0000 does not boot.
The board maps the memory the CM4 writes as non-cacheable (for example an MPU region over the shared window) before calling imxrt_rptun_init(). The driver cleans the D-cache over the loaded image before releasing the core.