- This topic has 15 replies, 4 voices, and was last updated 4 years, 10 months ago by
.
-
Posts
-
Hello,
is it possible to include the STM32G0 patches for OpenOCD in the VisualGDB build?
http://openocd.zylin.com/#/c/4807/
Or is there any working debug interface for stm32g0 available?
Thanks, Artem
We usually include the patches once they are become a part of the mainline OpenOCD source tree.
If you would like to have them included earlier, please consider applying them on your side to our OpenOCD fork, confirm that it works on the hardware and send us a merge request.
If you have purchased a license and have an active support coverage, we can also do it for you. As long as the patches are readily available and do not require non-trivial merging, this is covered by our support.
Hello,
yes, I have an active license. Please try if you can include them, as the STM32G0 are not usable with VisualGDB right now.
Thanks for updating your forum email to match the license email.
We have reviewed the patches, however we do have some considerations about them. It looks like instead of creating a new driver from scratch, or adding minimal changes to the existing driver, the patch author introduced many changes across the existing STM32L4 driver, extending it to cover the STM32G0 family as well.
Unfortunately, this means that if any of those changes introduce bugs, it would make OpenOCD unusable for some of the existing STM32L4 users, and since many of our users rely on the existing STM32L4 support, we won’t be able to merge those patches to our OpenOCD fork unless their reliability is confirmed (typically, once the patches are included in the mainline OpenOCD repository, we consider them verified by the OpenOCD maintainers).
That said, there are several workarounds:
- First of all, please consider checking out and building our OpenOCD fork (see the detailed tutorial). We have specifically made it easy to build (by converting it to CMake) and provide a ready-to-use toolchain that can help you compile it by simply opening the project file in VisualGDB and building the solution. Then you can try merging the patches into it and replace the OpenOCD.exe file under %LOCALAPPDATA% with the version you build. We can help you get our OpenOCD fork to build and run, however we cannot guarantee that the patches can be merged easily, or that they will work at all.
- If anyone restructures the patches to be completely separate from the STM32L4 family (it can be done by just copying the existing driver and renaming the references), we can merge it into our tree. As long as it doesn’t interfere with the device families that are already supported, we are happy to include it as long it works with at least some of the devices in the new family.
- As another alternative, please consider using Segger J-Link. It is more expensive than ST-Link and FT2232-based probes exactly because they maintain a proprietary replacement to OpenOCD that is frequently updated and tested with the newest devices, so you don’t need to worry about that.
Ok, thank for the info and the guide. I will try the first workaround and build a local OpenOCD.
The Segger J-Link also does not support the STM32G0 family yet.
Update: I just saw that Segger has listed the G0 as supported on their website. I will need to try if this works.
Thanks for sharing this. Segger usually does a pretty good job at being up-to-date with the latest devices and protocols and it’s good to know they now support STM32G0 as well.
ST will likely contribute some level of STM32G0 support to OpenOCD in the next few months, but Segger usually starts supporting new devices faster.
FYI a better patch for the STM32G0x is http://openocd.zylin.com/gitweb?p=openocd.git;a=commit;h=dcec354bfc756c4a4e1034c9461b5d3f4e55a63e
This leaves the STm32L4 code alone and creates a new, independent STM32G0x set of files.
I’ve been able to successfully build an openOCD binary which allows standard prog / debug on the STM32G070 using this patch and the guide mentioned above https://visualgdb.com/tutorials/arm/openocd/build/
Thanks for sharing the patches. We have integrated them into our OpenOCD fork (20190828-0.10.0 available via VisualGDB Package Manager).
I use OPEN OCD 20191216-0.10.0 and can not debug my stm32g031K8 with a ST-Link/V2.
No chance to connect to the target.
What can I do?
Following test output:
<span>C:\Users\danny\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c “gdb_port 51116” -c “telnet_port 51115” -f interface/stlink-v2.cfg -f C:/Users/Daniel/AppData/Local/Temp/tmp19CC.tmp -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.10.0 (2019-12-16) [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.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 50 kHz
Info : STLINK v2 JTAG v34 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.218361
Info : Stlink adapter speed set to 50 kHz
Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 51116 for gdb connections
Info : Stlink adapter speed set to 50 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08002d78 msp: 0x20002000
Info : Stlink adapter speed set to 50 kHz
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 51115 for telnet connections
Info : accepting ‘gdb’ connection on tcp/51116
Info : device id = 0x10016466
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
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’.
Error: attempted ‘gdb’ connection rejected
</span>Hi,
It looks like your device is not yet supported by OpenOCD. Please consider waiting 1-2 months until OpenOCD supports it, using Segger J-Link instead (that adds device support faster), or patching OpenOCD on your side (our OpenOCD fork can be conveniently built using VisualGDB and CMake as shown here: https://visualgdb.com/tutorials/arm/openocd/build/).
Sorry, the exact timelines of OpenOCD supporting various devices are outside of our control. Either way, if you prefer out-of-the-box integration with the latest devices, using Segger J-Link should be the best option.
With new OpenOCD 20200114-0-10.0 i got following Output.
What could I do to fix it?
<span>C:\Users\Daniel\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c “gdb_port 58890” -c “telnet_port 58889” -f interface/stlink-v2.cfg -f C:/Users/Danny/AppData/Local/Temp/tmpD0B4.tmp -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.10.0 (2020-01-14) [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.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 50 kHz
Info : STLINK v2 JTAG v34 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.013368
Info : Stlink adapter speed set to 50 kHz
Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 58890 for gdb connections
Info : Stlink adapter speed set to 50 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08004220 msp: 0x20002000
Info : Stlink adapter speed set to 50 kHz
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 58889 for telnet connections
Info : accepting ‘gdb’ connection on tcp/58890
Info : device id = 0x10016466
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
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’.
Error: attempted ‘gdb’ connection rejected
</span>
- You must be logged in to reply to this topic.