Description

The Freescale MCF521x group of processors is part of the larger family of Coldfire processors. The MCF521x group has several members including the MCF5211, MCF5212 and MCF5213. They differ from other Coldfire processors in that there is no external memory bus, instead all memory is on-chip. For example the MCF5213 has 256KB on-chip flash and 32K of on-chip SRAM. All MCF521x processors have basically the same set of peripherals (CAN is not available on the MCF5211 or MCF5212) but differ in the amount of on-chip memory.

The processor HAL package CYGPKG_HAL_M68K_MCF521x provides support for all MCF521x processors, although at the time of writing it has only been tested on an MCF5213. It complements the M68K architectural HAL package CYGPKG_HAL_M68K and the variant HAL package CYGPKG_HAL_M68K_MCFxxxx. An eCos configuration should also include a platform HAL package, for example CYGPKG_HAL_M68K_M5213EVB to support board-level details like how the on-chip peripherals are connected to the outside world. It should be noted that compared with other eCos Coldfire ports rather more work is done by the MCF521x processor HAL and rather less by the platform HAL. This is possible because of the lack of an external memory bus.

Configuration

The MCF521x processor HAL package should be loaded automatically when eCos is configured for appropriate target hardware. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

The configuration option CYGHWR_HAL_M68K_MCF521x_PROCESSOR defines the exact processor type, for example MCF5213. Usually it will be set by the platform HAL and should not be manipulated by the user.

The option CYG_HAL_STARTUP determines whether the application will reside in RAM or in ROM (flash). With just 32K of RAM on the MCF5213 only fairly simple applications will fit into RAM so the default is ROM startup. This can make debugging significantly more difficult because it requires the use of hardware breakpoints, and the processor only supports a small number of these. Debugging RAM startup applications can be rather easier because the debugger can insert breakpoints by modifying the code. Hence it may sometimes be convenient to debug a cut-down version of an application linked against a RAM startup eCos configuration. Alternatively with ROM startup individual functions can be placed in a “.2ram” section which means they will be copied from flash to RAM during initialization and execute from RAM. Again this may make debugging rather easier, assuming sufficient RAM is available.

For ROM startup the table of M68K exception vectors can reside either in ROM or in RAM. This table occupies 512 bytes (a full M68K exception vector table is 1K but on an MCF521x running eCos only half of this is needed). Keeping it in ROM saves a significant portion of the scarce RAM, but means that some eCos functionality (such as the HAL_VSR_SET macros) is not available. Few applications require that functionality so by default the vectors are kept in ROM.

The processor HAL gives application developers full control over how the GPIO pins should be initialized, using configuration options such as CYGHWR_HAL_M68K_MCF521x_GPIO_PORTQS_QS0. That pin is normally used for QSPI but can also be used for CAN, UART0, or as a general-purpose input or output. For a GPIO output it is also possible to specify whether the pins should be initialized high or low. The default settings for each pin are determined by the platform HAL. However there may be various jumpers or an expansion connector on the board, in which case the platform HAL may not know exactly how the various pins should be set up. Hence the processor HAL allows application developers to override the default settings for every pin. There are also configuration options for controlling the pin slew rates and drive strengths.

The GPIO pin settings are used to determine default values for a variety of other hardware-related configuration options. For example CYGHWR_HAL_M68K_MCFxxxx_UART0 will be enabled if either the TX or RX lines are connected, and that option is used elsewhere in the system when deciding which UARTs are potentially usable for HAL diagnostics or should have serial device driver support. The user may be able to override some of these settings, to handle scenarios where a pin should come up as a GPIO output but may later get switched to e.g. a UART tx line. The platform HAL may impose some restrictions.

If the SPI bus should be enabled then there is a configuration option CYGNUM_HAL_M68K_MCF521x_QSPI_ISRPRI to control the interrupt priority of the QSPI bus device. MCF521x processors use the same interrupt controller as the MCF5282, and this has a limitation that all interrupt priorities should be unique. The processor HAL provides non-conflicting defaults for the various on-chip devices but when changing interrupt priorities it is the application developer's responsibility to maintain unique priorities.

If the I²C bus should be enabled then again there is a configuration option CYGNUM_HAL_M68K_MCF521x_I2C_ISRPRI to control the interrupt priority of the I²C device. There is also a configuration option CYGNUM_HAL_M68K_MCF521x_I2C_FDR to set the FDR register which controls the I²C bus speed. The default speed is the I²C standard 100KHz, or as close to that as the hardware allows, but if all attached I²C devices can operate at a faster speed then this option may be adjusted accordingly.

The processor HAL provides a configuration option CYGNUM_HAL_RTC_PERIOD to control the system clock speed. The default setting is 10 milliseconds between clock interrupts or as close to that as the hardware allows, giving a 100Hz system clock.

In kernel configurations the behaviour of the idle thread can be controlled using CYGIMP_HAL_M68K_MCF521x_IDLE. The default behaviour is wait where the cpu, flash and SRAM enter a low power mode but all peripherals continue operating normally. Any interrupt will bring the processor out of low power mode.

The processor HAL defines the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. There are three flags specific to the MCF521x port:

The HAL Port

This section describes how the MCF521x processor HAL package implements parts of the eCos HAL specification. It should be read in conjunction with similar sections from the architectural and variant HAL documentation.