Configuration

Configuration
	Chapter 314. STM32L4R9-DISCO Platform HAL

Overview

The STM32L4R9-DISCO board platform HAL package CYGPKG_HAL_CORTEXM_STM32_STM32L4R9_DISCO is loaded automatically when eCos is configured for the stm32l4r9_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.

Startup

The STM32L4R9-DISCO board platform HAL package supports four separate startup types:

ROM

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

ROMAPP

This startup type can be used for finished applications which will be programmed into internal flash at location 0x08008000. Data and BSS will be put into internal SRAM starting from 0x200002D8. 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.

This startup type is identical to the ROM startup with the exception of the flash base address. It is used for applications that can be started or updated by BootUp.

SRAM

This startup type can be used for finished applications which will be loaded into internal SRAM via a JTAG interface. The application will be self-contained with no dependencies on services provided by other software. The program expects to be loaded from 0x200002D8 and entered at that address. eCos startup code will perform all necessary hardware initialization.

RAM

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

	Warning
	RedBoot can have an adverse affect on the real-time performance of applications.

It should be noted that due to the MFX I/O expander needing to be used to configure the hardware for correct PSRAM operation there is no direct startup type for loading and executing applications from PSRAM. However, there is nothing to stop a suitable boot loader from initialising the hardware appropriately and application code subsequently being loaded into and executed from the PSRAM.

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 STM32L4R9-DISCO platform, and space in the SRAM is limited, 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).

No SPI devices are instantiated for this platform by default.

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_STM32L4R9_DISCO_I2C. This enables I²C bus 1. Some board H/W features are routed via the I²C MFXv3 I/O expander device, and as such, the support for bus 1 is enabled by default. An audio codec is also available on this bus and is instantiated with the name hal_stm32l4r9_disco_cs42l51. The instantiated device is available for applications via <cyg/io/i2c.h>.

ADC Driver

The STM32 processor variant HAL provides an ADC driver. The STM32L4R9-DISCO platform HAL enables the support for the device ADC1 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.

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

OCTOSPI Flash Driver

When OCTOSPI NOR flash support is enabled in the configuration with CYGHWR_HAL_CORTEXM_STM32_FLASH_OCTOSPI, then the cyg_stm32_octospi1_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_OCTOSPI1_CORTEXM_STM32_MEMMAPPED is enabled in the OCTOSPI driver, which is not the default). When memory mapping is disabled, using the eCos Flash API will still allow the device to be read/written at that logical base address.


Setup		Hardware debugging support

Name