STM32F0, ST-link v2, OpenOCD 0.9.0: open failed

Question

I'm using Launchpad's gcc-arm-none-eabi 4.9-2015q2 to compile for an STM32F0, and now I'd like to debug using arm-none-eabi-gdb from that collection. My ST-Link v2 is part of a Nucleo F411RE board, with external hardware (the STM32F0 target) attached. Flashing the F0 works fine, so I conclude that my SWD connections are good.

Now I want to start OpenOCD, but it fails:

$ openocd -f interface/stlink-v2.cfg -f target/stm32f0x.cfg
Open On-Chip Debugger 0.9.0 (2015-07-26-16:02)
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: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'

What might be wrong here?

I also couldn't establish a connection using st-util, which reported timeouts and in the end always crashed with a segmentation fault.

Answer 1

The file stlink-v2.cfg might be ok. You probably should use stlink-v2-1.cfg file (inside that file is hla_vid_pid 0x0483 0x3748).

Answer 2

In my case I also got Error: open failed but all the configuration was OK. Then I did dmesg | grep usb to see why it cannot connect via USB (on Ubuntu). The dmesg told me that there are power issues and perhaps the cable is faulty. As I had used the same cable earlier the same day and some LEDs still flashed on the board, I first ignored the message. But then I finally decided to try, bought another cable and lo and behold! It was a faulty cable - with the new one everything works. So, not always a software problem after all.

Though if you do lsusb (or use device manager in Windows) and the board is nicely listed, it will probably not be a cable issue. If it is missing, it might be.

Answer 3

I found a fix. The VID/PID pair in stlink-v2.cfg was wrong. They had this:

hla_vid_pid 0x0483 0x3748

but it should be this:

hla_vid_pid 0x0483 0x374B

letter "B", not the digit "8".

Answer 4

Nucleo F411RE embedded a stlink v2-1 not stlink v2

so change the script file like this:

source [find interface/stlink-v2-1.cfg]

transport select hla_swd

source [find target/stm32f4x.cfg]

reset_config srst_only