The STM3210C-EVAL board platform HAL package is loaded automatically when eCos is configured for an stm3210c_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.
The STM3210C-EVAL board platform HAL package supports three separate startup types:
This is the startup type which is normally used during application development. The board has GDB stubs programmed into internal Flash at location 0x08000000 and uses internal RAM at location 0x20000000. arm-eabi-gdb is then used to load a RAM startup application into memory from 0x20001000 and debug it. It is assumed that the hardware has already been initialized by the stubs. By default the application will use the eCos virtual vectors mechanism to obtain services from the stubs, including diagnostic output.
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 RAM 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.
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 0x20000400 and entered at that address. eCos startup code will perform all necessary hardware initialization.
Monitors 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 the Stubrom.
If the application is supposed to make use of services provided by
a ROM monitor, via the eCos virtual vector mechanism, then the
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 STM3210C-EVAL board uses the STM32's internal UART serial
support. As well as the polled HAL diagnostic interface, there is
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 USART1 is actually
routed to an external connector. 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
The STM3210C-EVAL board is fitted with an Ethernet port connected
via a DP83848 PHY to the STM32's on-chip Ethernet MAC. This is supported
in eCosPro with a driver for the lwIP networking stack,
contained in the package
At the present time it only supports the lwIP networking stack, and cannot
be used for either the BSD networking stack, nor RedBoot.
The driver will be inactive (not built and greyed out in the eCos
Configuration Tool) unless the platform HAL option "STM32
is enabled. This option in turn is only active if the "Common
Ethernet support" (
package is included in your configuration. As the STM32 ethernet
driver is an lwIP-only driver, it is most appropriate to choose
the lwip_eth template as a starting point when
choosing an eCos configuration, which will cause the necessary
packages to be automatically included.
The STM32 ethernet driver defines a further configuration option
"Use MCO as PHY clock"
which indicates whether the MCO1 clock signal is used as the
25MHz clock for the Ethernet PHY. With this option disabled, the
on-board 25MHz crystal oscillator located at X1 can be used
instead, although in that case the board jumper JP4 must be
changed. You may wish to make this change if you wish to use the
MCO1 clock output for another purpose. Consult the STM32 clock
and ethernet documentation for more details.
The STM32 variant HAL provides the main I²C hardware driver itself,
CYGPKG_HAL_STM32_I2C. But the platform
I²C support can also be configured separately at
CYGPKG_HAL_CORTEXM_STM32_STM3210C_EVAL_I2C. This ensures
that the M24C64 serial EEPROM is instantiated and becomes available for
applications from <cyg/io/i2c.h>, and also
ensures the STM32's I²C bus 1 is enabled for it. This option also
allows the m24c64.c test is built. In order to allow writes to the serial
EEPROM, you must ensure that the STM3210C-EVAL jumper JP17 is fitted.
The m24c64.c test will not pass otherwise.
An SPI bus driver is available for the STM32 in the package
"ST STM32 SPI driver" (
The only SPI device instantiated by default is for an external
Aardvark SPI test board, connected to SPI bus 3 with the SD card
attached to chip select 0 on PA4 and the Aardvark AT25080 to chip
select 1 on PD2 (CN8 pin 24). To disable the Aardvark device
support, the platform HAL contains an option "SPI devices"
which can be disabled. No other SPI devices are instantiated.
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.
The STM32 processor variant HAL provides an ADC driver. The STM3210C-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.