Configuration

Configuration
	Chapter 299. STM32X0G-EVAL Platform HAL

Overview

The STM32X0G-EVAL board platform HAL package is loaded automatically when eCos is configured for an stm3220g, stm3240g or stm3241g 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 STM32X0G-EVAL board platform HAL package supports five separate startup types:

RAM: This is the startup type which is normally used during application development. The board has RedBoot programmed into internal Flash at location 0x08000000 and uses external RAM at location 0x64000000. arm-eabi-gdb is then used to load a RAM startup application into memory from 0x64008000 and debug it. It is assumed that the hardware has already been initialized by RedBoot. By default the application will use the eCos virtual vectors mechanism to obtain services from RedBoot, including diagnostic output.
ROM: This startup type can be used for finished applications which will be programmed into internal ROM at location 0x08000000. Data and BSS will be put into external RAM starting from 0x64000000. 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.
ROMINT: This startup type can be used for finished applications which will be programmed into internal ROM at location 0x08000000. Data and BSS will be put into internal SRAM starting from 0x20000284 (F2) or 0x20000288 (F4). 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.
JTAG: This is the startup type used to build applications that are loaded 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 0x64000000 and entered at that address. eCos startup code will perform all necessary hardware initialization.
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 0x20000284 (F2) or 0x20000288 (F4) and entered at that address. eCos startup code will perform all necessary hardware initialization.

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.

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 STM32X0G-EVAL board uses the STM32's internal UART serial support. The HAL diagnostic interface, used for both polled diagnostic output and RedBoot / GDB stub communication, is only expected to be available to be used on the UART 4 port (counting the first UART as UART1). This is because only UART 4 is actually routed to an external connector.

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: while it is possible for USART3 to be configured to use this connector, the only advantage of USART3 would be flow control lines, which are not routed to the connector on the STM32X0G board.

It is not recommended to use the interrupt-driven serial 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 UART4 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 STM32X0G-EVAL board is fitted with an Ethernet port connected via a DP83847 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, nor RedBoot.

The driver will be inactive (not built and greyed out in the eCos Configuration Tool) unless the platform HAL option "STM32 Ethernet Support" (CYGPKG_HAL_CORTEXM_STM32_STM32X0G_EVAL_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.

The platform HAL defines a further configuration option "Use MCO as PHY clock" (CYGHWR_HAL_CORTEXM_STM32X0G_ETH_PHY_CLOCK_MCO) which indicates whether the MCO1 clock signal is used as the 25MHz clock for the Ethernet PHY. With this option disabled, the on-board 25MHz crystal oscillator located at X1 can be used instead, although in that case the board jumper J5 must be changed. You may wish to make this change if you wish to use the MCO1 clock output for another purpose. Consult the STM32 clock and ethernet documentation for more details.

SPI Driver

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

The only SPI device instantiated by default is for an external Aardvark SPI test board, connected to SPI bus 2 with pin PI0 selected as the chip select. To disable the Aardvark device support, the platform HAL contains an option "SPI devices" (CYGPKG_HAL_CORTEXM_STM32_STM32X0G_EVAL_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. But the platform I²C support can also be configured separately at CYGPKG_HAL_CORTEXM_STM32_STM32X0G_EVAL_I2C. This ensures that the M24C64 serial EEPROM is instantiated and becomes available for applications from <cyg/io/i2c.h>, and also ensures the STM32's I²C bus 1 is enabled for it. This option also allows the m24c64.c test is built. In order to allow writes to the serial EEPROM, you must ensure that the STM32X0G-EVAL jumper JP24 is fitted. The m24c64.c test will not pass otherwise.

ADC Driver

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

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 shares IO pins with the FSMC, which controls the external SRAM. Therefore, BXCAN1 can only be used in ROMINT startup mode.

The board has a single external CAN socket, to which either BXCAN1 or BXCAN2 can be routed, based on the settings of JP3 and JP10. By default these jumpers are set to route neither CAN device to the socket, and jumpers must be fitted to route the desired CAN device as appropriate. See the board reference manual for details.

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 STM32X0G 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		JTAG debugging support

Name