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 STM32H723ZG 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
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 USART3 on the STM32H723ZG. 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.
and above is required to support the STM32H723ZG MCU.
A prebuilt host openocd executable which
also supports the on-board ST-LINK/V3E interface available via
the USB CN1 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
when configuring the OpenOCD build to provide for ST-LINK support.
An example OpenOCD configuration file
openocd.nucleo144.cfg is provided
within the eCos platform HAL package in the source repository.
This will be in the directory
relative to the root of your eCosPro installation, but for
convenience it is copied into the
openocd.cfg during the
make etc build process of the eCosPro
This configuration file can be used with OpenOCD on the host as follows:
openocd -f openocd.nucleo144_disco.cfgOpen 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 V3J8M3 (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
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
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.
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
CYGSEM_HAL_USE_ROM_MONITOR must be
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
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.
|2022-03-29||eCosPro Non-Commercial Public License|