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.
CYGPKG_HAL_M68K_DNP5280 provides a
port to both modules. Specifically it supports the following targets:
A DNP/5280 module plugged into an EVA2_SV6 carrier board.
A V1.2 DNP/5280 plugged into an EVA2_SV6 carrier board. This adds support for the DS1306 clock device on this revision of the module.
A DNP/5282 plugged into an EVA6 carrier board.
eCos configuration options can be used to change the settings.
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:
This is the startup type normally used during application development. RedBoot is programmed into flash and performs the initial bootstrap. m68k-elf-gdb is then used to load a RAM startup application into memory and debug it. By default the application will use eCos' virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output. The RAM startup type can also be used for finished applications: RedBoot can be made to load and run such applications automatically following bootstrap.
With a minor change to the eCos configuration this startup type can also be used to debug applications via BDM. eCos will no longer assume the presence of RedBoot and hence will not make any virtual vector calls to obtain RedBoot services.
This is another variant of RAM startup, used only when initializing a board. It can be used to run a special RAM-resident version of RedBoot on top of the dBUG ROM monitor, allowing a ROM startup version of RedBoot to be programmed into flash.
This should be used for applications which will boot directly from flash at location 0xFF800000, replacing any ROM monitor. The application will be self-contained. eCos startup code will perform all necessary hardware initialization. ROM startup is used for building the flash-resident version of RedBoot, but can also be used for finished applications.
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
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
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
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
CYG_MCFxxxx_QSPI_DEVICE structures to
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
will be used automatically by the C library's time-related functions,
asctime, and can be changed by an eCos-specific
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.
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
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_USE_ROM_MONITOR disabled to stop eCos
accessing any services provided by RedBoot. Diagnostic output will be
sent out of uart0.