Name

Setup — Preparing the STM32F429I-DISCO Board for eCos Development

Overview

Typically, since the STM32F429I-DISCO motherboard has a built-in ST-LINK/V2 interface providing hardware debug support, eCos applications are loaded and run via the debugger arm-eabi-gdb or via the Eclipse IDE. The debugger then communicates with the “GDB server” provided by the relevant host ST-LINK/V2 support tool being used (e.g. OpenOCD).

Normally for release applications the ROM startup type would be used, with the application programmed into the on-chip flash for execution when the board boots. It is still possible to use the hardware debugging support to debug such flash-based ROM applications, and this may be the desired approach if the application is too large for execution from SRAM, or where all of the SRAM and SDRAM is required for application run-time use.

Since the stand-alone STM32F429I-DISCO motherboard has limited I/O there is no support for either RedBoot or GDB stubs by default.

Nevertheless, it is still possible to program a GDB stub or RedBoot ROM image into on-chip Flash and download and debug via a serial UART, if pins for the UART are available. In that case, eCos applications are configured for RAM startup and then downloaded and run on the board via the debugger arm-eabi-gdb, or via the Eclipse IDE. By default for serial communications, all versions run with 8 bits, no parity, and 1 stop bit at 115200 baud. This rate can be changed in the eCos configuration used for building the GDB stub ROM image.

Programming ROM images

Since the STM32F429I-DISCO board has a built-in ST-LINK/V2 SWD interface, if the CN4 jumpers are closed then the micro USB host connection (CN1) and suitable host software (e.g. The OpenOCD package openocd tool) can be used to program the flash. Normally a default openocd session provides a comand-line via port 4444. Consult the OpenOCD documentation for more details if a non-default openocd configuration is being used.

With a telnet connection established to the openocd any binary data can easily be written to the on-chip flash. e.g.

$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> flash write_image test.bin 0x08000000
wrote 32518 bytes from file test.bin in 1.073942s (29.569 KiB/s)

To create a binary for flash programming the arm-eabi-objcopy command is used. This converts the, ELF format, linked application into a raw binary. For example:

$ arm-eabi-objcopy -O binary programname programname.bin