Overview

Typically, since the STM32H7 Nucleo-144 motherboard has a built-in STLINK-V3 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 STLINK-V3 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 on-chip SRAM, or where all of the SRAM is required for application run-time use.

If off-chip non-volatile memory (NVM) is used to hold the main application then the board can boot from the internal flash using a suitable boot loader. For example, the eCosPro BootUp ROM loader, where the BootUp code can start the main application (after an optional update sequence).

Preparing Board for Use

The STM32H7 Nucleo-144 board is distributed with some example firmware already loaded into the flash. This is useful for checking that the board is functional after unpacking. However, it is recommended that it be replaced before loading eCos applications for development since it can interfere with the board setup that eCos applications expect.

An executable, stminfo.elf, is provided as part of the release within the prebuilt subdirectory of the eCosPro release installation and this should be programmed into the ROM before use. Details on how to do this are described in the Programming ROM images section below.

Preparing the ST-LINK/V3E interface

The ST-LINK/V3E firmware delivered with the board should be sufficiently up to date to work with debug servers like OpenOCD. The firmware for the ST-LINK/V3E interface can be checked, and updated if needed, using a tool available from STMicroelectronics. The firmware version is also reported when the openocd command is executed (using a suitable configuration file):

Info : STLINK V3J8M3 (API v3) VID:PID 0483:374E

The user should refer to the ST “ST-LINK/V3E firmware upgrade” Release Note, which provides detail on the host requirements for upgrading the ST-Link firmware on Linux, Mac OS X and Windows hosts.

Programming ROM images

Since the STM32H7 Nucleo-144 board has a built-in ST-LINK/V3E SWD interface, the USB host connection (CN1) and suitable host software (e.g. The OpenOCD package openocd tool) can be used to program the flash.

The openocd GDB server can directly program flash based applications from the GDB load command.

	Note
	The openocd command provided with the eCosPro Host Tools has been configured and built to support the ST-LINK/V3E interface. Should you wish to rebuild openocd yourself, you must specify the --enable-stlink option when configuring the OpenOCD build. Additional information on running openocd may be found in the OpenOCD notes.

For example, assuming that openocd is running on the same host as GDB, and is connected to the target board the following will program the stminfo.elf application into the on-chip flash:

$ arm-eabi-gdb stminfo.elf
GNU gdb (eCosCentric GNU tools 7.3.0d) 8.1
[ … GDB output elided … ]
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
=> 0x8000d40:	push	{r3, r4, r5, r6, r7, lr}
0x08000d40 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x8000000
Loading section .text, size 0x3be8 lma 0x8000008
Loading section .rodata, size 0x6bc lma 0x8003bf0
Loading section .data, size 0x1c8 lma 0x80042b0
Start address 0x8000008, load size 17524
Transfer rate: 12 KB/sec, 4381 bytes/write.
(gdb) cont

Following the cont command, the following output should appear on the virtual UART:

INFO:<code from 0x08000008 -> 0x08003f00, CRC c29f>
INFO:<STM32 CPU information>
INFO:<CDL Cortex-M7>
INFO:<MCU ID 10016483 DEV H72x/H73x REV Z>
INFO:<CPU reports flash size 1024K>
INFO:<Unique-ID: 000E000F 31395118 38323331>
INFO:<Variant Unique-ID maximum length 12>
INFO:<CYGARC_HAL_CORTEXM_STM32_INPUT_CLOCK 8000000>
INFO:<SYSCLK 400000000>
INFO:<HCLK   200000000>
INFO:<PCLK1  100000000>
INFO:<PCLK2  100000000>
INFO:<PCLK3  100000000>
INFO:<PCLK4  100000000>
INFO:<QCLK    50000000>
INFO:<Cortex-M systick 50000000>
INFO:<Dcache enabled>
INFO:<Icache enabled>
PASS:<Done>
EXIT:<done>

Alternatively, the openocd telnet interface can be used to manually program the flash. By default the 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 stminfo.bin 0x08000000
Padding image section 0 at 0x080047c4 with 28 bytes (bank write end alignment)
wrote 18400 bytes from file stminfo.bin in 0.073288s (245.180 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