eCosPro® Reference Manual
Prev |  | Next

# Configuration

## Name

Configuration -- Platform-specific Configuration Options

## Overview

The STR710-EVAL Board platform HAL package is loaded automatically when eCos is configured for an str710eval 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.

## Startup

The STR710-EVAL Board platform HAL package supports four separate startup types:

RAM

  This is the startup type which is normally used during application development. The board has RedBoot programmed into external Flash at location 0x60000000 and uses external RAM at location 0x62000000. arm-elf-gdb is then used to load a RAM startup application into memory from 0x62020000 and debug it. It is assumed that the hardware has already been initialized by RedBoot. By default the application will use the eCos virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output.

ROM

  This startup type can be used for finished applications which will be programmed into external ROM at location 0x60000000. The application will be self-contained with no dependencies on services provided by other software. The program expects to boot from reset with ROM mapped at location zero. It will then transfer control to the 0x20000000 region and map internal RAM to location zero. eCos startup code will perform all necessary hardware initialization.

ROM_INT

  This startup type can be used for finished applications which will be programmed into internal Flash at location 0x40000000. The application will be self-contained with no dependencies on services provided by other software. The program expects to boot from reset with ROM mapped at location zero. It will then transfer control to the 0x40000000 region and map internal RAM to location zero. eCos startup code will perform all necessary hardware initialization.

  This startup is enabled by setting the CYGHWR_HAL_STR7XX_FLASH_INTERNAL option, when CYG_HAL_STARTUP is set to ROM.

ROM_INT_EXTRAM

  This startup type can be used for finished applications which will be programmed into internal Flash at location 0x40000000. The application will be self-contained with no dependencies on services provided by other software. The program expects to boot from reset with ROM mapped at location zero. It will then transfer control to the 0x40000000 region and map internal RAM to location zero. eCos startup code will perform all necessary hardware initialization. The application will also use external RAM at 0x62000000 for its DATA, BSS and heap, rather than the internal SRAM.

  This startup is enabled by setting the CYGHWR_HAL_STR7XX_FLASH_INTERNAL option, when CYG_HAL_STARTUP is set to ROM and additionally setting CYGHWR_HAL_ARM_STR710EVAL_EXT_RAM.

JTAG

  This is the startup type used to build applications that are loaded via a JTAG interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x62000000 and entered at that address. It will then map internal RAM to location zero. eCos startup code will perform all necessary hardware initialization and the system will be in a condition suitable for loading and running RAM applications.

## The Stubrom 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, as a testing step before switching to ROM startup.

If the application does not rely on a ROM monitor for diagnostic services then serial port 0 will be claimed for HAL diagnostics.

## Flash Drivers

The STR710-EVAL board contains a 4Mbyte ST M28W320CB parallel Flash device. The CYGPKG_DEVS_FLASH_STRATA_V2 package contains all the code necessary to support this part and the platform HAL package contains definitions that customize the driver to the STR710-EVAL board. This driver is not active until the generic Flash support package, CYGPKG_IO_FLASH, is included in the configuration.

A driver is also present for the internal Flash. The package CYGPKG_DEVS_FLASH_STR7XX contains all the code necessary to support this memory and the platform HAL package contains definitions that customize the driver to the STR710-EVAL board. This driver is not active until the generic Flash support package, CYGPKG_IO_FLASH, is included in the configuration.

## Watchdog Driver

The STR710-EVAL board use the STR7XX's internal watchdog support. The CYGPKG_DEVICES_WATCHDOG_ARM_STR7XX package contains all the code necessary to support this device. Within that package the CYGNUM_DEVS_WATCHDOG_ARM_STR7XX_DESIRED_TIMEOUT_US configuration option controls the watchdog timeout, and by default will force a reset of the board upon timeout. This driver is not active until the generic watchdog device support package, CYGPKG_IO_WATCHDOG, is included in the configuration.

## UART Serial Driver

The STR710-EVAL boards use the STR7XX's internal UART serial support. As well as the polled HAL diagnostic interface, there is also a CYGPKG_IO_SERIAL_ARM_STR7XX package which contains all the code necessary to support interrupt-driven operation with greater functionality. All four UARTs can be supported by this driver, although only UARTs 0 and 1 are actually routed to external connectors. Note that it is not recommended to enable this driver on the port used for HAL diagnostic I/O. This driver is not active until the CYGPKG_IO_SERIAL_DEVICES configuration option within the generic serial driver support package CYGPKG_IO_SERIAL is enabled in the configuration.

The STR7XX UARTs only provide the minimal TX and RX data lines; hardware flow control using RTS/CTS is not supported. The eCos device drivers have been extended to permit the use of a pair of GPIO lines to be use as flow control lines. These must be defined by the platform for each UART using the following CDL options:

CYGHWR_HAL_ARM_STR7XX_UARTX_RTS

  This value encodes which PIO line will be used as the RTS line for UARTX. The value of this option is an invocation of the macro UART_PIO(), which takes three arguments: the first is the PIO port number and the second is the bit number in that port for the PIO line. The third argument gives the polarity of the line, 0 if it is active low, 1 if it is active high.

CYGHWR_HAL_ARM_STR7XX_UARTX_CTS

  This value encodes which PIO line will be used as the CTS line for UARTX. UART_PIO() takes three arguments: the first is the PIO port number and the second is the bit number in that port for the PIO line. The third argument gives the polarity of the line, 0 if it is active low, 1 if it is active high.

CYGHWR_HAL_ARM_STR7XX_UARTX_CTS_INT

  This must be the name of the interrupt vector, from var_intr.h, that corresponds to the PIO bit selected for CTS. It is essential that the PIO bit selected be capable of generating an interrupt, so only those that have an XTI interrupt vector can be used. The polarity of the CTS line will decide whether this interrupt occurs on a rising or falling edge.

## I2C Support

Support for the two I2C® busses is provided by the variant HAL (CYGPKG_HAL_ARM_STR7XX). The STR710-EVAL board carries an ST M24C08 I2C serial EEPROM connected to bus 0.

The M24C08 is an 8Kibit device, 1024 bytes. This memory is addressed by using a single byte for the least significant 8 bits of the address plus 2 bits from the device's I2C address. Within eCos, this EEPROM is presented as four separate I2C devices at addresses 0xA8, 0xAA, 0xAC, 0xAE. These are instantiated as four I2C device objects, named cyg_i2c_str710eval_m24c08_0, cyg_i2c_str710eval_m24c08_1, cyg_i2c_str710eval_m24c08_2 and cyg_i2c_str710eval_m24c08_3 respectively.

A test application for use with the EEPROM is provided within the `tests` subdirectory of the CYGPKG_HAL_ARM_STR7XX_STR710EVAL package. This test communicates with the I2C EEPROM on the board to perform read and write operations using I2C. Since it overwrites the contents of the EEPROM, this test is not built by default. It may be built by enabling the configuration option CYGBLD_HAL_ARM_STR7XX_STR710EVAL_TEST_M24C08.

## System Clock

By default, the system clock interrupts once every 10ms, corresponding to a 100Hz clock. This can be changed by the configuration option CYGNUM_HAL_RTC_DENOMINATOR which corresponds to the clock frequency. Other clock-related settings are recalculated automatically if the denominator is changed. The description of the clock-related options may be found in the STR7XX variant HAL documentation.

## 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.

The option "-mcpu=arm7tdmi" should be set for all compilations for this platform.

There are two flags that are used if Thumb mode is to be supported:

-mthumb

  The arm-elf-gcc compiler will compile C and C++ files into the Thumb instruction set when this option is used.

-mthumb-interwork

  This option allows programs to be created that mix ARM and Thumb instruction sets. Without this option, some memory can be saved. This option should be used if -mthumb is used.

Prev | Home | Next
Setup | Up | JTAG debugging support