Configuration

Configuration
	Chapter 310. STM32F7XX-EVAL Platform HAL

Overview

The STM32F7XX-EVAL board platform HAL package is loaded automatically when eCos is configured for the stm32f746g_eval2 or stm32f746g_proto targets. 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 STM32F7XX-EVAL board platform HAL package supports six separate startup types.

Note

Due to Cortex-M limitations regarding executable addresses, and the STM32F7 FMC memory bank address locations, it is not possible to have a configuration with code executing from SDRAM and PSRAM/NOR without run-time support for manipulating FMC_MEMRMP when moving between regions. The eCos run-time does not provide such support. The relevant CYG_HAL_STARTUP configuration should be chosen for the desired application CODE+DATA memory usage, with the other external memory being used purely for DATA storage.

ROM

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.

The off-chip SRAM memory from 0xC8000000 is available, but is not referenced by the eCos run-time. It is available for application DATA use if required.

ROMAPP

This startup type can be used for finished applications which will be programmed into internal (on-chip) flash at the configured offset from location (0x08000000+CYGIMP_BOOTUP_RESERVED), and started via a suitably configured BootUp ROM loader. Data and BSS will be put into internal SRAM. The application will be self-contained with no dependencies on services provided by other software.

ROMINT

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 and off-chip SRAM memory from 0xC8000000 are available, but are not referenced by the eCos run-time so are available for application use if required. The SDRAM can be used for CODE+DATA, with the external SRAM for DATA.

JTAG

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 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.

The off-chip SRAM memory from 0xC8000000 is available, but is not referenced by the eCos run-time. It is available for application DATA use if required.

SRAM

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 as required.

The off-chip SRAM memory from 0xC8000000 is also available, but is not referenced by the eCos run-time. It is available for application DATA use if required.

SRAMEXT

This is a variation of the JTAG type that uses the external SRAM memory addressed from 0x68000000.

The off-chip SDRAM memory from 0xC0000000 is also available, but is not referenced by the eCos run-time. It is available for application DATA use if required.

RAM

For the ST-LINK/V2 enabled STM32F7XX-EVAL 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 the relevant UART connection to load and debug applications. An application is loaded into memory from 0x60100000. 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.

	Note
	As well as having a memory footprint cost, RedBoot use can adversely affect the real-time performance of an eCos application.

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 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.

	Note
	Though, as previously discussed, since the option of hardware debugging is available as standard on the STM32F7XX-EVAL platform it is unlikely that the `RAM` startup type would be used for development.

SPI Driver

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

When QSPI NOR flash support is enabled in the configuration with CYGHWR_HAL_CORTEXM_STM32_FLASH_QSPI, then the m25pxx_flash_device device is exported and can be accessed via the standard flash API. The device is given a logical base address to match its physical base address of 0x90000000 (corresponding to FMC bank 4) when it is memory mapped (if CYGFUN_DEVS_FLASH_QSPI_CORTEXM_STM32_MEMMAPPED is enabled in the QSPI driver, which is the default). Even if memory mapping is disabled, using the eCos Flash API will still allow the device to be read/written at that logical base address.

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. Since the platform uses an I²C bus 1 based I/O expander the I²C support is always enabled. The touch-panel device is instantiated and becomes available for applications from <cyg/io/i2c.h>.

ADC Driver

The STM32 processor variant HAL provides an ADC driver. The STM32F7XX-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.

Ethernet Driver

The Ethernet MAC is connected to a DP83848 PHY via the MII interface and thence to a RJ45 connector at CN9. By default the external 25MHz crystal is used to supply the clock and JP6 must be set to the 1-2 position, which should be the default setting. The MMIO and MDC signals must be connected to PA2 and PC1, so JP21 and JP22 should be set to the 1-2 position, which should also be the default settings.

By default solder bridges SB36, SB47 and SB9 are open, which means that MII_CRS, MII_COL and MII_RX_ER are not connected to the PHY. Without MII_CRS and MII_COL, the MAC will only operate in full duplex mode and not half duplex. This means that it will work with Ethernet switches, but not with older hubs.

CAN Driver

The STM32 has a dual BXCAN device for CAN support. This consists of a master device, BXCAN1, and a slave device, BXCAN2. If BXCAN2 is to be used, BXCAN1 must be powered and clocked, regardless of whether it is to be used for CAN traffic. BXCAN1 is the only device connected to an external D-Sub socket at CN22. It shares an IO pin with the OTG FS controller. JP8 controls connection of CAN1_RX to PA11. By default this jumper is not fitted, so one must be fitted to enable BXCAN1. Additionally, the OTG_FS1 connector at CN13 cannot now be used and must be left unconnected. This means that the OTG_FS USB controller and CAN cannot be used concurrently.

Consult the generic CAN driver API documentation in the eCosPro Reference Manual for further details on CAN support in eCosPro, along with the documentation and configuration options in the BXCAN device driver.

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 STM32F7XX-EVAL 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.


Setup		Hardware debugging support

Name