Showing results for 
Search instead for 
Did you mean: 

Debugging with OpenOCD and STLink v3 in VSCode

Associate III

I started a new job where everyone is using VSCode so I'm attempting to be a good citizen and use it to. Before this I used STM32CubeIDE. Unfortunately nobody is here to help me today and I'm hoping to work over the holidays.

I can build in VSCode for an STM32F423CHU6 but I can't debug it. I am using an ST-Link v/3. When I try to debug I get the message "OpenOCD: GDB Server Quit Unexpectedly. See gdb-server output in TERMINAL tab for more details." 

When I go to the terminal I see:




Open On-Chip Debugger 0.11.0 (2021-03-07-12:52)
Licensed under GNU GPL v2
For bug reports, read
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 : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 2000 kHz
Error: open failed

[2023-11-22T17:34:49.660Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...




I see the clock speed of 2000 kHz which is different from when I open the ST-Link in STM32CubeProgrammer (Frequency is 8000kHz) but it'd surprise me if that stopped it from working and I can't figure out how to change it (changing swoFrequency in launch.json has no effect).

I appreciate any help anyone might be able to give me. 


Thanks, I'll read through it to see if it helps.

Associate III

Well, I borrowed someone else's ST-Link and it worked. It had FW V3.J10.M3. I downgraded my ST-Link FW to the same revision and it now works. Apparently there's something about V3.J12.M3 that stops it from working with OpenOCD

Note that ST has their own branch (or fork?) of OpenOCD, this is worth to use on STM32 instead of any other version.

Associate III

Good to know. I think the codebase I'm working with is designed to work with Segger JTAG debuggers too so I'm not sure how much I can change at this point.

In some ways it's good to have a ton to work with when you start a new job. In other ways it means there's a ton to learn and you're unsure what you can change without affecting everyone else.