Configuration

Configuration
	Chapter 317. NXP MIMXRT1xxx-EVK Platform HAL

Overview

The MIMXRT1xxx-EVK board platform HAL package is loaded automatically when eCos is configured for a suitable target, e.g. mimxrt1050_evk or mimxrt1064_evk. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Startup

The MIMXRT1xxx-EVK board platform HAL package supports six separate startup types:

JTAG

This is the default startup type. It is used to build applications that are loaded via a H/W debug interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x20209000 and entered at 0x20209008. eCos startup code will perform all necessary hardware initialization.

Even though this startup type is the default, it is not normally expected to be used in the field. It is normally used for testing and development on uninitialised boards.

SRAM

This startup type is currently essentially equivalent to the JTAG startup type in memory layout and usage. This startup is intended to be used for standalone applications, either loaded from an external memory device such as an SD card or FlexSPI flash at boot time, or via a H/W debug interface.

The program expects to be loaded from 0x20209020, and the eCos startup code will perform all necessary hardware initialisation. The difference in load address from the JTAG startup is to allow space for the boot ROM configuration structures required when the application is packaged into a boot image using the flashimg_rt10 tool.

This startup type should be configured for standalone applications to execute from SRAM. All of the SRAM is available for application use, and the external SDRAM is unassigned and not managed by eCos, but is available for application use.

JSDRAM

This startup is intended to be used for standalone applications, either loaded from an external memory device such as an SD card or FlexSPI flash at boot time via a second-level boot loader, or via a H/W debug interface into external SDRAM.

The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x80000000 and entered at 0x80000018 (based on the current application signature block size). eCos startup code will perform all necessary hardware initialization. JSDRAM applications can only be loaded once the SDRAM has been initialised, either when loaded from a boot location in conjunction with a valid IVT+DCD via a second-level boot loader, or when loaded via a suitable H/W debug session directly.

This startup type should be configured for standalone applications to execute from SDRAM. All of the SDRAM and SRAM is available for application use.

RBRAM

This is a special case startup type intended for SDRAM based RedBoot applications. It is essentially equivalent to the JSDRAM startup type, but with a section from the start of SRAM and SDRAM allocated to RedBoot for its code+data storage. The remaining SRAM and SDRAM is set aside for applications loaded/executed via the RedBoot instance. As mentioned, this startup is intended to be used for the standalone RedBoot, either loaded at boot from a memory device such as the FlexSPI flash via a second-level boot loader, or via a H/W debug interface.

The program expects to be loaded from 0x80000000, and the eCos startup code will perform all necessary hardware initialisation.

RBSRAM

This is a special case startup type intended for SRAM based RedBoot applications. It is essentially equivalent to the SRAM startup type, but with the bottom of the SRAM allocated to RedBoot, along with an (unused) section at the start of SDRAM, for the RedBoot code+data requirements. The remaining SRAM and SDRAM are set aside for applications loaded/executed via the RedBoot instance. As mentioned, this startup is intended to be used for the standalone RedBoot, either loaded at boot from a memory device such as the FlexSPI flash, or via a H/W debug interface.

The program expects to be loaded from 0x20209020, and the eCos startup code will perform all necessary hardware initialisation. The difference in load address from the JTAG startup is to allow space for the boot ROM configuration structures required when the application is packaged into a boot image. e.g. as by the flashimg_rt10 tool.

RAM

This startup type is for applications that are loaded via RedBoot into external SDRAM. They rely on services supplied by RedBoot. RAM applications can only be loaded via RedBoot.

Note

	Note
Due to the `RBSRAM` startup type RedBoot code+data occupying SRAM, only the upper section of SRAM is available for `RAM` applications. Similarly due to the `RBRAM` startup type RedBoot code+data occupying the start of SDRAM, the available SDRAM for `RAM` applications starts from the offset `CYGMEM_REGION_redboot_SIZE`. The decision to set aside the SRAM and SDRAM space for RedBoot in both `RBRAM` and `RBSRAM` RedBoot configurations was taken to allow the `RAM` startup applications to be loaded irrespective of whether RedBoot is executing from SRAM or SDRAM.

Due to the RBSRAM startup type RedBoot code+data occupying SRAM, only the upper section of SRAM is available for RAM applications.

Similarly due to the RBRAM startup type RedBoot code+data occupying the start of SDRAM, the available SDRAM for RAM applications starts from the offset CYGMEM_REGION_redboot_SIZE.

The decision to set aside the SRAM and SDRAM space for RedBoot in both RBRAM and RBSRAM RedBoot configurations was taken to allow the RAM startup applications to be loaded irrespective of whether RedBoot is executing from SRAM or SDRAM.

As highlighted in the VAR On-chip memory section, the i.MX RT ROM bootloader cannot directly boot external-SDRAM applications. If the final application is a JSDRAM standalone application, or a RBRAM RedBoot, then a second-level boot loader is required. The BootUp (CYGPKG_BOOTUP) application is a lightweight second-level loader implementation, with the VAR BootUp section providing an overview. Alternatively a RBSRAM RedBoot could be used to boot the final RBRAM RedBoot if really required, but since the SRAM cost of both RedBoot configurations are the same it is expected that if RedBoot is required then a RBSRAM version is used (as can be directly booted by the i.MX RT ROM bootloader). The only benefit for a SDRAM based RedBoot would be if the RBRAM and RAM startup types were modified to not make use of the SRAM, but that would preclude using RAM startup applications under a RBSRAM RedBoot.

UART Serial Driver

The MIMXRT1050-EVK board uses the RT10XX internal UART serial support. The HAL diagnostic interface, used for both polled diagnostic output and GDB stub communication, is only expected to be available to be used on the LPUART1 port.

As well as the polled HAL diagnostic interface, there is also a CYGPKG_IO_SERIAL_NXP_LPUART package which contains all the code necessary to support interrupt-driven operation with greater functionality.

It is not recommended to use the interrupt-driven serial driver with a port at the same time as using that port for HAL diagnostic I/O.

This driver is not active until the CYGPKG_IO_SERIAL_DEVICES configuration option within the generic serial driver support package CYGPKG_IO_SERIAL is enabled in the configuration. By default this will only enable support in the driver for the LPUART1 port (the same as the HAL diagnostic interface), but the default configuration can be modified to enable support for other serial ports.

SPI Driver

An SPI bus driver is available in the package "NXP LPSPI Support" (CYGPKG_DEVS_SPI_NXP_LPSPI).

Consult the generic SPI driver API documentation in the eCosPro Reference Manual for further details on SPI support in eCosPro, along with the configuration options in the NXP SPI device driver.

I²C Driver

Support for NXP I²C busses is provided by the "NXP LPI2C Support" package (CYGPKG_DEVS_I2C_NXP_LPI2C). The variant HAL causes two buses to be instantiated. These have been tested using external I²C devices.

Flash Driver

The external FlexSPI Flash, and in the case of RT1064 boards the FlexSPI2 attached SiP Flash. may be programmed and managed using the Flash driver located in the "NXP FlexSPI Support" (CYGPKG_DEVS_FLASH_NXP_FLEXSPI) package. This driver is enabled automatically if the generic "Flash device drivers" (CYGPKG_IO_FLASH) package is included in the eCos configuration. The driver will configure itself automatically for the size and parameters of the specific flash variant present on the IMXRT1050-EVKB and MIMXRT1064-EVK boards.

Ethernet Driver

The EVK boards use the internal ENET Ethernet device attached to an external Micrel KSZ8081RNB PHY. The CYGPKG_DEVS_ETH_FREESCALE_ENET package, in conjunction with the VAR HAL, contains all the code necessary to support this device and the platform HAL package contains definitions that customize the driver to the board. The driver is not active until the generic Ethernet support package, CYGPKG_IO_ETH_DRIVERS, is included in the configuration.

This PLF HAL provides support for enforcing the start-of-day PHY pin strapping for correct operation.

CAN Driver

The iMX RT1xxx devices have multiple FlexCAN interfaces. Device support is via the NXP FlexCAN CAN Driver package.

The EVK boards have a single CAN connector (unpopulated by default) on J11 that is configured as FlexCAN2 for RT1052 boards, and FlexCAN3 for RT1064 boards.

Consult the generic Chapter 90, CAN Support documentation for further details on use of the CAN API, CAN configuration and device drivers.

Watchdog Driver

The board uses the RT10XX Watchdog timer 1. The CYGPKG_DEVICES_WATCHDOG_ARM_IMX package contains all the code necessary to support this device. Within that package the CYGNUM_DEVS_WATCHDOG_ARM_IMX_DESIRED_TIMEOUT_MS configuration option controls the watchdog timeout, and by default will force a reset of the board upon timeout. This driver is not active until the generic watchdog device support package, CYGPKG_IO_WATCHDOG, is included in the configuration.

PWM Driver

Support for the NXP FlexPWM devices is provided by the "NXP PWM Support" package (CYGPKG_DEVS_PWM_NXP) which needs to be used in conjunction with the CYGPKG_IO_PWM generic PWM package. Refer to the documentation for that package for usage details.

The RT10XX contains four FlexPWM devices, each of which contains four independent submodules. Each submodule has two semi-independent output lines that can be routed to a variety of pads. Each submodule is presented as a separate PWM device and have names such as "pwm1.0" for FlexPWM 1 submodule 0 or "pwm3.2" for FlexPWM 3 submodule 2. The output lines are mapped on to channel 0 for output A and channel 1 for output B. These outputs are semi-independent in that they must share a period, but may have different duty cycles.

USB Support

Support for both Host and Peripheral mode operation is provided by the USB protocol stack plus EHCI host and peripheral drivers (CYGPKG_DEVS_USB_EHCI and CYGPKG_DEVS_USB_PCD_EHCI).

Host mode is supported for USB2 which is connected to the USB_HOST microab receptacle. Class support is available for mass storage devices, and CDC-ACM serial.

Peripheral mode is supported for USB1 which is connected to the USB_OTG microab receptacle. Note that OTG mode is not supported. By default this peripheral port is configured as a CDC-ACM device.

USB configuration is handled by the "RT10XX USB controller configuration" package (CYGPKG_DEVS_USB_RT10XX). Here both the host and peripheral drivers are instantiated along with the CDC-ACM peripheral serial device if configured.


Setup		The HAL Port

Name