i.MX RT1064 EVK

i.MX RT1064 EVK is an evaluation kit by NXP company. This kit uses the i.MX RT1064 crossover MCU with ARM Cortex M7 core.

Features

  • Processor

    • MIMXRT1066DVL6A processor

  • Memory

    • 1 Mb OCRAM memory

    • 256 Mb SDRAM memory

    • 512 Mb Hyper Flash - Populated but 0 ohm DNP

    • 64 Mb QSPI Flash

    • TF socket for SD card

  • Display and Audio

    • Parallel LCD connector

    • Camera connector

    • Audio CODEC

    • 4-pole audio headphone jack

    • External speaker connection

    • Microphone

    • SPDIF connector

  • Connectivity

    • Micro USB host and OTG connectors

    • Ethernet (10/100T) connector

    • CAN transceivers

    • Arduino® interface

  • Sensors

    • FXOS8700CQ 6-Axis Ecompass (3-Axis Mag, 3-Axis Accel)

Serial Console

Virtual console port provided by OpenSDA:

UART1_TXD

GPIO_AD_B0_12

LPUART1_TX

UART1_RXD

GPIO_AD_B0_13

LPUART1_RX

Arduino RS-232 Shield:

J22

D0

UART_RX

GPIO_AD_B1_07

LPUART3_RX

J22

D1

UART_TX

GPIO_AD_B1_06

LPUART3_TX

LEDs and buttons

LEDs

There are four LED status indicators located on the EVK Board. The functions of these LEDs include:

Pin

Description

D3

Power Supply

D18

User LED

D20

OpenSDA

D21

Reset LED

Only a single LED, D18, is under software control. It connects to GPIO_AD_B0_09 which is shared with JTAG_TDI and ENET_RST

This LED is not used by the board port unless CONFIG_ARCH_LEDS is defined. In that case, the usage by the board port is defined in include/board.h and src/imxrt_autoleds.c. The LED is used to encode OS-related events as follows:

SYMBOL

Meaning

LED

LED_STARTED

NuttX has been started

OFF

LED_HEAPALLOCATE

Heap has been allocated

OFF

LED_IRQSENABLED

Interrupts enabled

OFF

LED_STACKCREATED

Idle stack created

ON

LED_INIRQ

In an interrupt

N/C

LED_SIGNAL

In a signal handler

N/C

LED_ASSERTION

An assertion failed

N/C

LED_PANIC

The system has crashed

FLASH

Thus if the LED is statically on, NuttX has successfully booted and is, apparently, running normally. If the LED is flashing at approximately 2Hz, then a fatal error has been detected and the system has halted.

Buttons

There are five user interface switches on the MIMXRT1050 EVK Board:

  • SW1: Power Switch (slide switch fir power from J2)

  • SW2: ON/OFF Button

  • SW3: Power-on Reset button state forces to reset the system power except SNVS domain

  • SW9: Reset button

  • SW8: User button GPIO5-00

Only the user button is available to the software. It is sensed on the WAKEUP pin which will be pulled low when the button is pressed.

Configurations

can

This is an nsh configuration (see below) with added support of CAN driver. FlexCAN3 is chosen as default, the change can be made at System type peripheral selection. Please note that only FlexCAN3 and FlexCAN2 is available on this board.

Bitrate and sample point can be also changed at System type peripheral selection, basic values are 1 MHz for bitrate and 0.80 for sample point. The FlexCAN driver for imxrt runs at 80 MHz clock frequency.

The configuration also includes CAN utilities as candump and cansend.

canfd

This is an nsh configuration (see below) with added support of CAN_FD driver. FlexCAN3 is chosen as default, please note that only FlexCAN3 is capable of providing CAN_FD support.

Bitrate and sample point can be also changed at System type peripheral selection, basic values are 1 MHz for bitrate and 0.80 for sample point for arbitration phase and 4 MHz (bitrate) and 0.90 (sample point) for data phase. The FlexCAN driver for imxrt runs at 80 MHz clock frequency.

The configuration also includes CAN utilities as candump and cansend.

knsh

This is identical to the nsh configuration below except that NuttX is built as a protected mode, monolithic module and the user applications are built separately. It is recommends to use a special make command; not just ‘make’ but make with the following two arguments:

$ make pass1 pass2

In the normal case (just ‘make’), make will attempt to build both user- and kernel-mode blobs more or less interleaved. This actual works! However, for me it is very confusing so I prefer the above make command: Make the user-space binaries first (pass1), then make the kernel-space binaries (pass2)

NOTES:

At the end of the build, there will be several files in the top-level NuttX build directory:

PASS1:

  • nuttx_user.elf - The pass1 user-space ELF file

  • nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)

  • User.map - Symbols in the user-space ELF file

PASS2:

  • nuttx - The pass2 kernel-space ELF file

  • nuttx.hex - The pass2 Intel HEX file (selected in defconfig)

  • System.map - Symbols in the kernel-space ELF file

The J-Link programmer will except files in .hex, .mot, .srec, and .bin formats.

Combining .hex files. If you plan to use the .hex files with your debugger or FLASH utility, then you may need to combine the two hex files into a single .hex file. Here is how you can do that.

The ‘tail’ of the nuttx.hex file should look something like this (with my comments added beginning with #):

$ tail nuttx.hex
#xx xxxx 00 data records
...
:10 C93C 00 000000000040184000C2010000000000 90
:10 C94C 00 2400080000801B4000C01B4000001C40 5D
:10 C95C 00 00401C4000000C4050BF0060FF000100 74
#xx xxxx 05 Start Linear Address Record
:04 0000 05 6000 02C1 D4
#xx xxxx 01 End Of File record
:00 0000 01 FF

Use an editor such as vi to remove the 05 and 01 records.

The ‘head’ of the nuttx_user.hex file should look something like this (again with my comments added beginning with #):

$ head nuttx_user.hex
#xx xxxx 04 Extended Linear Address Record
:02 0000 04 6020 7A
#xx xxxx 00 data records
:10 0000 00 8905206030002060F2622060FC622060 80
:10 0010 00 0000242008002420080024205C012420 63
:10 0020 00 140024203D0020603100206071052060 14
...

Nothing needs to be done here. The nuttx_user.hex file should be fine.

Combine the edited nuttx.hex and un-edited nuttx_user.hex file to produce a single combined hex file:

$ cat nuttx.hex nuttx_user.hex >combined.hex

Then use the combined.hex file with the to write the FLASH image. If you do this a lot, you will probably want to invest a little time to develop a tool to automate these steps.

STATUS: This configuration was added on 8 June 2018 primarily to assure that all of the components are in place to support the PROTECTED mode build. This configuration, however, has not been verified as of this writing.

netnsh

This configuration is similar to the nsh configuration except that is has networking enabled, both IPv4 and IPv6. This NSH configuration is focused on network-related testing.

nsh

Configures the NuttShell (nsh) located at examples/nsh. This NSH configuration is focused on low level, command-line driver testing. Built-in applications are supported, but none are enabled. This configuration does not support a network.

lvgl

Configures the Littlev graphic library (lvgl) demo located under examples/lvgldemo. This configuration needs the optional LCD model RK043FN02H-CT from NXP. The LCD panel comes with the integrated capacitive touchscreen sensor FT5336GQQ connected to the LPI2C1 bus, address 0x38. NuttX support such touchscreen device via the driver ft5x06 (drivers/input/ft5x06.c). At the moment only the polling method is available, the board features an interrupt line connected to the touchscreen sensor IC.

IMXRT1064 MCU provides the integrated LCD driver.

The LCD panel features:

  • size 4.3”

  • resolution 480×272 RGB

  • backlight driver

  • dimensions [mm]: 105.5 (W) x 67.2(H) x 4.35(D) Max.

To run the lvgl demo please type “lvgldemo” at nsh prompt:

nsh> lvgldemo