Configuration — Platform-specific Configuration Options
The MIMXRT1xxx-EVK board platform HAL package is loaded
automatically when eCos is configured for a suitable target,
mimxrt1064_evk. It should never be
necessary to load this package explicitly. Unloading the
package should only happen as a side effect of switching
The MIMXRT1xxx-EVK board platform HAL package supports six separate startup types:
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.
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
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.
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.
This is a special case startup type intended for SDRAM based RedBoot applications. It is essentially equivalent to the
JSDRAMstartup 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 an external 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.
This is a special case startup type intended for SRAM based RedBoot applications. It is essentially equivalent to the
SRAMstartup 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 an external 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
JTAGstartup 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.
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.
Due to the
RBSRAMstartup type RedBoot code+data occupying SRAM, only the upper section of SRAM is available for
Similarly due to the
RBRAMstartup type RedBoot code+data occupying the start of SDRAM, the available SDRAM for
RAMapplications starts from the offset
The decision to set aside the SRAM and SDRAM space for RedBoot in both
RBSRAMRedBoot configurations was taken to allow the
RAMstartup applications to be loaded irrespective of whether RedBoot is executing from SRAM or SDRAM.
As highlighted in the VAR
memory section, the i.MX RT ROM bootloader
cannot directly boot external-SDRAM applications. If the
final application is a
application, or a
RBRAM RedBoot, then a
second-level boot loader is required. The
CYGPKG_BOOTUP) application is a
lightweight second-level loader implementation, with the VAR
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
RAM startup types were modified to not
make use of the SRAM, but that would preclude using
RAM startup applications under a
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.
An SPI bus driver is available in the package "NXP
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.
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.
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
package. This driver is enabled automatically if the generic
"Flash device drivers" (
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.
The EVK boards use the internal ENET Ethernet device
attached to an external Micrel KSZ8081RNB PHY. The
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
This PLF HAL provides support for enforcing the start-of-day PHY pin strapping for correct operation.
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.
The board uses the RT10XX Watchdog timer 1.
contains all the code necessary to support this device. Within
that package the
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
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.
Support for both Host and Peripheral mode operation is
provided by the USB protocol stack plus EHCI host and
peripheral drivers (
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
CYGPKG_DEVS_USB_RT10XX). Here both the
host and peripheral drivers are instantiated along with the
CDC-ACM peripheral serial device if configured.
|2023-08-15||Open Publication License|