eCos® and eCosPro® Reference Manual
Prev		Next

Configuration

Name

Configuration -- Platform-specific Configuration Options

Overview

The STM3210E-EVAL board platform HAL package is loaded automatically when eCos is configured for an stm3210e_eval 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 STM3210E-EVAL board platform HAL package supports five separate startup types:

RAM: This is the startup type which is normally used during application development. The board has RedBoot programmed into internal Flash at location 0x08000000 and uses external RAM at location 0x68000000. arm-eabi-gdb is then used to load a RAM startup application into memory from 0x68008000 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 services from RedBoot, including diagnostic output.
ROM: This startup type can be used for finished applications which will be programmed into internal ROM at location 0x08000000. Data and BSS will be put into external RAM starting from 0x68000000. 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 0x08000000 region. eCos startup code will perform all necessary hardware initialization.
ROMINT: This startup type can be used for finished applications which will be programmed into internal ROM at location 0x08000000. Data and BSS will be put into internal SRAM starting from 0x20000400. 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 0x08000000 region. eCos startup code will perform all necessary hardware initialization.
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 0x68000000 and entered at that address. eCos startup code will perform all necessary hardware initialization.
SRAM: This is a variation of the JTAG type that only uses internal memory. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x20000400 and entered at that address. eCos startup code will perform all necessary hardware initialization.

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

UART Serial Driver

The STM3210E-EVAL board uses the STM32's internal UART serial support. As well as the polled HAL diagnostic interface, there is also a CYGPKG_IO_SERIAL_CORTEXM_STM32 package which contains all the code necessary to support interrupt-driven operation with greater functionality. All five 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.

SPI Driver

An SPI bus driver is available for the STM32 in the package "ST STM32 SPI driver" (CYGPKG_DEVS_SPI_CORTEXM_STM32).

The only SPI device present on the board is the M25PXX device connected to SPI bus 1 using PB2 as the chip-select. To enable support for this device the platform HAL "External SPI M25PXX flash support" (CYGHWR_HAL_CORTEXM_STM32_FLASH_M25PXX) option should be enabled.

Consult the generic SPI driver API documentation in the eCosPro Reference Manual for further details on SPI support in eCosPro, along with the configuration options in the STM32 SPI device driver.

I²C Driver

The STM32 processor variant HAL provides an I²C driver. The STM3210E-EVAL platform HAL enables the support for bus 1 with the on-board STLM75 temperature sensor instantiated by default. It is exported to <cyg/io/i2c.h> with the name hal_stm32_i2c_temperature in the normal way.

Consult the generic I²C driver API documentation in the eCosPro Reference Manual for further details on I²C support in eCosPro, along with the configuration options in the STM32 on-chip I²C driver.

ADC Driver

The STM32 processor variant HAL provides an ADC driver. The STM3210E-EVAL platform HAL enables the support for the devices ADC1, ADC2 and ADC3 and for configuration of the respective ADC device input channels.

Consult the generic ADC driver API documentation in the eCosPro Reference Manual for further details on ADC support in eCosPro, along with the configuration options in the STM32 ADC device driver.

Onboard NAND

The HAL port includes a low-level driver to access the on-board NAND flash memory chip. To enable the driver, ensure that the CYGPKG_DEVS_NAND_ST_NANDXXXX3A and CYGPKG_IO_NAND packages are present in your eCos configuration. The driver is capable of operating with the NAND_RB jumper (JP7) in either position.

CYGHWR_HAL_CORTEXM_STM3210E_EVAL_RB_ON_INT2: Jumper 7 on the board - labelled NAND_RB - controls the wiring of the NAND chip's Ready/Busy line. You must set this option correspondingly. If the jumper is in position 1-2, this option must be 0; in position 2-3, this option must be 1. This setting changes the behaviour of the driver when waiting for slow NAND operations to complete. In position 1-2, the memory controller halts accesses until the chip is ready; in 2-3, memory access is unimpeded but the CPU polls for the chip to signal ready before attempting to read from it. The latter case may yield an efficiency boost in multi-threaded applications.

Partitioning the NAND chip

The NAND chip must be partitioned before it can become available to applications.

A CDL script which allows the chip to be manually partitioned is provided (see CYGSEM_DEVS_NAND_STM3210E_EVAL_PARTITION_MANUAL_CONFIG); if you choose to use this, the relevant data structures will automatically be set up for you when the device is initialised. By default, the manual config CDL script sets up a single partition (number 0) encompassing the entire device.

It is possible to configure the partitions in some other way, should it be appropriate for your setup. To do so you will have to add appropriate code to stm3210e_eval_nand.c.

Prev	Home	Next
Setup	Up	JTAG debugging support

Documentation license for this page: eCosPro License

Privacy & Legal Statements