STM32 OpenOCD cannot connect to ST Link V2

Sysprogs forums Forums VisualGDB STM32 OpenOCD cannot connect to ST Link V2

This topic contains 3 replies, has 3 voices, and was last updated by  support 2 weeks, 2 days ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #22949

    canaanav
    Participant

    My VisualGDB project seems to configure and compile correctly.  I’m even able to use the STM32 CubeProgrammer to load and run the generated .bin compiled by VisualGDB.

    I get the following error while trying to debug though.

    Firmware for the STlink has been updated, WinUsb Driver has been updated, I’ve tried switching USB cables and ports, several command line options have been tinkered with; no noticeable effect.

    I used the VisualGDB properties page to download the OpenOCD drivers, and it say that the version 0.10.0.  The OpenOCD website says that 0.10.0 isn’t stable yet, so maybe there’s something with that.  I tried overwriting the openocd.exe and .dll’s with version 0.9.0, but VisualGDB wasn’t happy with that so I had to put it back to 0.10.0.

    Note: I am currently running an Evaluation Version of VisualGDB, maybe that’s the issue?

     

     

    #22954

    support
    Keymaster

    Hi,

    This looks like some sort of driver incompatibility between OpenOCD and ST-Link. Unfortunately, as a free tool, OpenOCD sometimes doesn’t work with some USB controller/device combinations.

    Generally, if you are looking for a hardware solution that works 100% reliably, please consider trying Segger J-Link. It is more expensive than ST-Link, but comes with its own equivalent of OpenOCD that is fully covered by Segger’s support and is compatible with more devices. VisualGDB fully supports it as well as OpenOCD.

    Alternatively, please try the OpenOCD-based setup on a different machine (i.e. with a different USB host controller), or try reinstalling the ST-Link drivers.

    #22955

    parsec67
    Participant

    I’m using ST-Link V2 and it works great with OpenOCD 0.10.0.

    In the first line of your debug log there is a switch “-f C:/Users/mdric_000/AppData/Local/Temp/tmp62F7.tmp”

    I don’t know if this is significant but comparing to my working setup I have “-f target/stm32f4x.cfg”

    So maybe verify in VisualGDB Project properties/Debug settings window that “Debugged device” is set to your MCU type?

    Also in the Debug settings options, try changing JTAG/SWD debugger option to ST-Link V2.1

    HTH

    #22957

    support
    Keymaster

    @parsec67, thanks for your input. We will try to clarify what is going on below.

    Based on the log file, the error happens during the USB connection phase, before the target script takes any effect:

    The .tmp script is used when you modify the JTAG/SWD frequency via settings for device scripts (such as STM32F4) that have it hardcoded. In that case, VisualGDB will create a temporary copy of the script, edit the frequency there and pass it to OpenOCD.

    OpenOCD generally works well with ST-Link v1, v2 and v2.1. We have internal tests checking it and many of our customers are successfully using it. Based on the input we have collected in the past years, in ~0.1% of the cases, it would simply fail to recognize the USB device. This has been previously caused by:

    • 3rd-party USB-over-network software
    • VMWare USB virtualization not releasing the device properly (normally it works with VMWare)
    • A USB host controller by a non-mainstream vendor that was not compatible with libusb
    • Unidentified problem with Windows USB drivers that got resolved by uninstalling the device drivers and reinstalling them from scratch

    Given the the issue occurs very rarely and is located in an external component (libusb) and seems to be triggered by a different set of factors each time, unfortunately it’s hard for us to suggest any specific diagnostic steps other than trying a different computer (assuming that the issue happens from the very beginning with the default settings). We mentioned J-Link because it comes with its own USB driver and software and does not rely on libusb.

    Hope this explains and sorry we couldn’t suggest anything more specific.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.