STLINK-V3MINIE Not Detected

[bflannery]

I just purchased a handful of the newer STLINKV3-MINIE. Which is a compact USB-C replacement for the STLINK-V3MINI.

VisualGDB doesn’t seem to detect this version of the debugger as a USB device.

Anyone run into this?

[support]

Hi,

Most likely, the device uses a different USB VID/PID, that is not recognized by VisualGDB. From a quick look at the original .cfg file, it looks like ST recently added the 0483/3754 ID, so that’s likely corresponds to the new device.

Please try replacing the edp.xml and the files in the QuickSetup directory under %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd with the ones from the attached archive, then restart Visual Studio.

Please let us know if it solves the problem, and we will release an updated OpenOCD package with the correct definition files.

 

Attachments:

You must be logged in to view attached files.

[bflannery]

That did the trick. Now all my debuggers show up as USB Devices under the Debug Settings.

Thanks!

[support]

Hi,

No problem. We have updated the OpenOCD package on our side to include the new definition file.

[mcipjvw]

Hi, seems that I have a similar problem. Now with the new stlink-v3pwr adapter. Latest version of visualgdb (VisualGDB-5.6r9) did not solve the problem. Manual adding the VID/PID to the edp.xml and QuickSetup files gives the ST-link v3 adapter in the list but gives an error “stlink_usb.c:3431 stlink_usb_usb_open(): read version failed”. The stlink seems correctly installed as “stlink-bridge” and “stlink debug” devices.

Any idea? I am looking forward!

Martin

 

• This reply was modified 11 months ago by mcipjvw.
• This reply was modified 11 months ago by mcipjvw.

[support]

Hi,

Updating VisualGDB version should not affect this because the low-level ST-Link interaction is handled directly by OpenOCD (open-source tool with ST-Link support contributed by ST). If your ST-Link revision is new, it may not be supported by mainline OpenOCD yet.

You can troubleshoot it as shown below:

1. Make sure this ST-Link works with STM32CubeIDE (Eclipse-based IDE from Eclipse that also uses OpenOCD).
2. In VisualGDB Project Properties -> Debug Settings select “OpenOCD (ST Fork)”. This will use a version of OpenOCD equivalent to the one in STM32CubeIDE.

If the ST fork still doesn’t work with VisualGDB, the STM32CubeMX might be passing different arguments to OpenOCD in this case. Please feel free to share the OpenOCD command lines by STM32CubeIDE and VisualGDB, and we will help you understand/mitigate the differences.

 

[mcipjvw]

Hi,

Good suggestion. I installed the STM32CubeIDE and programming worked using the stlink-v3pwr adapter.
So, stlink drivers and OpenOCD using the ST fork seem fine. Programming with VisualGDB though still not, despite the selection of the ST fork cfg.
Looking at the arguments, some differences can be remarked.

CubeIDE:

openocd.exe “-f” “TestIDE.cfg” “-s” “C:/Users/xxxxx/STM32CubeIDE/workspace_1.12.1/TestIDE” “-s” “C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.600.202303311036/resources/openocd/st_scripts” “-s” “C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts” “-c” “gdb_report_data_abort enable” “-c” “gdb_port 3333” “-c” “tcl_port 6666” “-c” “telnet_port 4444”

VisualGDB:

-f interface/stlink-dap.cfg –set “CHIPNAME $$SYS:MCU_ID$$Xx” -f target/stm32l0x.cfg -c init -c “reset init”

Some configuration needs to be done I suppose 😉

Thanks for the quick response. Looking forward for your ideas.

Martin

 

• This reply was modified 10 months, 4 weeks ago by mcipjvw.

[support]

Hi,

No problem. Please try manually running the OpenOCD executable used by VisualGDB with the TestIDE.cfg file from STM32CubeIDE. If it works, you can edit the OpenOCD command line in VisualGDB Project Properties to use the same file.

If not, does it work the other way (OpenOCD executable from STM32CubeIDE copied in place of the one supplied by VisualGDB)?

[mcipjvw]

Hi,

A little bit further! I first copied the openocd binaries from the STM32CubeIDE to the visualgdb location. Just an error on the “–set “CHIPNAME $$SYS:MCU_ID$$Xx”” command: “unknown option — set”.
By removing this option parameter, the adapter is successfully detected. However, with warnings -> DEPRECATED! use ‘read_memory’ not ‘mem2array’. Further, erasing/programming is failing. I think due to the configured and reappearing ‘– set’ parameter. Can’t figure out where it comes from.

I will try to use the TestIDE.cfg file now.

BR Martin

[mcipjvw]

Hi,

Experiment of copying the TestIDE.cfg file to the VisualGDB environment showed that cfg files are not exchangeble.
See error:

target/stm32l0x.cfg:53: Error: Command: STM32L071KZTx.dap Exists in procedure ‘script’
at file “embedded:startup.tcl”, line 28
at file “target/stm32l0x.cfg”, line 53

Ok… Exchanging binaries or cfg files gives some more insight on the underlying problem perhaps, but it is not working.
I got stuck…

I hope that you have some options left. Switching to the STM32CubeIDE is not actually an option…..

BR Martin

 

 

 

 

[support]

Hi,

You can try copying it like this:

1. Use the OpenOCD (ST Fork) in VisualGDB. DO NOT use the regular OpenOCD.
2. Rename the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\share\openocd\scripts directory to scripts.old and re-create it.
3. Copy the contents of the script directories mentioned in the ST command line to the new scripts directory:
   1. C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.600.202303311036/resources/openocd/st_scripts
   2. C:/Users/xxxxx/STM32CubeIDE/workspace_1.12.1/TestIDE
   3. C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts
   4. The share\openocd\scripts from the OpenOCD installation used by STM32CubeIDE (you can search for memory.tcl around STM32CubeIDE to find it)
4. This will re-create the directory structure VisualGDB expects, but will use the scripts from ST. So you can now try running the simplified version of the ST command line (as long as you copied the scripts and are using the VisualGDB’s OpenOCD.exe, you don’t need the ‘-s’ parts):

   openocd.exe -f <full path to TestIDE.cfg>

5. If this doesn’t work, try replacing the VisualGDB’s OpenOCD.exe with the one from STM32CubeIDE. You may need to add the “-s <scripts directory you re-created>” to the command line if it refuses to find the scripts automatically.

[mcipjvw]

Hi,

Thanks man! Sorry for the late response. Finally I found some time to do some digging.
In short, it still is a struggle with visualgdb. I followed your last recipy, but with no success.
My opinion is that above solutions may all be a workaround, but it should work out of the box. But from who can I expect some? Sysprogs tells it is the lowlevel openocd, but st will say it is working with openocd (st fork) inside our IDE.
Both are right, but where lies the solution?

BR Martin

 

 

[mcipjvw]

Hi,

It is working now. I repeated step 5 once again, but now I replaced all accompanied binaries of openocd.
Remains my last remark, that it should work out of the box. But I can go on! Waiting for new releases of openocd/visualgdb now.

Thx!

 

[support]

OK, we have updated both the regular OpenOCD and the ST fork. It should now be equivalent to the version used by STM32CubeIDE.

You can update conveniently via Tools->VisualGDB->Manage VisualGDB Packages.

[mcipjvw]

Thanks for the message and the OpenOCD 0.12.0 update. Works like a charm now with the stlink-v3pwr adapter.

BR Martin

 

[Author]

Posts