Description

There are currently three variants of ST's STM32 "G" evaluation board, the STM3220G-EVAL. STM3240G-EVAL and STM3241G-EVAL. This documentation uses "STM32X0G-EVAL" to refer generically to these boards. The boards have "STM32 20-21-45-46 G-EVAL" silk screened on the PCB, with the specific board model only identifiable by the CPU markings.

The STM3220G-EVAL board has a STM32F207IG microcontroller that incorporates 1MiB of internal flash and 128KiB of internal SRAM.

The STM3240G-EVAL board has a STM32F407IG microcontroller that incorporates 1MiB of internal flash and 192KiB of internal SRAM.

The STM3241G-EVAL board has a STM32F417IG microcontroller that incorporates 1MiB of internal flash and 192KiB of internal SRAM.

The boards have an additional 2MiB of external SRAM, and connectors for UART, Ethernet, MicroSD, USB, CAN, JTAG and various other devices.

For typical eCos development, RedBoot or a GDB stub image is programmed into internal FLASH and the CPU boots directly into that. It is then possible to download and debug stand-alone and eCos applications via the gdb debugger using UART4. Alternatively test programs may be downloaded and debugged via a JTAG debugger attached to the JTAG socket.

This documentation describes platform-specific elements of the STM32X0G-EVAL board support within eCos. The STM32 variant HAL documentation covers various topics including HAL support common to STM32 variants, and on-chip device support. This document complements the STM32 documentation.

Supported Hardware

The STM32F207IG has two on-chip memory regions, with the STM32F407IG and STM32F417IG having three on-chip memory regions. The F2 and F4 devices have a RAM region of 128KiB present at 0x20000000 and a 1MiB FLASH region present at 0x08000000 which is aliased to 0x00000000 during normal execution. The STM32F407IG and STM32F417IG devices have another RAM region of 64KiB present at 0x10000000. For all platform variants on-board memory consists of 2MiB of SRAM mapped to 0x64000000.

The STM32 variant HAL includes support for the six on-chip serial devices which are documented in the variant HAL. UART4 is connected to the external connector on the board marked "CN16". There is no connection for hardware flow control (RTS/CTS) lines.

The STM32 variant HAL also includes support for the I²C bus. A single I²C device is instantiated as part of the platform port, which is for the M24C64 serial EEPROM connected via I²C. It is exported to <cyg/io/i2c.h> with the name hal_stm32_i2c_eeprom in the normal way.

Device drivers are provided for the STM32 on-chip Ethernet MAC, ADC interfaces, I²C interface, SPI interface and SDIO interface. Additionally, support is provided for the on-chip watchdog, RTC (wallclock) and a Flash driver exists to permit management of the STM32's on-chip Flash.

The STM32 variant HAL support for the SDIO interface is currently limited to supporting MMC/SD cards. Due to the GPIO availability on the platform by default only 1-bit MMC/SD data accesses are enabled, since 4-bit data access would clash with the UART4 debug channel. If 4-bit mode is required then the platform configuration would need to be changed to avoid the use of UART3/UART4. For 4-bit mode the use of on-chip SRAM for the transfer buffers is recommended to avoid RX overrun and TX underrun errors due to the slow external RAM access speed.

A driver is available for the BXCAN devices present on the chip. Note that BXCAN1 is incompatible with the use of off-chip SRAM. Under normal circumstances ensure jumpers JP3 and JP10 are not fitted so that neither CAN device is enabled, or fitted to enable CAN2 only. Also that JP1 and JP2 are set with pins 2-3 connected to allow SRAM use. These are the factory-supplied defaults for these jumpers.

Also, while the board is fitted with OneNAND Flash, this is not presently supported by the HAL port. The STM32F2 processor and the STM32X0G-EVAL board provide an extremely wide variety of peripherals, but unless support is specifically indicated, it should be assumed that it is not included.

Tools

The board port is intended to work with GNU tools configured for an arm-eabi target. The original port was done using arm-eabi-gcc version 4.4.5, arm-eabi-gdb version 7.2, and binutils version 2.20.1.