Debugging with VS Code/ST Link-V3 Mini -- openocd error

Hi all. I am just getting started with Daisy, and am trying to get my dev environment set up. In particular, I’d like to be able to debug in VS Code with the ST Link-V3 Mini, and am running into an error. I’m on Win10, and I’m working with a Daisy attached to a Ruina Versio.

Here’s where I’m at

  • all the CLI tools are set up and on the Git Bash path
  • Git Bash is the default VS Code terminal
  • Cortex Debugging is installed
  • I’ve been able to connect to the Daisy via USB, and have successfully loaded code though both the Electro-Smith web interface and the Noise Eng web interface
  • ST Link-V3 Mini is recognized by the system and has the latest firmware

I have the Versio Decimator project loaded up and it builds. I set a breakpoint and hit F5. After the build, I get VS Code pops up a dialog with “Failed to launch OpenOCD GDB Server: Timeout.”

The debug console shows

Reading symbols from 'C:\Users\daves\Desktop\DaisyExamples\versio\Decimator/build/PatchDecimator.elf'
Finished reading symbols
Please check OUTPUT tab (Adapter Output) for output from openocd.exe
Launching server: "openocd.exe" "-c" "gdb_port 50000" "-s" "C:\Users\daves\Desktop\DaisyExamples\versio\Decimator" "-f" "interface/stlink.cfg" "-f" "target/stm32h7x.cfg" "-c" "init" "-c" "reset init"

The Output tab shows:

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
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
Info : STLINK V3J7M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 0.011268
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)

Any thoughts on what I’m doing wrong or may have missed configuring things?


PS – apologies if I missed an FAQ or something – there’s a lot to absorb

Oh also: it’s unclear to me if it’s sufficient to be connected to the device by USB. Is it safe/necessary to have the Version plugged into modular power as well? I’d try it but I’d like to know if it’s safe first.

Interestingly, I’m having almost exactly the same problem, but with a slight twist. I’m at the same point in my setup process, running on MacOS. When I have the ST-link plugged into USB and the Daisy powered with 9.1V on VIN, I see the same failure dialog, although I do not get the voltage messages in the output tab. When I ALSO plug the Daisy into USB, the debugger seems to start properly, although I’m seeing strange breakpoint behavior (I won’t go into details about this; I’ll post in a separate thread so as not to muddy the waters here, since it’s not obviously related). If I power off the 9.1V so it’s USB alone for the Daisy, I’m again getting the failure dialog. Sure would love to know what’s going on here!

1 Like

Well, you emboldened me to hook up power to the module while the USB was attached to the ST-Link – and it worked! Debugger starts up, getting reasonable breakpoint behavior and able to set watches. So for me, it looks like this issue is solved. I hope you’re able to work it out on your system!

1 Like

I tried this again this morning, using the “tone” example for Daisy seed. I was able to get a problem-free build and launch both with 9.1V on Vin AND without Vin voltage (in both cases with both Seed and ST-Link connected to Macbook via USB). No idea why it’s working this morning when the other day it certainly didn’t :thinking:

I did notice a difference between using cmd-p, “task build_and_program” and using F5. In the former, the “openocd” command was the last step of the build (with output including target voltage, which for me was 3.2V in all cases). When using F5, I did not see the “openocd” command or output.