VisualGDB – STM32U5 flashing/Debugging issues

[AndyCap]

Hi There,

I’m evaluating VisualGDB looks pretty good but I am having some issues with the STM32U5A9J-DK : https://www.st.com/en/evaluation-tools/stm32u5a9j-dk.html

First using standard OpenOCD I get the following issue:
<div>C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 59007" -c "telnet_port 59005" -f interface/stlink.cfg -f target/stm32u5x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"</div>
<div>Open On-Chip Debugger 0.12.0 (2023-02-02) [https://github.com/sysprogs/openocd]</div>
<div>Licensed under GNU GPL v2</div>
<div>libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3</div>
<div>For bug reports, read</div>
<div>http://openocd.org/doc/doxygen/bugs.html</div>
<div>Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.</div>
<div>Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD</div>
<div>Warn : The selected adapter does not support debugging this device in secure mode</div>
<div>Info : clock speed 500 kHz</div>
<div>Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED</div>
<div>Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E</div>
<div>Info : Target voltage: 1.790855</div>
<div>Info : [stm32u5x.cpu] Cortex-M33 r0p4 processor detected</div>
<div>Info : [stm32u5x.cpu] target has 8 breakpoints, 4 watchpoints</div>
<div>Info : starting gdb server for stm32u5x.cpu on 59007</div>
<div>Info : Listening on port 59007 for gdb connections</div>
<div>Info : Unable to match requested speed 480 kHz, using 200 kHz</div>
<div>Info : Unable to match requested speed 480 kHz, using 200 kHz</div>
<div>CPU in Non-Secure state</div>
<div>[stm32u5x.cpu] halted due to debug-request, current mode: Thread </div>
<div>xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000</div>
<div>Info : Unable to match requested speed 4000 kHz, using 3300 kHz</div>
<div>Info : Unable to match requested speed 4000 kHz, using 3300 kHz</div>
<div>VisualGDB_OpenOCD_Ready</div>
<div>Info : Listening on port 6666 for tcl connections</div>
<div>Info : Listening on port 59005 for telnet connections</div>
<div>Info : accepting 'gdb' connection on tcp/59007</div>
<div>Warn : Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device.</div>
<div>Error: auto_probe failed</div>
<div>Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.</div>
<div>Error: attempted 'gdb' connection rejected</div>
 

Using the opened (st fork) I can successfully attach and debug but it is having issues flashing external memory:

C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe -c "gdb_port 58967" -c "telnet_port 58965" -f interface/stlink-dap.cfg --set "CHIPNAME STM32U5A9NJXx" -f target/stm32u5x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2023-01-03) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
STM32U5A9NJXx
Info : auto-selecting first available session transport "dapdirect_swd". To override use 'transport select '.
clock_config
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 1.790855
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : clock speed 3300 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0be12477
DEPRECATED! use 'read_memory' not 'mem2array'
Info : [STM32U5A9NJXx.cpu] Cortex-M33 r0p4 processor detected
Info : [STM32U5A9NJXx.cpu] target has 8 breakpoints, 4 watchpoints
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
Info : gdb port disabled
Info : starting gdb server for STM32U5A9NJXx.cpu on 58967
Info : Listening on port 58967 for gdb connections
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
CPU in Non-Secure state
[STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 58965 for telnet connections
Info : accepting 'gdb' connection on tcp/58967
Error executing event gdb-attach on target STM32U5A9NJXx.cpu:
target/stm32x5x_common.cfg:265: Error: invalid command name "gdb_attach_hook"
at file "target/stm32x5x_common.cfg", line 265
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : OTP size is 512 bytes, base address is 0x0bfa0000
Info : New GDB Connection: 1, Target STM32U5A9NJXx.cpu, state: halted
Warn : Prefer GDB command "target extended-remote :58967" instead of "target remote :58967"
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
[STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : OTP size is 512 bytes, base address is 0x0bfa0000
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
[STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Erasing FLASH: 0x08000000-0x08032000...
Info : Programming FLASH (2 sections, 198624 bytes)...
Info : Programming FLASH section 1/2 (620 bytes) at 0x08000000...
Info : Padding image section 0 at 0x0800026c with 4 bytes
Info : Padding image section 1 at 0x080307e4 with 12 bytes (bank write end alignment)
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
DEPRECATED! use 'read_memory' not 'mem2array'
[STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
DEPRECATED! use 'read_memory' not 'mem2array'
Error: Failed to read memory at 0x00000044

 

The version of OpenOCD currently supplied with the ST32CubeIDE IDE is a more recent version and works fine in ST32CubeIDE flashing all external memories:

Open On-Chip Debugger 0.12.0-00017-gb153daa14 (2023-02-03-14:58) [https://github.com/STMicroelectronics/OpenOCD]

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

clock_config

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

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

Info : Target voltage: 1.792445

Info : clock speed 8000 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x0be12477

Info : [STM32U599NJHxQ.cpu] Cortex-M33 r0p4 processor detected

Info : [STM32U599NJHxQ.cpu] target has 8 breakpoints, 4 watchpoints

Info : gdb port disabled

Info : starting gdb server for STM32U599NJHxQ.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : [STM32U599NJHxQ.cpu] external reset detected

Info : accepting 'gdb' connection on tcp/3333

CPU in Non-Secure state

[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000

STM32U599NJHxQ.cpu TrustZone disabled

STM32U599NJHxQ.cpu work-area address is set to 0x20000000

Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

Info : TZEN = 0 : TrustZone disabled by option bytes

Info : RDP level 0 (0xAA)

Info : flash size = 4096 KiB

Info : flash mode : dual-bank

Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

Info : TZEN = 0 : TrustZone disabled by option bytes

Info : RDP level 0 (0xAA)

Info : flash size = 4096 KiB

Info : flash mode : dual-bank

Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

Info : TZEN = 0 : TrustZone disabled by option bytes

Info : RDP level 0 (0xAA)

Info : OTP size is 512 bytes, base address is 0x0bfa0000

Info : New GDB Connection: 1, Target STM32U599NJHxQ.cpu, state: halted

Info : accepting 'gdb' connection on tcp/3333

Info : New GDB Connection: 2, Target STM32U599NJHxQ.cpu, state: halted

[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000

Info : Padding image section 0 at 0x0800026c with 4 bytes

[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000

 

Is there a way of using this version of OpenOCD in VisualGDB?

Many Thanks

 

Andy

 

• This topic was modified 1 year, 9 months ago by AndyCap.

[bflannery]

The microcontroller and OpenOCD have no idea how to communicate with external memory by default. I am not sure what the CubeIDE is doing in the background to initialize those peripherals (maybe semihosting or an externalLoader specifically for whatever is on the development kit).

Anyways, here is somewhere to start with VisualGDB

https://visualgdb.com/tutorials/arm/stm32/flash/

 

 

 

[AndyCap]

Hi,

Thanks very much for the reply, I was guessing the ST version of OpenOCD has this ability built in via an external loader and you needed the 0.12 version to work with this board, I will check the exact interaction tomorrow…

Is there a way of getting VisualGDB to flash using a command line and then start OpenOCD to attach to the target?

Cheers

Andy

• This reply was modified 1 year, 9 months ago by AndyCap.
• This reply was modified 1 year, 9 months ago by AndyCap.

[support]

Hi All,

@bflannery, thanks for your suggestion, but the tutorial you pointed out is meant for a much more complex case – trying to program external memories (e.g. SPI FLASH) that are not supported out-of-the-box. The regular on-chip FLASH memory and the memories that have drivers from ST should not need it.

@AndyCap, indeed, the OpenOCD version shipped with STM32CubeIDE comes from a different repository. ST typically adds support for new devices there, and in a few months it gets ported (with some changes) to mainline OpenOCD. Either way, please try selecting OpenOCD (ST fork) instead of the regular OpenOCD in VisualGDB Project Properties -> Debug Settings. It is based on the ST fork and should work the same way as STM32CubeIDE. If it still doesn’t work, please let us know, and we will update it based on the latest release tag from ST.

We can also help you configure programming and debugging separately if you wish, but using the ST fork of OpenOCD should be much easier.

[AndyCap]

@support

Thanks for the reply.

I have already tried the 0.10 stfork version, the log is in my first post above.

Basically I have this:

1. Normal OpenOCD – Doesn’t attach to the target at all : “Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device”
2. stfork OpenOCD 0.10 – Does attach, flashes the main flash ok and can debug but it is failing to flash the external flash on the board correctly.
3. St version OpenOCD 0.12 in CubeIDE- Everything works fine.
4. St programmer command line – Everything works fine

The last mainline ST openocd release is 0.11, I’m not sure if that will support this board as it is pretty new.

Any help on using a command line to flash the devices would be great.

Also I can’t seem to find an elf file being produced only a bin, is there an option somewhere to enable writing (or not deleting) the elf?

One more question as well, I am using TouchGFX generating a STMCubeIDE project with is then imported into VisualGDB. When I update the project via TouchGFX and restart Visual Studio it picks up the project changes and update the VS project which is really good but is there a way of doing this without restarting Visual Studio which would be perfect?

Thanks

 

Andy

 

 

 

• This reply was modified 1 year, 9 months ago by AndyCap.

[AndyCap]

I did a little test by starting up ST 0.12 OpenOCD, using the arm-none-eabi-gdb.exe from the VisualGDB folder and an elf produced by stm32CubeIDE, everything works fine (0x90000000 is the external flash).

Is there a way in VisualGDB of telling it to use this 0.12 OpenOCD from disk?

 

C:\Program Files (x86)\Sysprogs\VisualGDB\Keil\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from STM32U5A9J-DK-FreeRTOS.elf...
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Reset_Handler () at ../Application/User/Startup/startup_stm32u599njhxq.s:62
62 ldr sp, =_estack /* set stack pointer */
(gdb) load
Loading section FontFlashSection, size 0x1a8 lma 0x90000000
Loading section TextFlashSection, size 0x10 lma 0x900001a8
Loading section ExtFlashSection, size 0xfac0 lma 0x900001b8
Loading section .isr_vector, size 0x26c lma 0x8000000
Loading section .text, size 0x2a0d0 lma 0x8000270
Loading section .rodata, size 0x2f64 lma 0x802a340
Loading section FontSearchFlashSection, size 0x18 lma 0x802d2a4
Loading section .init_array, size 0x1c lma 0x802d2bc
Loading section .fini_array, size 0x8 lma 0x802d2d8
Loading section .data, size 0x130 lma 0x802d2e0
Start address 0x08001900, load size 249988
Transfer rate: 91 KB/sec, 10869 bytes/write.
(gdb)

 

 

C:\>C:\ST\STM32CubeIDE_1.12.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.2.300.202301161003\tools\bin\openocd.exe "-f" "STM32U5A9J-DK-FreeRTOS.cfg" "-s" "C:/Users/andre/source/repos/STM32/ExampleTGFX/STM32CubeIDE" "-s" "C:/ST/STM32CubeIDE_1.12.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.500.202302091318/resources/openocd/st_scripts" "-s" "C:/ST/STM32CubeIDE_1.12.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 4444" "-c" "tcl_port 7777" "-c" "telnet_port 5555"
Open On-Chip Debugger 0.12.0-00017-gb153daa14 (2023-02-03-14:58) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
clock_config
Info : Listening on port 7777 for tcl connections
Info : Listening on port 5555 for telnet connections
Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 1.793634
Info : clock speed 8000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0be12477
Info : [STM32U599NJHxQ.cpu] Cortex-M33 r0p4 processor detected
Info : [STM32U599NJHxQ.cpu] target has 8 breakpoints, 4 watchpoints
Info : gdb port disabled
Info : starting gdb server for STM32U599NJHxQ.cpu on 4444
Info : Listening on port 4444 for gdb connections
Info : [STM32U599NJHxQ.cpu] external reset detected
Info : accepting 'gdb' connection on tcp/4444
CPU in Non-Secure state
[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000
STM32U599NJHxQ.cpu TrustZone disabled
STM32U599NJHxQ.cpu work-area address is set to 0x20000000
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : flash size = 4096 KiB
Info : flash mode : dual-bank
Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
Info : TZEN = 0 : TrustZone disabled by option bytes
Info : RDP level 0 (0xAA)
Info : OTP size is 512 bytes, base address is 0x0bfa0000
Info : New GDB Connection: 1, Target STM32U599NJHxQ.cpu, state: halted
Warn : Prefer GDB command "target extended-remote :4444" instead of "target remote :4444"
[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000
Info : Padding image section 0 at 0x0800026c with 4 bytes
[STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000

• This reply was modified 1 year, 9 months ago by AndyCap.

[AndyCap]

I also just tried with another board https://www.st.com/en/evaluation-tools/stm32h747i-disco.html#overview

First issue is that the ram setup seems to be wrong for the stm32h747xi, see attached image.

When I try to flash, I get a stack warning (I’m guessing because of the above) using:

MEMORY
{
RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K /* Memory is divided. Actual start is 0x08000000 and actual length is 2048K */
QSPI (rx) : ORIGIN = 0x90000000, LENGTH = 128000K
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
}

 

Then with both the normal and st 0.10 versions it fails to flash and even run (Failed to start GDB Session window)

 

Here is the log from the st version:

 

C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe -c "gdb_port 49515" -c "telnet_port 49513" -f interface/stlink-dap.cfg --set "CHIPNAME STM32H747XIXx" -f target/stm32h7x_dual_core.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2023-01-03) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
STM32H747XIXx
Info : auto-selecting first available session transport "dapdirect_swd". To override use 'transport select '.
stm32h7x_cti_prepare_restart_one
Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.284127
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : clock speed 3300 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [STM32H747XIXx.cm7] Cortex-M7 r1p1 processor detected
Info : [STM32H747XIXx.cm7] target has 8 breakpoints, 4 watchpoints
Error: [STM32H747XIXx.cm4] Cortex-M PARTNO 0x0 is unrecognized
Warn : target STM32H747XIXx.cm4 examination failed
Info : gdb port disabled
Info : starting gdb server for STM32H747XIXx.cm7 on 49515
Info : Listening on port 49515 for gdb connections
Info : starting gdb server for STM32H747XIXx.cm4 on 49516
Info : Listening on port 49516 for gdb connections
Error: [STM32H747XIXx.cm4] Cortex-M PARTNO 0x0 is unrecognized
Info : [STM32H747XIXx.cm4] Cortex-M4 r0p1 processor detected
Info : [STM32H747XIXx.cm4] target has 6 breakpoints, 4 watchpoints
[STM32H747XIXx.cm7] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005860 msp: 0x20020000
[STM32H747XIXx.cm4] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08103dc4 msp: 0x10048000
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 49513 for telnet connections
Info : accepting 'gdb' connection on tcp/49515
Error executing event gdb-attach on target STM32H747XIXx.cm7:
target/stm32h7x.cfg:427: Error: invalid command name "gdb_attach_hook"
at file "target/stm32h7x.cfg", line 427
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
Info : New GDB Connection: 1, Target STM32H747XIXx.cm7, state: halted
Warn : Prefer GDB command "target extended-remote :49515" instead of "target remote :49515"
Error: Failed to read memory at 0x66c32214
Error: Failed to read memory at 0x66c32214
[STM32H747XIXx.cm7] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005860 msp: 0x20020000
[STM32H747XIXx.cm4] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08103dc4 msp: 0x10048000
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
Info : Device: STM32H74x/75x
Warn : STM32H747XIXx.cm4 cannot read the flash size register
Info : assuming 2048k flash
Info : STM32H7 flash has dual banks
Info : Bank (2) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Warn : STM32H747XIXx.cm4 cannot read the flash size register
Info : assuming 2048k flash
Info : STM32H7 flash has dual banks
Info : Bank (3) size is 1024 kb, base address is 0x08100000
Error: Failed to write memory at 0x90001600
Error: Failed to write memory at 0x900055e0
Error: Failed to read memory at 0x15503d22
Error: Failed to read memory at 0x15503d22

 

• This reply was modified 1 year, 9 months ago by AndyCap.

[support]

Hi,

No problem, please see the answers to your questions below:

1. We have just rechecked the latest OpenOCD release from ST, and it looks like our build already has all the latest commits. The version number reported by the binary could be different due to the differences in build scripts, but otherwise it should be identical. However, the OpenOCD script files used to configure it could be different: STM32CubeIDE generates them dynamically based on some internal logic, and might insert some additional statements to handle QSPI. We would advice approaching it as follows:
   1. Make sure you can program and debug everything via command-line gdb + OpenOCD from STM32CubeIDE
   2. Make sure you can reproduce the problem with command-line gdb + OpenOCD from VisualGDB
   3. Try using setup (a) with binary from (b). It should normally still work as the binaries are identical.
   4. Inspect the OpenOCD scripts used by (a) and (b) looking for FLASH-related commands (flash <…>). Try copying them from the script file used in (a) to a copy of the script file used in (b).
   5. Once you get the modified script file working, you can configure VisualGDB to use it via VisualGDB Project Properties -> Debug Settings -> Advanced -> Command Line. You can use variables like $(ProjectDir) to avoid hardcoding paths there.
2. If you would like to program the memory separately, you can add a command line for doing so to VisualGDB Project Properties -> Custom Debug Steps (to do it automatically), or Custom Shortcuts (to do it manually via a context menu command). Then, disable the regular memory programming via the Debug Settings page.
3. VisualGDB always produces the ELF file and never deletes it. It normally has the same name as the .bin file, and no extension.
4. If you have imported a STM32CubeIDE project, and are changing it, VisualGDB would check for changes when you open the VisualGDB project. You can force it to recheck it by closing and reopening a solution, or by reloading the project via context menu in Solution Explorer (not for all project types). Another option would be to use the advanced STM32CubeMX workflow – it internally uses the same importing logic, but nicely separates the STM32CubeMX-generated part from anything you would add later in Solution Explorer, and also has a context menu command to launch STM32CubeMX, and apply any changes it makes.
5. If you absolutely want to use a custom OpenOCD executable, you can select “Custom GDB stub” in VisualGDB Project Properties -> Debug settings and specify the command line manually, however you will lose some advanced features like automatic substitution of USB serial numbers (for multiple ST-Link probes) and live memory reading. Using the regular OpenOCD method with a custom script should work much better.
6. The STM32H747XI linker script you mentioned looks different from the default one. Please double-check where did it come from. If it’s located in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\STM32H7xxxx\LinkerScripts, it was generated by us and could indicate a bug in our BSP generator. If it comes from %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\VendorSamples, it was copied “as is” from the ST SDK, and could indicate a bug in the ST SDK that will likely be fixed in the next SDK version. In the latter case, please consider simply patching the file on your side as a temporary fix until ST fixes it properly and we release an updated BSP with the latest patches.

[AndyCap]

Thanks very much for the detailed steps.

I am stumbling on the “VisualGDB always produces an elf file and doesn’t delete it” bit though, as there is no elf file here 🙂

I have attached a pdf file of the exact steps I have taken.

Cheers

Andy

 

Attachments:

You must be logged in to view attached files.

[AndyCap]

Ok ignore that, it is there but it doesn’t have a .elf extension!

I will do the other tests and update the pdf file…

[AndyCap]

So, being very careful this time and clearing down the external flash between steps it looks like the STM32CubeIDE  version of OpenOCD is also not working correctly with the external flash. I was mistaken before when I thought this was working.

If I use stink-gdb-server instead of openocd then everything works, external flash is written correctly.

I will log an issue with them about this.

I will also try this later with the 747 board as well.

I will try getting stink-gdb-server working with VisualGDB…

Cheers

Andy

 

Andy

 

 

 

Attachments:

You must be logged in to view attached files.

[AndyCap]

Now I have two debug configs:

one using stlink-gdb-server which flashes internal and external

one using the st openocd which flashes just internal.

Works well for me, I will have a look at the 747 board tomorrow to see what is going on with that one…

[support]

Hi,

Good to know it works. Let us know if you encounter further issues.

[AndyCap]

Hi,

Just a follow up for the other STM32H747I-DISCO board incase anyone else has issues.

The ST Openocd just does not work for this board you have to use ST-LINK_gdbserver.exe with a CustomGDB Stub.

ST-LINK_gdbserver.exe will always flash the entire elf including external memory so if you have data in there that is not changing and you don’t want to wait ages for it to flash it every time you debug then it seems the way to do this is to strip the ext flash sections from the elf.

I’m not sure I did this the best way but I create another Debug Config “DebugNoExt” and then use a custom debug step to strip the sections out of the elf. So now to do a full flash I choose “Debug” and to just flash the internal flash I use “DebugNoFlash”.

 

 

 

• This reply was modified 1 year, 9 months ago by AndyCap.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for sharing this. BTW, we have published a tutorial showing how to use the ST-Link GDB server with VisualGDB here. We will watch for feedback on it and will consider creating an out-of-the-box debug package for it, similar to the OpenOCD one.

[Author]

Posts