The MCF520x ColdFire Processor Family
Prev Chapter 331. Motorola MCF520x Processor Support Next

Name

CYGPKG_HAL_M68K_MCF520x — eCos Support for Freescale MCF520x Processors

Description

The Freescale MCF5207 and MCF5208 processors are part of the larger family of ColdFire processors. The two processors differ in the peripheral support: the MCF5208 has on-chip ethernet, the MCF5207 does not. The processor HAL package CYGPKG_HAL_M68K_MCF520x provides support for both processors, although at the time of writing it has only been tested on an MCF5208. 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 to support board-level details like how the on-chip peripherals are connected to the outside world.

The package contains very little code. Instead it consists mainly of definitions, enabling appropriate code in the MCFxxxx variant HAL and in the various device drivers.

Configuration

The MCF520x 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.

Most of the package's configuration options relate to hardware. The settings are generally determined by the platform HAL and there is little need for application developers to change them. The first hardware option is CYGHWR_HAL_MCF520x_PROCESSOR, identifying the specific MCF520x processor being used. Legal values are MCF5207 and MCF5208. Typically the platform HAL will set this option via a CDL constraint.

Component CYGHWR_HAL_M68K_MCF520x_GPIO contains various options related to pin-connectivity. This gives full control over the PAR pin assignment registers, and for those pins configured as GPIO it is also possible to control the pin direction and data settings. These options are used to initialize the processor's GPIO module early on during system initialization, but applications may change settings later on as necessary.

The GPIO settings are used to determine default settings for the three on-chip uarts, the I²C bus and the QSPI bus. For example if none of the relevant GPIO pins are assigned to uart2 then component CYGHWR_HAL_M68K_MCFxxxx_UART2 will be disabled by default, and that uart cannot be used for HAL diagnostics nor accessed via the serial device driver. It is possible to override these settings if desired, for example if a uart is connected but will be manipulated directly by application code instead of via a device driver.

  1. For each of the three on-chip uarts there will be a component, e.g. CYGHWR_HAL_M68K_MCFxxxx_UART0, determining whether or not the uart is usable on the target hardware. There are additional options CYGHWR_HAL_M68K_MCFxxxx_UART0_RTS and CYGHWR_HAL_M68K_MCFxxxx_UART0_CTS indicating whether or not the hardware handshake lines are connected, and CYGHWR_HAL_M68K_MCFxxxx_UART0_RS485_RTS to indicate that the RTS line controls an RS485 transceiver.
  2. Component CYGHWR_HAL_M68K_MCF520x_I2C determines whether or not the processor HAL will instantiate an I²C bus device hal_mcfxxxx_i2c_bus. There are also options to control the interrupt priority and to set the FDR register which controls the bus speed. The default bus speed will be the standard I²C bus speed of 100KHz, or as close as can be achieved given hardware limitations.
  3. Component CYGHWR_HAL_M68K_MCF520x_SPI determines whether or not the processor HAL will instantiate an SPI bus device hal_mcfxxxx_qspi_bus. It contains an additional configuration option for the interrupt priority.

For configurations which include the eCos kernel, CYGIMP_HAL_M68K_MCF520x_IDLE determines what happens when the idle thread runs. It should be noted that there are hardware errata associated with this functionality, and when systems were configured to use WAIT or DOZE mode problems were observed where the processor appeared to fail to wake up even though there were pending interrupts.

The HAL Port

This section describes how the MCF520x 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.

HAL I/O

The header file cyg/hal/proc_io.h provides definitions of MCF520x-specific on-chip peripherals. Many of the on-chip peripherals are compatible with those on the MCF5282 or other ColdFire processors, and for those peripherals it is the var_io.h header provided by the MCFxxxx variant HAL which provides the appropriate definitions. Both headers are automatically included by the architectural header cyg/hal/hal_io.h, so typically application code and other packages will just include the latter.

Interrupt Handling

MCF520x processors implement standard ColdFire interrupt and exception handling, and come with one MCF5282-compatible interrupt controller and an edge port module. Therefore all interrupt and exception handling is left to the architectural and MCFxxxx variant HAL. The interrupt controllers are slightly enhanced relative to the MCF5282, with extra registers to facilitate masking and unmasking interrupts. These enhancements are supported. Unlike the MCF5282 interrupt priorities do not have to be unique, so valid interrupt priorities are in the range 1 to 6 corresponding to M68K IPL levels.

The processor's cyg/hal/proc_intr.h serves mainly to define symbols such as CYGNUM_HAL_ISR_UART0, mapping the MCF520x on-chip interrupt sources to the interrupt vectors.

Clock

Typically hardware timer PIT0 will be used for the eCos system clock, and that timer should not be manipulated directly by application code. If gprof-based profiling is enabled then that will use hardware timer PIT1. Some of the configuration options related to the system clock, for example CYGNUM_HAL_RTC_PERIOD, are actually contained in the platform HAL rather than the processor HAL. These options need to take into account the processor clock speed, a characteristic of the platform rather than the processor.

Caching

Support for the cache is provided via the generic HAL macros in the MCFxxxx variant HAL cache. The HAL also defines a macro HAL_MEMORY_BARRIER() which acts to synchronize the pipeline, delaying execution until all previous operations including all pending writes are complete. This will usually be necessary when interacting with devices that access memory directly.

Other Issues

The MCF520x processor HAL does not affect the implementation of data types, stack size definitions, SMP support, system startup, or debug support. The MCFxxxx variant HAL versions of HAL_LSBIT_INDEX and HAL_MSBIT_INDEX are used since the processor supports the ff1.l and bitrev.l instructions. HAL_DELAY_US is implemented as a simple counting loop. HAL_IDLE_THREAD_ACTION may be defined depending on configuration option CYGIMP_HAL_M68K_MCF520x_IDLE.

Other Functionality

The processor HAL will instantiate a cyg_i2c_bus structure hal_mcfxxxx_i2c_bus when the configuration option CYGHWR_HAL_M68K_MCFxxxx_I2C is enabled. That option is enabled by default if various GPIO pins are configured appropriately. The implementation is provided by the CYGPKG_DEVS_I2C_MCFxxxx device driver. The processor HAL does not know what I²C devices may be attached to the bus so that is left to the platform HAL.

The processor HAL will instantiate a cyg_spi_bus structure hal_mcfxxxx_qspi_bus when the configuration option CYGHWR_HAL_M68K_MCFxxxx_SPI is enabled. That option is enabled by default if various GPIO pins are configured appropriately. The implementation is provided by the CYGPKG_DEVS_SPI_MCFxxxx_QSPI device driver. The processor HAL does not know what SPI devices may be attached to the bus so that is left to the platform HAL. All SPI device structures should be placed in the table mcfxxxx_qspi.

Prev Up Next
Chapter 331. Motorola MCF520x Processor Support Home Part LXXXII. MIPS Architecture