Flashing STM32H743II with OpenOCD

[smadeux]

I’m trying to flash and debug a program on an STM32H743II (with Dual Flash Bank) and OpenOCD with VisualGDB. No matter what I do, I can’t seem to get it working. Are there any known issues with OpenOCD and the STM32H743II?

Here some of the things I’ve tried, based on what I’ve seen online:

• Increasing the “workareasize”
• Setting the remotetimeout higher (warnings about that earlier)
• Changing the section allignment in the linker file (16/32/64)

Flashing the program to the board using STM32Programmer works just fine. In fact up until this point I’ve been using that and then later debugging with VisualGDB/Visual Studio. I also tried flashing the LEDBlink Example project to the board and it seemed to flash without any problems.

Here is the output from OpenOCD:


Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Info : STLINK V2J38S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.314812
Info : stm32h7x.cpu0: Cortex-M7 r1p1 processor detected
Info : stm32h7x.cpu0: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 61955
Info : Listening on port 61955 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002c18 msp: 0x00010000
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 61953 for telnet connections
Info : accepting 'gdb' connection on tcp/61955
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
Warn : Prefer GDB command "target extended-remote :61955" instead of "target remote :61955"
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002c18 msp: 0x00010000
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
flash_bank_summary:0x8000000|0x100000|stm32h7x.bank1.cpu0
flash_bank_summary:0x8100000|0x100000|stm32h7x.bank2.cpu0
FLASH progress reporting is now on

target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002c18 msp: 0x00010000
Info : Erasing FLASH: 0x08080000-0x08180000...
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002c18 msp: 0x00010000
Info : Erasing FLASH: 0x081a0000-0x081c0000...
Info : Programming FLASH (3 sections, 1020246 bytes)...
Info : Programming FLASH section 1/3 (984942 bytes) at 0x08080000...
Error: timed out while waiting for target halted
target halted due to debug-request, current mode: Thread
xPSR: 0x29000000 pc: 0x08020cf0 msp: 0x2001fef0
Error: error waiting for target flash write algorithm
Error: error writing to flash at address 0x08000000 at offset 0x00080000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002c18 msp: 0x00010000


• This topic was modified 2 years, 10 months ago by smadeux.

[support]

Hi,

This looks like an issue in OpenOCD, rather than VisualGDB itself. You can resolve it in one of the following ways:

1. Try using Segger J-Link with the J-Link software instead of OpenOCD. The Segger software is generally much more reliable than the open-source tools.
2. Alternatively, please try selecting the ST fork of OpenOCD in VisualGDB Project Properties -> Debug Settings instead of the regular OpenOCD branch. The ST fork uses a slightly different code base, that might work better in some cases.
3. If it still doesn’t work, please try installing the STM32CubeIDE and debugging the device with it. If it works, try comparing the OpenOCD script generated by STM32CubeIDE with the one used by VisualGDB (see VisualGDB Project Properties -> Debug Settings for the exact OpenOCD command line). The ST script might include some additional commands that are not present in the regular scripts used by VisualGDB. Adding them manually to the OpenOCD command line (or creating a copy of the STM32CubeIDE script and pointing VisualGDB to it) should replicate the results from STM32CubeIDE.

[smadeux]

Hey, thanks for the response.

I guess one thing that I forgot to mention is that I have already tried it with a Segger J-Link. It’s been a bit since then so I can’t quite remember what the errors were, but I can give it another shot. On that note, one my coworkers had told me that the J-Link doesn’t work with the STM32H743II. I don’t know if that’s correct or not though.

I’ve also already tried using the ST fork of OpenOCD, but with similar results.

As for STM32CubeIDE, the project I’m working on is one that I’m trying to port from the IAR Arm compiler to gcc-arm-none-eabi with VisualGDB. As far as I know, I can’t easily debug with STM32CubeIDE, but I’d love to know if there is a way.

I’ll take a look on the OpenOCD forum as well to see if there’s anything similar out there.

[support]

Thanks for letting us know.  Segger J-Link supports a huge variety of devices very well, and has its own support dedicated to this type of low-level issues. Feel free to check with them whether your specific device is supported, and forward them any J-Link-level messages you get.

If you do not wish to use J-Link, you can try debugging:

1. A “LEDBlink” project for the same chip/board using VisualGDB.
2. A “LEDBlink” project for the same chip/board using STM32CubeIDE.

If the #1 doesn’t work, while #2 works, you should be able to fix VisualGDB-based debugging by copying the additional initialization commands from STM32CubeIDE.

If debugging a “LEDBlink” project works, while debugging your current project doesn’t, it could be an OpenOCD bug triggered by something about the project layout. Comparing the project to the LEDBlink project could help understand it.

You can also try building OpenOCD yourself and stepping through its logic, although it could be a tricky endeavor.

[smadeux]

I didn’t exactly solve the problem of OpenOCD not working, but I did find a workaround and I wanted to share it in case it’s helpful to anyone.

I ended up adding a post-build Python script that is set to flash the microcontroller after it’s done building (VisualGDB Project Properties>Custom build steps).

For STM32 you can easily use the STM32Programmer command line interface. Then under the VisualGDB Debug settings just switch Program FLASH memory to Never.

[support]

Hi,

Sounds like a reasonable workaround, thanks for sharing this!

[Author]

Posts