The STM32F746G-DISCO board platform HAL package CYGPKG_HAL_CORTEXM_STM32_STM32F746G_DISCO is loaded automatically when eCos is configured for the stm32f746g_disco 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 STM32F746G-DISCO board platform HAL package supports five separate startup types:
This startup type can be used for finished (stand-alone) applications which will be programmed into internal flash at location 0x08000000. Data and BSS will be put into external SDRAM starting from 0x60000000. 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 startup type can be used for finished applications which will be programmed into internal flash at location 0x08000000. Data and BSS will be put into internal SRAM starting from 0x200002C8. Internal SRAM below this address is reserved for vector tables. 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.
The off-chip SDRAM memory from 0x60000000 is available, but is not referenced by the eCos run-time so is available for application use if required.
This is the startup type used to build applications that are loaded via the hardware debugger interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded into off-chip SDRAM from 0x60000000 and entered at that address. eCos startup code will perform all necessary hardware initialization, though since the application is loaded via the hardware debugger interface the host debug environment is responsible for configuring the necessary I/O state to initialise the off-chip SDRAM.
This is the startup type normally used during application development, since the large SDRAM memory space allows for larger debug applications where compiler optimisation may be disabled, and run-time assert checking enabled.
Note: Executing code from the SDRAM memory has a performance downside. It is significantly slower than execution from on-chip SRAM or flash. If performance is an issue then hardware debugging can be used for any of the startup types if required.
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 0x200002C8 and entered at that address. eCos startup code will perform all necessary hardware initialization. Unlike the JTAG startup no explicit hardware debugger configuration is needed, since the application (like the ROM and ROMINT startup types) will initialise the off-chip SDRAM memory.
For the ST-LINK/V2-1 enabled STM32F746G-DISCO platform this startup type is unlikely to be used. It is provided for completeness.
When the board has RedBoot (or a GDB stub ROM) programmed into internal Flash at location 0x08000000 then the arm-eabi-gdb debugger can communicate with a suitably configured UART connection to load and debug applications. An application is loaded into memory from 0x60008000. It is assumed that the hardware has already been initialized by RedBoot. By default the application will not be stand-alone, and will use the eCos virtual vectors mechanism to obtain services from RedBoot, including diagnostic output.
RedBoot can have an adverse affect on the real-time performance of applications.
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
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.
Note: Though, as previously discussed, since the option of hardware debugging is available as standard on the STM32F746G-DISCO platform it is unlikely that the RAM startup type would be used for development.
An SPI bus driver is available for the STM32 in the package
“ST STM32 SPI driver”
No SPI devices are instantiated for this platform by default.
Note: An example SPI M25PXX configuration can be enabled for boards suitably modified with an attached compatible flash device. The CDL option
CYGPKG_HAL_CORTEXM_STM32_STM32F746G_DISCO_SPIcan be enabled, and uses SPI bus 2 with the chip-select on PI0.
When configured the
m25pxx_flash_devicedevice is exported and can be accessed via the standard flash API. The device is given a logical base address of 0x00000000 but is not memory-mapped.
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
enables I2C buses 1 and 3. The instantiated devices become available
for applications via <cyg/io/i2c.h>.
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
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 STM32F746G-DISCO board.
A number of aspects of Flash driver behaviour can be configured within that driver, such as program/erase parallelism and program burst size. Consult the driver for more details.
The Ethernet MAC is connected to a LAN8742A PHY via the RMII interface and thence to a RJ45 connector at CN9. The external 25MHz crystal is used to supply the clock.