Hardware debugging support
Prev Chapter 302. STM32H735-DISCO Platform HAL Next

Name

SWD support — Usage

Use of JTAG/SWD for debugging

JTAG/SWD can be used to single-step and debug loaded applications, or even applications resident in ROM.

Debugging of ROM applications is only possible if using hardware breakpoints. The Cortex-M7 core of the STM32H735IG only supports eight such hardware breakpoints, so they may need to be used sparingly. If using a GDB front-end such as Eclipse, check it has not set unnecessary extra breakpoints such as at main(). Some JTAG/SWD devices give the option of whether to set hardware or software breakpoints by default. Be sure to configure your device appropriately.

When debugging via JTAG, you are likely to need to disable the default HAL idle thread action, otherwise there may be issues where the target fails to halt and the debugging session is unreliable. More details can be found in the Cortex-M architectural HAL. This should not be necessary when using a SWD-based hardware debugger such as the on-board ST-LINK/V3E interface.

Using the ST-LINK/V3E USB connection allows for a single cable to provide power, hardware debug support and diagnostic output. The latter is provided via a virtual UART which instantiates an ACM compatible serial channel in the host which is connected to USART2 on the STM32H735IG. A separate application may be run alongside the debugger to capture the output from this UART, such as minicom under Linux or PuTTY under Windows.

OpenOCD notes

OpenOCD version 0.11.0 and above is required to support the STM32H735IG MCU. A prebuilt host openocd executable which also supports the on-board ST-LINK/V3E interface available via the USB CN15 connection has been provided with the eCosPro Host Tools version 5.0.0 and above.

Should you wish to rebuild openocd yourself, you must specify the --enable-stlink option when configuring the OpenOCD build to provide for ST-LINK support.

An example OpenOCD configuration file openocd.stm32h735_disco.cfg is provided within the eCos platform HAL package in the source repository. This will be in the directory packages/hal/cortexm/stm32/stm32h735_disco/current/misc relative to the root of your eCosPro installation, but for convenience it is copied into the install/etc subdirectory as openocd.cfg during the make etc build process of the eCosPro library.

This configuration file can be used with OpenOCD on the host as follows: 

$ openocd -f openocd.stm32h735_disco.cfg
Open On-Chip Debugger 0.11.0 (eCosCentric)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V3J7M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.287824
Info : stm32h7x.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections

By default openocd provides a telnet console on port 4444, and this can be used to interact with the target system. This console interface can be used to perform debugging, program the flash, etc.

Normally arm-eabi-gdb is used to connect to the default GDB server port 3333 for debugging. For example: 

(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in ?? ()
(gdb)

OpenOCD should report the following on its terminal when a GDB connection is made: 

Info : accepting 'gdb' connection on tcp/3333

Initialising CPU...
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000d40 msp: 0x2404fc00
force hard breakpoints
Note: Breakpoints limited to 8 hardware breakpoints
Invalidate ICACHE
Invalidate DCACHE
Disable Caches

Info : Device: STM32H72x/73x
Info : flash size probed value 1024
Info : STM32H7 flash has a single bank
Info : Bank (0) size is 1024 kb, base address is 0x08000000

The application can then be loaded and executed under GDB as normal. If you are using Eclipse then, if required, you can define a “preload” gdb macro to emit any necessary commands to OpenOCD. See the “Hardware Assisted Debugging” section of the “Eclipse/CDT for eCos application development” document's “Debugging eCos applications” chapter.

[Note]Note

Incompatibilities between OpenOCD and the STM32H7 cache support mean that at present only hardware breakpoints should be used for debugging. The OpenOCD configuration file provided within the eCosPro Developer's kit enforces this.

Configuration of JTAG/SWD applications

JTAG/SWD applications can be loaded directly into SRAM without requiring a ROM monitor. Loading can be done directly through the JTAG/SWD device, or through GDB where supported by the JTAG/SWD device.

In order to configure the application to support this mode, it is recommended to use the JTAG startup type which will implicitly cause two important settings to change. Firstly, CYGSEM_HAL_USE_ROM_MONITOR must be disabled. Secondly the CYGDBG_HAL_DIAG_TO_DEBUG_CHAN option should be enabled in order to prevent HAL diagnostic output being encoded into GDB ($O) packets. These configuration changes could be made by hand, but use of the JTAG startup type will just work.

With these changes, any diagnostic output will appear out of the configured diagnostic channel. An eCosCentric extension allows diagnostic output to appear in GDB. For this feature to work, you must enable the configuration option CYGSEM_HAL_DIAG_TO_GDBFILEIO_CHAN in the common HAL package. If you are using the graphical configuration tool then you should then accept any suggested solutions to the subsequent configuration conflicts. Older eCos releases also required the gdb "set hwdebug on" command to be used to enable GDB or Eclipse console output, but this is no longer required with the latest tools.

Prev Up Next
Configuration Home The HAL Port