Update: The issue got resolved by installing the latest version of openocd. All works well if I install do brew install openocd --HEAD instead of brew install openocd, i.e., use 0.11.0+dev-00562-g5ab74bde0 instead of 0.11.0. This resolves the segfault!
I got an ST-LINK v3 mini which I’d like to use instead of flashing via USB in DFU mode for better debugging. Flashing via USB in DFU mode works as it should (both using the web interface as well as make program-dfu).
Unfortunately, however, I get a segfault when I try to flash via the ST-LINK v3 mini both using task build_and_program in VSCode as well as make program on the command line.
The error, e.g., when using the Blink example, is:
openocd -s /usr/local/share/openocd/scripts -f interface/stlink.cfg -f target/stm32h7x.cfg \
-c "program ./build/Blink.elf verify reset exit"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
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
make: *** [program] Segmentation fault: 11
Any help would be much appreciated!
Additional notes:
The programmer is detected as a USB device and mounted
The seed is powered externally
I have triple checked that cable orientations are correct
My OpenOCD version is up-to-date
The USB cable is the same that works for flashing in DFU mode via USB
I had a similar problem on Windows 10 with Visual Studio Code and the STLINK-V3-MINIE (the one with USB-C). I could resolve it by downloading the newest binary release of openocd from github (Releases · xpack-dev-tools/openocd-xpack · GitHub) and copy the contents (bin, drivers, share) into the DaisyToolchain directory, overwriting 2 files in the process. One of them was openocd.exe.
note: I have strated a discussion on the Discord channel here:
One question: I was trying to adjust my ST Link driver with the use for the Zadig tool… so I am wondering if I also now have a bad/wrong driver in the mix now. Any thoughts on what driver I should be using here?
Here is my version number:
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.11.0-00155-ge392e485e (2021-03-15-16:44)
Licensed under GNU GPL v2
For bug reports, read
I tired the above with the xpac version v0.12.0-1, it was the latest when I follwed the link above.
I copied over the just the files in the bin (openocd.exe, and the two libs). When I went to run them the same openocd command I got an error saying it could not find the stlink.cfg file in the interfaces directory.
If I copied back the V0.11 version that comes in the Daisy Toolchain directory that error goes away.
Any thoughts on this?
I thought I was getting closer… but still not quite working for me.
In case somebody comes across this thread in the future, the new version of the Daisy toolchain will include openocd 0.12.0, which will address this issue.
Hi…i have also an issue with my ST LINK V3.
But i do not find a new windows toolchain installer.
It is always the DaisyToolchain-1.0.0-win64.exe
Did i miss something ?
My actual open ocd is:
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.11.0-00155-ge392e485e (2021-03-15-16:44)
The trace of my issue xPack OpenOCD, x86_64 Open On-Chip Debugger 0.11.0-00155-ge392e485e (2021-03-15-16:44) Licensed under GNU GPL v2 For bug reports, read
http://openocd.org/doc/doxygen/bugs.html*
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select ’. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 1800 kHz Error: open failed in procedure ‘program’
*** OpenOCD init failed *** shutdown command invoked
Hi Brett
Thank you very much for your proposition.
Now i can download the firmware with the ST-LINK. (it is already very useful)
But the debug part is always “out of service”…it is an error around the gdb server.
I will send the log ASAP.
I am having trouble getting OpenOCD working with ST-LINK v3
as well
i can get make program working but if i try to run Cortex debug Play button i get this error:
GDB executable “/opt/homebrew/bin/openocd/arm-none-eabi-gdb” was not found.
Please configure “cortex-debug.armToolchainPath” or “cortex-debug.gdbPath” correctly.
for M1 users. there is conflicting information out there about the right way to set up your JSON files on OSX for openOCD.
In my case I had to set it like this :
I think i figured it out
you do not want to have those cortex paths set to anything but ""
so this did the trick
"cortex-debug.openocdPath": "",
"cortex-debug.armToolchainPath.osx": ""