Description

The senTec Cobra5329 platform consists of a small module which plugs into a carrier board. The module contains: an MCF5329 ColdFire processor; 16MB of external SDRAM; 16MB of external flash memory; a configuration dip switch; a wallclock device on the I²C bus; a temperature sensor, also on the I²C bus; a multiplexer for the SPI chip select signals; and an ethernet phy. By default the module comes with the dBUG ROM monitor programmed in the external flash. The carrier board adds: power circuitry; transceivers for two RS232 ports; a CAN transceiver; four LEDs; an MMC socket connected to the SPI bus and multiplexed chip select 0; a touch screen controller, also attached to the SPI bus and chip select 1; and connectors for the various peripherals.

This package CYGPKG_HAL_M68K_COBRA5329 provides a port to the Cobra5329 platform. The port assumes that the cpu module is plugged into a standard carrier board. If instead it is plugged into a custom carrier board with different I/O capabilities then it may still be possible to use the port by adjusting the eCos configuration. However the port has only been tested on a standard board.

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. Alternatively a BDM hardware debug module can be used.

The eCos port can be configured for one of four startup types:

Hardware

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

There is a potential problem with external memory accesses on the MCF5329 (device erratum 6): spurious accesses to unpopulated parts of the address space can hang the processor. To avoid this problem the external flash is replicated throughout the bottom of the address space, and a dummy region is created at address 0xC0000000. As a debugging aid the flash is set to write-protected, which should catch some null pointer indirections. The flash driver will temporarily set this part of the address space to read-write when modifying the flash.

For all startup types the M68K exception vectors, the eCos virtual vector table, and a small amount of additional data is placed at the base of SDRAM. For ROM startup the application's data starts immediately afterwards. For RAM and RAMBDM startup application code starts at 0x40010000, with just under 64K reserved for use by RedBoot, and data follows after the code. For DBUG startup application code starts at 0x40020000, with 128K reserved for use by dBUG.

Typically the first 128K of flash is used for RedBoot, and the last 64K of flash @ 0x00FF0000 is used for RedBoot's FIS and fconfig data. The remainder of the flash is available for use by the application, and is supported via the V2 AMD flash driver CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2. That driver is inactive unless the generic flash support CYGPKG_IO_FLASH has been included in the configuration.

Code and data can be placed in the internal RAM using the linker script section “.iram_text” for code, and “.iram_data” and “.iram_bss” for initialized and unitialized data respectively. The M68K architectural HAL contains a testcase iram1.c which demonstrates how to use these linker sections.

Of the three on-chip uarts only uart0 and uart1 have external transceivers and connectors. Uart0 is normally used as the default diagnostics channel for RedBoot and for stand-alone applications, and may also be inherited as the diagnostics/debug channel when debugging a RAM startup application over serial. The default settings are 38400 baud 8n1, except when running on top of dBUG when the baud rate is set to 115200 instead. If uart0 is not used for diagnostics then it can be accessed via the serial driver CYGPKG_DEVS_SERIAL_MCFxxxx using the device name “/dev/ser0”. Similarly uart1 can be accessed via the serial device driver using the name “/dev/ser1”. The device driver is inactive unless the generic serial support option CYGPKG_IO_SERIAL_DEVICES is enabled.

The on-chip ethernet device is supported via the device driver CYGPKG_DEVS_ETH_MCFxxxx. This driver will be inactive unless the generic ethernet support CYGPKG_IO_ETH_DRIVERS is included in the configuration. Typically that will happen automatically when the configuration is created using the net template. The board does not have a serial EEPROM or equivalent to hold a unique ethernet MAC address, so that has to be provided in software instead. For RedBoot or applications run on top of RedBoot the MAC address will typically be supplied by an fconfig setting. Otherwise the address will be set by a configuration option in the ethernet driver. Care should be taken that no two boards on the same network segment accidentally use the same MAC address.

The I²C bus is supported by the generic package CYGPKG_IO_I2C and the device driver CYGPKG_DEVS_I2C_MCFxxxx. Both of these will be included automatically in any configuration for the Cobra5329, but will be eliminated at link-time if the application does not use any I²C functionality. The I²C bus instance is called hal_mcfxxxx_i2c_bus, and the platform HAL also instantiates I²C device objects hal_cobra5329_lm73, hal_cobra5329_max3353, cyg_i2c_wallclock_isl12028 and cyg_i2c_wallclock_isl12028_eeprom for the various devices attached to the I²C bus. These devices are not used by eCos, but example code for how to access the LM73 can be found in the platform testcase cobra5329.c.

The QSPI bus is supported by the generic package CYGPKG_IO_SPI and the device driver CYGPKG_DEVS_SPI_MCFxxxx_QSPI. Both of these will be included automatically in any configuration for the Cobra5329, but will be eliminated at link-time if the application does not use any SPI functionality. The SPI bus instance is called hal_mcfxxxx_qspi_bus, and the platform HAL also instances SPI device objects cyg_spi_mmc_dev0 and hal_cobra5329_tsc2200 for the two devices attached to the bus. The MMC device can be used with the eCos MMC disk driver. The TSC2200 is not used by eCos, but example code for how to access it can be found in the platform testcase cobra5329.c.

Support for USB peripheral mode on the OTG controller is supported by the EHCI peripheral controller driver (CYGPKG_DEVS_USB_PCD_EHCI). A configuration package (CYGPKG_DEVS_USB_COBRA) enables the charge pump. Support is also present for a CDC/ACM USB serial interface.

All eCos configurations for the Cobra5329 also include a watchdog device driver CYGPKG_DEVS_WATCHDOG_MCF532x. That driver is inactive unless the generic watchdog support CYGPKG_IO_WATCHDOG has been added to the configuration, and should be accessed via the API provided by that package.

All eCos configurations for the Cobra5329 also include a wallclock device driver CYGPKG_DEVICES_WALLCLOCK_INTERSIL_ISL12028. This will be used automatically by the C library's time-related functions, for example time and asctime, and can be changed by an eCos-specific function cyg_libc_time_settime. In addition when using RedBoot the data command can be used to examine and change the current clock setting.

The platform HAL contains a utility function for manipulating the four LEDs:

void hal_cobra5329_led_set(which, on);

which should be a number between 1 and 4, and on should be 1 or 0. Example code for driving the LEDs can be found in the platform testcase cobra5329.c.

When using the Robust Bootloader package CYGPKG_RBL, switch 8 on the configuration dipswitch controls the rbl condboot functionality.

eCos also manages the interrupt controllers, the FlexBus settings for chip selects 0 and 5, and the SDRAM controller. The Crossbar switch is set to favour I/O rather than the cpu, avoiding problems with DMA underruns. Timer PIT3 is normally used for the eCos system clock, and when using the profiling package CYGPKG_PROFILE_GPROF PIT2 will be used for the profiling timer. Bit 7 of the edge port module is set up for use with the board's IRQ7 button. The remaining hardware is available for use by the application.

Tools

The Cobra5329 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.4.4, m68k-elf-gdb version 6.4, and binutils version 2.16.

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.