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.
If the application is intended to act as a ROM monitor, providing
services for other applications, then the configuration
CYGSEM_HAL_ROM_MONITOR should be
set. Typically this option is set only when building the GDB stub ROM
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 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.
Note: 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
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
CYGPKG_IO_SERIAL_DEVICES configuration option
(within the generic serial driver support
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"
"ST STM32 serial port 1 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
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"
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.
An SPI bus driver is available for the STM32 in the package
"ST STM32 SPI driver"
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.
The STM32 variant HAL provides the main I²C hardware driver
CYGPKG_HAL_STM32_I2C. However, the platform
I²C support can also be configured separately
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.
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
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)"
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.