After upgrading to 0.4.5 ST-Link no longer works for me

[ulsoek]

I get the following message when trying to debug a STM32H723 with ST-Link.

Please check TERMINAL tab (gdb-server) for output from c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe Launching server: "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe" "-p" "50000" "-cp" "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin" "--swd"

And the OUTPUT tab says: STMicroelectronics ST-LINK GDB server. Version 5.9.1 Copyright (c) 2021, STMicroelectronics. All rights reserved.

Starting server with the following options: Persistent Mode : Disabled Logging Level : 31 Listen Port Number : 50000 Status Refresh Delay : 15s Verbose Mode : Disabled SWD Debug : Enabled

COM frequency = 24000 kHz Target connection mode: Default Reading ROM table for AP 0 @0xe00fefd0 Hardware watchpoint supported by the target ST-LINK Firmware version : V3J8M3 Device ID: 0x483 PC: 0x8000728 ST-LINK device status: HALT_MODE ST-LINK detects target voltage = 3.27 V ST-LINK device status: HALT_MODE ST-LINK device initialization OK Waiting for debugger connection... Waiting for connection on port 50000... Waiting for connection on port 50001...

And after a while there's a timeout dialog popping up.

It worked fine yesterday with version 0.4.4

Any ideas?

[haneefdm]

I don't think anything changed for ST-Link specifically. I am not familiar with the ST-Link debugger but I will see what I can do.

It appears that gdb never made a connection. You can see the command line(s) for both gdb and st-link in the Debug Console. Can you use both in separate terminals and see if that works?

[haneefdm]

In your launch.json, can you do the following?

"showDevDebugOutput": true

and report what you see in the Debug Console?

[ulsoek]

I updated my launch.json and then the Debug Console shows the following:

Reading symbols from 'C:\Users\us\Documents\dev\u12\u12_sw\U12_VFD\Src\main.elf' Finished reading symbols Please check TERMINAL tab (gdb-server) for output from c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe Launching server: "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe" "-p" "50000" "-cp" "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin" "--swd"

To me, that looks about the same.

BTW. A colleague of mine who had the same problem told me that by going back to version 0.4.4 it worked ok again.

[haneefdm]

If there is nothing else in the Debug Console, did gdb even start? We should be seeing a flurry of command/responses between gdb and cortex-debug.

You can also run two programs (gdbserver.exe and gdb) in terminals and see if they work.

It may work with 0.4.4. There were some changes made for 0.4.5 but most are for how the debug session ends. And one change related to JLink. Nothing else I can remember that should affect this.

[ulsoek]

No, there's nothing else in the Debug Console.

The output tab shows the same as before. Shoudn't it say that Verbose Mode : enabled? It now says disabled.

STMicroelectronics ST-LINK GDB server. Version 5.9.1 Copyright (c) 2021, STMicroelectronics. All rights reserved.

Starting server with the following options: Persistent Mode : Disabled Logging Level : 31 Listen Port Number : 50000 Status Refresh Delay : 15s Verbose Mode : Disabled SWD Debug : Enabled

COM frequency = 24000 kHz Target connection mode: Default Reading ROM table for AP 0 @0xe00fefd0 Hardware watchpoint supported by the target ST-LINK Firmware version : V3J8M3 Device ID: 0x483 PC: 0x8000728 ST-LINK device status: HALT_MODE ST-LINK detects target voltage = 3.28 V ST-LINK device status: HALT_MODE ST-LINK device initialization OK Waiting for debugger connection... Waiting for connection on port 50000... Waiting for connection on port 50001...

Here is my launch.json contents. I have two configs, one for stlink and one for jlink (which works fine).

"version": "0.2.0",
"configurations": [
    {
        "type": "cortex-debug",
        "request": "launch",
        "servertype": "stlink",
        "cwd": "${workspaceRoot}",
        "executable": "Src/main.elf",
        "name": "Debug (ST-Link)",
        "device": "STM32H723ZG",
        "interface": "swd",
        "svdFile": "Src/STM32H723.svd",
        "runToMain": true,
        "armToolchainPath": "${workspaceFolder}/Tools/GCC_ARM/9_2020_q2_update/bin",
        "showDevDebugOutput": true,

// "ipAddress": null, // "serialNumber": null, }, { "type": "cortex-debug", "request": "launch", "servertype": "jlink", "cwd": "${workspaceRoot}", "executable": "Src/main.elf", "name": "Debug (J-Link)", "device": "STM32H723ZG", "interface": "swd", "svdFile": "Src/STM32H723.svd", "runToMain": true, "armToolchainPath": "${workspaceFolder}/Tools/GCC_ARM/9_2020_q2_update/bin", "serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe" // "ipAddress": null, // "serialNumber": null, } ] }

[haneefdm]

Btw, Cortex-Debug looks for a string like Listening at from the server, and until it sees that, it won't start the session at all. What I see from your output is

Waiting for debugger connection...
Waiting for connection on port 50000...
Waiting for connection on port 50001...

which does not match

While I did not write this code, it has not changed in 10 months. It was added by @hwmaier who may join the discussion. I know many people are using this so...

I also cannot see how it could have worked in 0.4.4

[ulsoek]

So, I just installed 0.4.4 and after that debugging works fine, as it used to. I also get a lot more output in the Debug Console.

Now I saw there's a 0.4.6 so I installed that one. Then it doesn't work again. Same problem.

[haneefdm]

Both 0.4.5 and 0.4.6 had nothing to do with STLink. Like I said, the code I am looking at cannot have worked with the gdb-server output you included above.

I can give you a test version that is fixed, do you mind trying it? STLink gdb-server does not work for me on my Mac or I could have tested this myself

[ulsoek]

Yes I can try the test version. I think we will stay with the 0.4.4 version for now though since it works fine. Could the toolchain version have anything to do with this? Doesn't seem likely but maybe something has changed on the gdb command line.

[ulsoek]

Here are the outputs in the Debug Console from 0.4.6 and 0.4.4 for comparison. Note that the line about launching GDB is missing from the 0.4.6 output.

0.4.6 not working

Reading symbols from 'C:\Users\us\Documents\dev\u12\u12_sw\U12_VFD\Src\main.elf' Finished reading symbols Please check TERMINAL tab (gdb-server) for output from c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe Launching server: "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe" "-p" "50000" "-cp" "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin" "--swd"

0.4.4 working

Please check OUTPUT tab (Adapter Output) for output from c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe Launching server: "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.0.202105311346\tools\bin\ST-LINK_gdbserver.exe" "-p" "50000" "-cp" "c:\ST\STM32CubeIDE_1.5.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin" "--swd" Launching GDB: "C:\Users\us\Documents\dev\u12\u12_sw\U12_VFD\Tools\GCC_ARM\9_2020_q2_update\bin\arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2" undefinedC:\Users\us\Documents\dev\u12\u12_sw\U12_VFD\Tools\GCC_ARM\9_2020_q2_update\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. Reading symbols from C:\Users\us\Documents\dev\u12\u12_sw\U12_VFD\Src\main.elf... Output radix now set to decimal 16, hex 10, octal 20. Input radix now set to decimal 10, hex a, octal 12. 0x08000728 in Reset_Handler () Program stopped, probably due to a reset and/or halt issued by debugger Unknown reset option Unknown reset option Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main () at Application\main.c:90 90 calc_crc_img();

[haneefdm]

I really doubt that the toolchain has an effect. It rarely does.

I am trying to set up a Windows machine. to test but it is taking a looong time.

I am finally able to duplicate the problem. Please stay tuned.

[haneefdm]

Fixed it. It should have never worked even before. Could you please try this out and confirm

https://github.com/Marus/cortex-debug/releases/tag/V0.4.7-pre1

[ulsoek]

Thank you very much! It works fine.

[hwmaier]

Fixed it. It should have never worked even before. Could you please try this out and confirm

Hi @haneefdm, just started working here in down under and saw this thread, was just about to look into it as well. I am curious what it was, I could not find a difference in the code, have you pushed your changes?

[haneefdm]

Yes, I pushed the changes

https://github.com/Marus/cortex-debug/commit/99149d76a593cb4b0e902c389c7a3acf0511af96

It was kinda working before because, in the server, we waited for the server to start. We had two tests.

• Primary: A matching pattern on stdout/stderr
• Secondary: A TCP port being open by the server

I had removed the 'Secondary' because checking to see if the port was opened, would cause the server to not be able to open that same port, and the port open failures were very random and hard to reproduce until I found the issue.

However, the pattern for stlink was wrong and it would never match. Just in case it was a version issue, I left both the old and the new patterns.

[hwmaier]

When I implemented and tested the ST-Link stuff, I never paid attention to that string and overlooked it as it was working magically due to the secondary socket condition. Glad you found it that quickly.

[christoph-nils]

I got here from #496. When I tested V0.4.7-pre1 it works again. But I have the issue when I try to press restart the debug console shows Unknown reset option and doesn't halt after restart.

[christoph-nils]

After I went back to 0.4.4, I noticed that there was also the message Unknown reset option. But that it stops at breakpoints. With version 0.4.7-pre1 it goes directly over breakpoints after reset and also attach does not work.

edit: I switched a few times between 0.4.4 and 0.4.7-pre1. Now I'm not sure what exactly worked when. But at last it didn't work to restart and halt at breakpoints with version 0.4.4 and gdb version 5.9.1. After reverting also the gdb version to 5.8.0 it works again.

[haneefdm]

But at last it didn't work to restart and halt at breakpoints with version 0.4.4 and gdb version 5.9.1. After reverting also the gdb version to 5.8.0 it works again.

Oh god no. Adding another variable. Yes, 5.9 broke some things but it was difficult to find out what. We already made a couple of adjustments for 5.9.x but the failures were obvious. They removed some commands without notice. Is the 5.9.1 you are using an official ARM released version? If not, I would not trust that.

doesn't halt after restart.

Do you mean at a breakpoint? Could you expand on this? In 0.4.4, we removed the halt on reset as a default because of user requests. It is in the changelog. There is an option breakAfterReset in launch.json for you to force a halt after reset.

So, in this regard, nothing really changed since 0.4.4 but it is possible. @christoph-nils , this thread is about STLink but you are using something else right? JLink? I forget.

[christoph-nils]

Oh god no. Adding another variable.

The beginning of the problem seemed to come out of nowhere. I had not noticed the update of the VSC extension. One of my first steps was to use the latest version of the ST-LINK GDB server. It comes directly from ST. For the project, I switched from OpenOCD to ST-LINK GDB server and ST-Link Server to be able to debug multicore microcontrollers.

Do you mean at a breakpoint?

Yes at breakpoints.

this thread is about STLink but you are using something else right? JLink? I forget.

I am currently using a nucleo board with integrated ST-Link.

[gvcallen]

I too am experiencing this problem. I am using GCC -9.2.1-arm-none-eabi with gdb from gdb-multiarch as Ubuntu 20.04 doesn't come with one.

I am debugging an STM32F411 using openocd servertype and 0.4.4 works fine for me, but switching to 0.4.5 does not. I get the following timeout message: "Failed to launch OpenOCD GDB Server: Timeout".

Release version 0.4.7 also does not work for me. I looked in the debug console but doesn't seem too helpful. Let me know if I can help with anything

[haneefdm]

@gvcallen If the server did not start, then we have not even gotten to launch gdb yet. So, it can't be the gdb version being a problem. Can you attach the gdb-server output from the Terminal Tab and can you start the gdb-server from a terminal (you can see the command-line in Debug Console) and attach the same in case they are different.

[gvcallen]

@haneefdm After inspecting the output it is pretty clear that gdb simply isn't being run in the newer version. The output looks about the same when I run it in my own terminal and also doesn't work. I have attached the command and output for 0.4.7 below, as well as the command only for 0.4.4.

Debug console 0.4.7: Please check TERMINAL tab (gdb-server) for output from openocd Launching server: "openocd" "-c" "gdb_port 50000" "-c" "tcl_port 50001" "-c" "telnet_port 50002" "-s" "/media/gvcallen/Data/Projects/Dev/CMake/STM-Sandbox" "-f" "interface/stlink-v2.cfg" "-f" "target/stm32f4x.cfg"

Terminal 0.4.7: Resuming connection to gdb server... SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected Open On-Chip Debugger 0.10.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 adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : clock speed 1800 kHz Info : STLINK v2 JTAG v37 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.899291 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed GDB server session ended. This terminal will be reused, waiting for next session to start...

Terminal after running 0.4.7 command manually: Open On-Chip Debugger 0.10.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 adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : clock speed 1800 kHz Info : STLINK v2 JTAG v37 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.897872 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Debug console 0.4.4: Please check OUTPUT tab (Adapter Output) for output from openocd Launching server: "openocd" "-c" "gdb_port 50000" "-c" "tcl_port 50001" "-c" "telnet_port 50002" "-s" "/media/gvcallen/Data/Projects/Dev/CMake/STM-Sandbox" "-f" "interface/stlink-v2.cfg" "-f" "target/stm32f4x.cfg" Launching GDB: "arm-none-eabi-gdb" "-q" "--interpreter=mi2" Reading symbols from /media/gvcallen/Data/Projects/Dev/CMake/STM-Sandbox/build/GCC-9.2.1-arm-none-eabi/Debug/STM-Sandbox.elf... 0x00000000 in ?? () Program stopped, probably due to a reset and/or halt issued by debugger ...

[gvcallen]

@haneefdm just tried this on windows with 0.4.7 and the gdb server command was fired not issue. Maybe my issue is Linux-specific?

[haneefdm]

@gvcallen I think I see the problem. We are looking for a regex pattern on stdout/stderr that says

/Info\s:[^\n]*Listening on port \d+ for gdb connection/i

Until we see this, a gdb session won't start.

Something is wrong with the OpenOCD version you have. You have a super old version. It says version 0.10.0 which is from Jan 2017. I suggest getting the latest. And, I know why it (kinda) worked in 0.4.4 but a long story.

If you can't find a pre-built package, I suggest building from scratch. Good luck.

[gvcallen]

@haneefdm glad you seemingly found the issue.

That OpenOCD version is the only one available through apt on Ubuntu. I will consider upgrading but it's working just fine for now ;)

Thanks for the help!

[haneefdm]

What about the version of the OpenOCD that ships with STM32Cube tools? There is an OpenOCD buried in their install I think. Or else,

I would attempt to re-build from sources. First, I would get it from here rather than private repos.

https://github.com/openocd-org/openocd

or, if you are using ST, get their clone

https://github.com/STMicroelectronics/OpenOCD

There are plenty of resources for how to build, but they seldom work. They miss a pre-requisite or two because it was already there on their system. But other than that, it should work. The USB and HID libs are the biggest problems

https://hackaday.io/page/4991-compiling-openocd-from-source-on-ubuntu-1604 https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/building-openocd-linux.html

Consider a few hours of your life lost.

[haneefdm]

Can I close this issue? It is no longer the original issue that was resolved? I am a bit lost. Let reopen a new issue if needed