Configuration — Platform-specific Configuration Options


The STM32F4DISCOVERY board platform HAL package is loaded automatically when eCos is configured for the stm32f4dis or stm32f4disbb targets. The stm32f4dis target enables the necessary hardware support for the bare STM32F4DISCOVERY board, whereas the stm32f4disbb target is intended to support the STM32F4DISCOVERY board stacked with a “STM32F4DISCOVERY Base Board” (STM32F4DIS-BB). The essential difference between the two targets being that the Base Board target adds Ethernet support. 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 STM32F4DISCOVERY board platform HAL package supports three separate startup types:


This startup type can be used for finished applications which will be programmed into internal Flash ROM at location 0x08000000. Data and BSS will be put into internal SRAM starting from 0x20000288. 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 which is used if relying on a GDB stub ROM image programmed into internal Flash to download and run applications into RAM via arm-eabi-gdb and a serial UART. RAM from 0x20000000 to 0x20001000 is reserved for the GDB stub, but then the RAM startup application may be loaded into memory from 0x20001000 and debugged using GDB. It is assumed that the hardware has already been initialized by the GDB stub ROM. By default the application will use the eCos virtual vectors mechanism to obtain services from the GDB stub ROM, including diagnostic output.


This is the startup type used to build applications that are loaded via a JTAG/SWD interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x20000288 and entered at that address. Memory from 0x20000000 to 0x20000288 is set aside for vector tables. eCos startup code will perform all necessary hardware initialization.

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 GDB stub ROM (or 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 the serial port will be claimed for HAL diagnostic output.

UART Serial Driver

The STM32F4DISCOVERY board uses the STM32's internal UART serial support. The HAL diagnostic interface, used for both polled diagnostic output and GDB stub communication, is only expected to be available to be used on the UART6 port (counting the first UART as UART1). The bare STM32F4DISCOVERY board only exports the UART6 connection via connector P2, but the STM32F4DIS-BB daughterboard provides UART6 on the COM1 (DB9) connector.


In reality when using a hardware SWD debugger (e.g. the on-board ST-LINK/V2 interface) it is preferable to use the on-chip ITM support for HAL diagnostic output. The ITM stimulus port HAL diagnostic interface is significantly faster than using a UART, and provides for a simpler, single cable, debug and diagnostic connection to the target board. The use of ITM for HAL diagnostics is configurable in the architecture HAL.

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 six UARTs can be supported by this driver. Note that it is not recommended to use this driver with a port at the same time as using that port 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. By default this will only enable support in the driver for the USART6 port (the same as the HAL diagnostic interface), but the default configuration can be modified to enable support for other serial ports. Note that in this package, serial port numbering starts at 0, rather than 1. So, for example, to enable the serial driver for ports USART1 and USART2, enable the configuration options "ST STM32 serial port 0 driver" (CYGPKG_IO_SERIAL_CORTEXM_STM32_SERIAL0) and "ST STM32 serial port 1 driver" (CYGPKG_IO_SERIAL_CORTEXM_STM32_SERIAL1).

Ethernet Driver

The STM32F4DIS-BB daughterboard is fitted with an Ethernet port connected via a SMSC LAN8720 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 CYGPKG_DEVS_ETH_CORTEXM_STM32. At the present time it only supports the lwIP networking stack, and cannot be used for either the BSD networking stack or RedBoot.

When using a default eCos configuration the driver will be inactive (not built and greyed out in the eCos Configuration Tool) since that configuration does not include the networking packages. The driver is enabled when the platform HAL option "STM32 Ethernet Support" (CYGPKG_HAL_CORTEXM_STM32_STM32F4DIS_ETH0) is enabled. This option in turn is only active if the "Common Ethernet support" (CYGPKG_IO_ETH_DRIVERS) 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.

SPI Driver

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

Two SPI device entries have been created for use, and the SPI devices structures are defined in the file stm32f4dis_spi.c.

The first device is configured for accessing the MEMS (LIS302DL motion Sensor) on SPI bus 1, using pin PE3 as the chip select.

The second SPI device is for use with the Aardvark SPI test board, which has an SPI EEPROM available. This is only intended for testing. If used, it is present on SPI bus 2 and will use pin PB14 as the SPI chip select pin.

To disable support for both the above SPI devices, the platform HAL contains an option "SPI devices" (CYGPKG_HAL_CORTEXM_STM32_STM32F4DIS_SPI) 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.

I²C Driver

The STM32 variant HAL provides the main I²C hardware driver itself, configured at CYGPKG_HAL_STM32_I2C. However, the platform I²C support can also be configured separately at CYGPKG_HAL_CORTEXM_STM32_STM32F4DIS_I2C. This option is present to allow use of the external Aardvark test board which has an I²C EEPROM fitted that is used for testing purposes. The option also ensures the STM32's I²C bus 1 is enabled as required.

Flash Driver

The STM32's on-chip Flash may be programmed and managed using the Flash driver located in the "STM32 Flash memory support" (CYGPKG_DEVS_FLASH_STM32) package. This driver is enabled automatically if the generic "Flash device drivers" (CYGPKG_IO_FLASH) package is included in the eCos configuration.

The driver will configure itself automatically for the size and parameters of the specific STM32 variant present on the STM32F4DISCOVERY board. However, if necessary the driver contains a configuration option "Flash size override (kb)" (CYGNUM_DEVS_FLASH_STM32_FLASH_SIZE_OVERRIDE) which allows the detected Flash size to be manually overriden, but this should not normally need to be changed.

A number of other aspects of Flash driver behaviour can be configured within that driver, such as program/erase parallelism and programburst size. Consult the driver for more details.