Overview

Description

The SSV DNP/5280 module has an MCF5280 ColdFire processor, 16MB of external SDRAM, 8MB of external flash memory, an ethernet phy chip, and in later revisions a DS1306 real-time clock. The module needs to be plugged into a suitable carrier board, typically an SSV DNP/EVA2_SV6 or a DNP/EVA6, but custom boards may be used. The carrier board provides power as well as connectors for the ethernet and some of the on-chip devices. The DNP/5282 module is similar but has a smaller footprint. The modules are supplied with some firmware already programmed into the external flash. This firmware can be either RedBoot, a ROM monitor based on eCos, or dBUG.

This package CYGPKG_HAL_M68K_DNP5280 provides a port to both modules. Specifically it supports the following targets:

eCos configuration options can be used to change the settings. CYGHWR_HAL_M68K_MCF528x_HARDWARE_DNP528x_BOARD determines the carrier board. This in turn affects the default GPIO pin settings and hence which of the on-chip peripherals are accessible. These pin settings are also controlled by configuration options. Hence custom carrier boards can be supported by creating an initial configuration for one of the standard targets and then changing the pin settings to reflect the I/O capabilities of the actual carrier board.

Typical eCos development involves using RedBoot as the board's firmware, replacing dBUG if necessary. 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.

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

Supported Hardware

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

DNP/5282 modules also have on-chip flash at 0xF0000000. 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. In a typical setup RedBoot will occupy the first two external flash blocks, and it will also use the last flash block for storing fconfig run-time configuration settings and the fis directory.

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.

RedBoot can communicate with the host using either ethernet or one of the UARTs - usually uart0 because the DNP/EVA2_SV6 carrier board only provides a connector for that board.

All configurations for the DNP/5280 and DNP/5282 targets 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 DNP/5280 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.

The on-chip uarts are supported via the 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. Only those uarts for which GPIO pins are configured appropriately are available. By default this is only uart0 when using an EVA2_SV6 carrier board, and both uart0 and uart1 when using an EVA6 carrier board. One of the uarts, typically uart0, may also be used for HAL diagnostics. If so it should not be accessed via the serial driver.

All configurations for the DNP/5280 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.

An I2C bus device driver is also included, but will not be built by default. If the DNP/5280 is plugged into a DNP/EVA2-SV6 carrier board the relevant pins are already in use, connected to the dip switch. Even if a different carrier board is being used the same pins may still be needed for GPIO or for uart2. If the I2C bus can be safely enabled on the target hardware then GPIO pin configuration options should be adjusted to connect the SCL and SDA signals. The MCF5282 processor HAL will then instantiate a cyg_i2c_bus structure hal_mcfxxxx_i2c_bus, allowing appropriate CYG_I2C_DEVICE structures to be defined.

Similarly an SPI bus device driver is included but will not be built by default. If the GPIO pins are adjusted to connect the QSPI DOUT, DIN and CLK signals then the MCF5282 processor HAL will instantiate an SPI bus device hal_mcfxxxx_qspi_bus, allowing appropriate CYG_MCFxxxx_QSPI_DEVICE structures to be defined.

Some releases may come with a driver CYGPKG_DEVS_CAN_FLEXCAN for the on-chip CAN device. This will be inactive unless the generic CAN support CYGPKG_IO_CAN is added to the configuration. In addition it will be necessary to adjust the GPIO pins to connect the CANTX and CANRX signals.

When configured for a dnp5280_v12 target the configuration will include a wallclock driver CYGPKG_DEVICES_WALLCLOCK_DALLAS_DS1306. 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.

All configurations will include a flash device driver CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2 for the external flash. In addition when configured for a dnp5282 target the configuration will include a flash driver CYGPKG_DEVS_FLASH_M68K_MCFxxxx_CFM. Both drivers will be inactive unless the generic flash support CYGPKG_IO_FLASH is added to the configuration.

On an EVA2_SV6 carrier board the platform HAL provides utility routines for accessing the LEDs and dip switch. 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 remaining on-chip peripherals are not used by eCos.

Tools

The DNP/5280 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.