Hi,

I have the same problem few days ago. But finally I was able to connect and debug on two boards, one of them was with STM32F303 (stm32f3discovery board) and NUCLEO-L152RE (on board ST-LINK/V2-1). I have also imported projects from STCube. For me it works on Win 7 and Win 8 64 bits.

What I can suggest you is to activate debug level 3 in System Workbench. This will print on Eclipse console a lot of information and maybe you can figure out what is happen. If you can’t see first messages just increase the buffer of the Eclipse console until will fit. On Debug Configuration window just add ‘-d3’ to ‘OpenOCD Setup’ field. See attached screen shoot.

If you did not already do, check the documentation: http://www.openstm32.org/Importing+a+STCubeMX+generated+project
(OpenSTM32 Community Site » Documentation » System Workbench for STM32 » User Guide » Importing a STCubeMX generated project)
There is a section how to manually set the debug configuration.

Alternatively, you can start OpenOCD from command line.
Example:
c:\openocd-0.9.0_fc\bin>openocd.exe -f c:\openocd-0.9.0_fc\scripts\board\stm32f429discovery.cfg -d 3 -l d:\openocd_stm32f429_log.txt

you will see something like this on console:

‘’Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
User : 13 0 command.c:546 command_print(): debug_level: 3
Debug: 14 15 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_log_output d:openocd_stm32f429_log.txt
Debug: 15 15 command.c:145 script_debug(): command - log_output ocd_log_output d:openocd_stm32f429_log.txt’’

Check the file specified with -l command (-l = log)

But before to do that you have to:
1) Download and install OpenOCD compiled for Win from Freddie Chopin web site (google ‘freddie chopin openocd’). System Workbench has the OpenOCD but you have to issue some commands first to add necessary path else will not work. See more in this post “openocd - wrong paths on win x64” (search in this forum)

2) Check what script System Workbench is using for your board/microcontroller and use the same script in command line. If you board does’t have a ‘board’ script you can specify the mcu script and the interface script (check one board script close to your micro)

For a successful connection you have to see something like this (note that this is without -d3):

‘’c:\openocd-0.9.0_fc\bin>openocd.exe -f c:\openocd-0.9.0_fc\scripts\board\stm32f429discovery.cfg
Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
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
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
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 v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.864877
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints’’

and here the On-Chip Debugger wait for commands from GDB Server. Press CTRL+C to stop to OpenOCD application.

Please note that for STLINK V2.1 PID is 0x374B (not 0x3748)

Thank you, cipriansalageanu.
Your sugestion of setting the d3 option is helpful. I was able to capture a log file of the details, however I still do not understand the cause of the problem. I will attach the log, hoping that someone will recognize the issue.
Regards

I also had this error while testing systemworkbench for production work. It came and went at unpredictable times, what leads me to believe this is some sort of USB/hardware thing going on.
Sometimes it helped flashing firmware to the stlink, at other times it did not.Rebooting sometimes helped, sometimes it did not. Fiddling with SWD/JTAG settings sometimes helped. I also tried modifying the OpenOCD scripts, but i could not pinpoint the exact cause. It might even have been an sub-par (USB) cable or something. In any event, it’s working for the time being.

Thanks for you help. I was able to resolve the problem. It was caused by operator head space! I thought that I had an ST-Link-V2-1, but in fact it is a V2. I hope I did not waste anyone’s time but my own.
Corky

This problem can also be caused by removing the stlink/discovery option jumpers - breaking the connection from stlink to target... One of those face palm moments...

I also had that problem but now its working
changed ST-link-V2-1 to V2
Its working...:-)

I also had this error! None of your proposed solutions helped!
For me it worked to press the reset button on the evaluation board at the moment I started the debugger!

I ran into same problem with STM32F429I-DISCO and Win 8.1 PC.

After downloading the updated driver from ST website (http://www.st.com/web/en/catalog/tools/PF260219) and setting the debug configuration manual to STLink V2-1 and SWD it worked.