Overview

The M5208EVBe platform HAL package is loaded automatically when eCos is configured for a m5208evbe target. 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 platform HAL is complemented by the M68K architectural HAL CYGPKG_HAL_M68K, the MCFxxxx variant HAL CYGPKG_HAL_M68K_MCFxxxx, and the MCF520x processor HAL CYGPKG_HAL_M68K_MCF520x.

Startup

The M5208EVBe platform HAL package supports three separate startup types: RAM, RAMBDM and ROM. The configuration option CYG_HAL_STARTUP: controls which startup type is being used. For typical application development RAM startup should be used, and the application will be run via m68k-elf-gdb interacting with RedBoot using either serial or ethernet. It is assumed that the low-level hardware initialization, including setting up the memory map, has already been performed by RedBoot. By default the application will use certain services provided by RedBoot via the virtual vector mechanism, including diagnostic output, but that can be disabled via CYGSEM_HAL_USE_ROM_MONITOR. RAMBDM startup is a variant of RAM startup which has CYGSEM_HAL_USE_ROM_MONITOR disabled by default, and is intended for debugging over BDM instead of via RedBoot.

ROM startup can be used for applications which boot directly from flash. All the hardware will be initialized, and the application is self-contained. This startup type is used by the flash-resident version of RedBoot, and can also be used for finished applications.

M5208EVBe or M5208EVB

By default selecting the m5208evbe target will build code for the newer M5208EVBe board, with its CFI compliant flash interface. Normally the M5208EVBe board has 8MB of on-board flash available.

If support is needed for the older M5208EVB board then the CDL configuration option CYGPKG_HAL_M68K_M5208EVBE_FLASH_2MB can be enabled in the configuration. This provides support for the non-CFI flash interface needed to access to the 2MB of on-board flash on the M5208EVB.

RedBoot and Virtual Vectors

If the application is intended to act as a ROM monitor, providing services for other applications, then the configuration option CYGSEM_HAL_ROM_MONITOR should be set. Typically this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, disabled otherwise. It can be manually disabled for a RAM startup, making the application self-contained. That is useful as a testing step before switching to ROM startup. It also allows applications to be run and debugged via BDM.

Diagnostics

Diagnostics support is provided by the MCFxxxx variant HAL. For RAM startup the application will inherit its diagnostics channel from RedBoot: when debugging over ethernet diagnostics will travel over the TCP connection between m68k-elf-gdb and RedBoot; if RedBoot is set to discard its diagnostics then application diagnostics will be discarded as well; otherwise diagnostics will be sent via UART0.

For other startup types the default diagnostics channel can be set to either of the UARTs, or eCos can be configured to discard all diagnostics. The relevant configuration option is CYGHWR_HAL_M68K_MCFxxxx_DIAGNOSTICS_PORT.

Optional Hardware

The MCF520x processor HAL provides configuration options for the GPIO pin assignment registers, effectively controlling which of the on-chip peripherals are connected to the outside board. These settings are used in term to set the defaults for various devices, for example which UARTs are available and whether or not the hardware handshake lines are connected. The platform HAL provides default setttings for all these registers appropriate for a M5208EVBe board, but application developers can override these settings as required. Alternatively application can manipulate the processor's GPIO unit directly.

Cache and On-Chip RAM

The platform HAL contains configuration options for the values of the RAMBAR, CACR, ACR0 and ACR1 control registers. The first of these determines the location of on-chip RAM and does not usually need to be changed by application developers. The other three registers determine the caching behaviour. The default settings enable caching for the external flash and SDRAM only.

System Clock

The board is set to operate at 166.67/83.33 MHz, corresponding to the cpu and peripheral clocks respectively. However PLL dithering is enabled, slightly reducing the effective clock frequency. Programmable interrupt timer PIT0 is used to implement the eCos system clock. By default this is set to tick approximately once every 10ms, corresponding to a 100Hz clock. The frequency can be changed via the configuration option CYGNUM_HAL_RTC_PERIOD, which is used to program the timer's PIT Modulus Register. Other clock-related settings are recalculated automatically if the period is changed.

It should be noted that the effects of clock dithering are not precise, and hence the resulting system clock will not run at exactly 100Hz. A consequence of this is that conversions between seconds/nanoseconds and system clock ticks will not be precise and may suffer from rounding errors. If application code requires very precise timings then it may be necessary to do some experimenting and fine tuning.

Compiler Flags

The platform 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 this port: