Name
Configuration — Platform-specific Configuration Options
Overview
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.
Startup
The STM32F4DISCOVERY board platform HAL package supports three separate startup types:
- ROM
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 from0x20000288
. 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 the0x08000000
region. eCos startup code will perform all necessary hardware initialization.- RAM
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
to0x20001000
is reserved for the GDB stub, but then the RAM startup application may be loaded into memory from0x20001000
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.- JTAG
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 from0x20000000
to0x20000288
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.
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
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.
2024-12-10 | eCosPro Non-Commercial Public License |