On-chip memory

The IMX parts include on-chip SRAM (OCRAM). The SRAM can vary in size from as little as 4KiB to 1MiB. Support is also available for external FLASH and SDRAM.

Typically, an eCos platform HAL port will expect a standalone application image to be programmed into boot memory, and the board would boot this image from reset.

Note

The i.MX RT ROM bootloader will only load and execute SRAM (OCRAM) or memory-mapped flash applications. If your final application is linked for SRAM then creating a bootable image as described in the relevant platform specific documentation is sufficient. For applications that are linked to execute from external memory (e.g. SDRAM) then the first stage of booting an application will be via execution of a second-level boot loader application started by the ROM bootloader. For eCos this second-level is normally BootUp (CYGPKG_BOOTUP) or RedBoot (CYGPKG_REDBOOT), though it can just as well be a custom application if required.

The i.MX RT ROM bootloader will parse a table describing the initial I/O setup and memory destination for the application image (copying the image if required). This table is known as the DCD (Device Configuration Data).

For embedded development it is normally expected that H/W debugging (JTAG/SWD) via a suitable adapter is used to aid application development of standalone applications. For standalone applications (no dependency on a ROM monitor) there is no application binary difference whether the application is started from the i.MX RT ROM bootloader process or loaded via a H/W debugger interface; with the exception that the H/W debugger may need to perform the same actions as the DCD table prior to loading an executable to ensure the MCU setup is the same as execution via the ROM bootloader.

An alternative to H/W debugging using an external adapter is for RedBoot to be installed as the application started by the IMX boot process. RedBoot provides GDB stub functionality so it is then possible to download and debug stand-alone and eCos applications via the gdb debugger using serial interfaces or other debug channels. If RedBoot is present it may also be used to manage the external flash memory. For RedBoot based production purposes, applications are programmed into external FLASH and may be self-booting. Applications may also be loaded into memory using a RedBoot startup script. RedBoot has a memory and performance impact on applications if they are configured to use RedBoot provided functionality. The use of the simple BootUp world instead of RedBoot means that there is no performance or memory impact on the final standalone application started by the boot process.

Cache Handling

The RT10XX variants contain an instruction and data cache controller defined as part of the Cortex-M architectural specification. Support for this controller is supplied by the architecture HAL.

The variant HAL provides a mechanism for setting aside a, configurable size, block of OCRAM as uncached for device driver and DMA usage.

OCOTP (On-Chip One-Time-Programmable) fuses

The HAL provides for basic OCOTP operations. Details are supplied later.

Serial I/O

The IMX variant HAL supports basic polled HAL diagnostic I/O over any of the on-chip serial devices. There is also a fully interrupt-driven serial device driver suitable for eCos applications for all on-chip serial devices. The serial driver consists of an eCos package: CYGPKG_IO_SERIAL_NXP_LPUART which provides support for the IMX on-chip serial devices. Using the HAL diagnostic I/O support, any of these devices can be used by the ROM monitor or RedBoot for communication with GDB. If a device is needed by the application, either directly or via the serial driver, then it cannot also be used for GDB communication using the HAL I/O support. An alternative serial port should be used instead.

The HAL defines CDL interfaces, CYGINT_HAL_CORTEXM_IMX_UART1 to CYGINT_HAL_CORTEXM_IMX_UART8 for each of the available UARTs. The platform HAL CDL should contain an implements directive for each such UART that is available for use on the board. This will enable use of the UART for diagnostic use.

Interrupts

The IMX HAL relies on the architectural HAL to provide support for the interrupts directly routed to the NVIC. The cyg/hal/var_intr.h header defines the vector mapping for these.

Pin Multiplexing and GPIO

The variant HAL provides support for packaging the pin, GPIO and daisy chain configurations of an external line into 32-bit descriptors that can then be used with macros to configure the pin and set and read its value. Details are supplied later.

Ethernet

eCos includes a device driver for the on-chip ENET Ethernet controllers. This is located in the package CYGPKG_DEVS_ETH_FREESCALE_ENET (“Freescale ENET ethernet driver”).

This variant HAL provides some common support for ENET interfaces via the initialisation helper function CYGHWR_FREESCALE_ENET_PLATFORM_INIT(base) and the IEEE MAC acquisition function CYGHWR_FREESCALE_ENET_PLATFORM_MAC(base, p_enaddr).

Note

The CYGHWR_FREESCALE_ENET_PLATFORM_MAC() will attempt to use the OCOTP fuses set aside for holding MAC addresses, but from the factory these are unset. In which case for the first ENET controller the code will fall back to providing a MAC address based on the OCOTP unique ID field. It is the responsibility of the developer to implement any factory production steps required to fuse a unique MAC address into the relevant OCOTP locations as required.

CAN

eCos includes a device driver for the on-chip FlexCAN controllers. This is located in the package CYGPKG_DEVS_CAN_NXP_FLEXCAN (“NXP FlexCAN driver”).

Watchdog

eCos includes device drivers for the on-chip watchdog in the IMX family. This is located in the package CYGPKG_DEVICES_WALLCLOCK_NXP ("NXP wallclock driver").