eCos Support for the Freescale M5282LITE Board — Overview


The Freescale M5282LITE board has an MCF5282 ColdFire processor, 16MB of external SDRAM, 2MB of external flash memory, and connectors plus required support chips for the on-chip peripherals. By default the board comes with its own dBUG ROM monitor located in the external flash.

For typical eCos development a RedBoot image is programmed into the external flash replacing the existing dBUG monitor. RedBoot provides gdb stub functionality so it is then possible to download and debug eCos applications via the gdb debugger. This can happen over either a serial line or over ethernet.

Supported Hardware

The memory map used by both eCos and RedBoot is as follows:

External SDRAM0x000000000x01000000
Internal RAM0x200000000x00010000
On-chip Peripherals0x400000000x40000000
On-chip Flash0xF00000000x00080000
External Flash0xFFE000000x00200000

eCos can be configured for one of three startup types:


This is the startup type normally used during application development. RedBoot is programmed into flash and performs the initial bootstrap. m68k-elf-gdb is then used to load a RAM startup application into memory and debug it. By default the application will use eCos' virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output.

With a minor change to the eCos configuration this startup type can also be used to debug applications via BDM.

This is a variant of the RAM startup which allows applications to be loaded via the board's dBUG ROM monitor rather than via RedBoot. Once the application has started it will take over all the hardware, and it will not depend on any services provided by dBUG. This startup type does not provide gdb debug facilities. It is used primarily for building a special version of RedBoot, used during hardware setup.
This startup type can be used for finished applications which will be programmed into flash at location 0xFFE00000. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization. This startup type is used for building the flash-resident version of RedBoot but can also be used for application code.

For all startup types the external SDRAM is used to hold all data. For RAM and dBUG startup the code also resides in external SDRAM, with the first 64K reserved for use by the ROM monitor. The 64K of internal RAM is not used, either by RedBoot or by eCos, so all of it is available to the application. The 512K of internal flash is not currently used.

In a typical setup the first two 64K flash blocks are used for holding the RedBoot image, and the last block is used for managing the flash and holding the RedBoot fconfig values. The remaining 29 blocks from 0xFFE20000 to 0xFFFEFFFF can be used by application code.

RedBoot can communicate with the host using either ethernet or one of the UARTs - usually uart0 corresponding to the existing serial connector on the M5282LITE board.

All configurations for the M5282LITE target include an ethernet driver package CYGPKG_DEVS_ETH_MCFxxxx. If the application does not actually require ethernet functionality then the package is inactive and the final executable will not suffer any overheads from unused functionality. This is determined by the presence of the generic ethernet I/O package CYGPKG_IO_ETH_DRIVERS. Typically the choice of eCos template causes the right thing to happen. For example the default template does not include any TCP/IP stack so CYGPKG_IO_ETH_DRIVERS is not included, but both the net and redboot templates do include a TCP/IP stack so will specify that package and hence enable the ethernet driver. The ethernet device can be shared by RedBoot and the application, so it is possible to debug a networked application over ethernet.

The M5282LITE board does not have a serial EPROM or similar hardware providing a unique network MAC address. Instead a suitable address has to be programmed into flash via RedBoot's fconfig command.

All configurations for the M5282LITE target include a serial device driver package CYGPKG_DEVS_SERIAL_MCFxxxx. The driver as a whole is inactive unless the generic serial support, CYGPKG_IO_SERIAL_DEVICES is enabled. Exactly which of the on-chip UARTs are supported is controlled by configuration options within the platform HAL. By default only uart0 is supported since on the standard board that is the only one with a connector. If the UART is needed by the application then it cannot also be used by RedBoot for gdb traffic, so another communication channel such as ethernet should be used instead.

All configurations for the M5282LITE target also include a watchdog device driver CYGPKG_DEVS_WATCHDOG_MCF5282. This driver is inactive unless the generic watchdog support CYGPKG_IO_WATCHDOG is loaded.

The on-chip interrupt controllers and the edge port module are managed by eCos using macros provided by the MCF5282 processor HAL. PIT timer 3 is normally used to implement the eCos system clock. If gprof-based profiling is enabled then that will use PIT timer 2. PIT timers 0 and 1 are unused and can be manipulated by the application. The GPIO pins are manipulated only as needed to get the UART(s) and ethernet working. eCos will reset the remaining on-chip peripherals (DMA, GPT, DMA timers, QSPI, I²C, FlexCAN, and QADC) during system startup or soft reset, but will not otherwise manipulate them.


The M5282LITE port is intended to work with GNU tools configured for an m68k-elf target. The original port was done using m68k-elf-gcc version 3.2.1, m68k-elf-gdb version 5.3, and binutils version 2.13.1.

By default eCos is built using the compiler flag -fomit-frame-pointer. Omitting the frame pointer eliminates some work on every function call and makes another register available, so the code should be smaller and faster. However without a frame pointer m68k-elf-gdb is not always able to identify stack frames, so it may be unable to provide accurate backtrace information. Removing this compiler flag from the configuration option CYGBLD_GLOBAL_CFLAGS avoids such debug problems.

A typical setup involves m68k-elf-gdb interacting with RedBoot using either serial or ethernet. Alternatively it is possible to debug via the BDM port. The package's misc subdirectory contains a script bdm.gdb that contains macros for the low-level hardware initialization normally performed by the ROM startup code. The application should be linked with an eCos configuration using RAM startup, and with the options CYGSEM_HAL_ROM_MONITOR and CYGSEM_HAL_USE_ROM_MONITOR disabled to stop eCos accessing any services provided by RedBoot. Diagnostic output will be sent out of uart0.