OpenOCD fail to open STM32 Nucleo board

[Bud]

I have a STM32F302R8 Nucleo board as the hardware, with a built-in programmer with SWD interface, Windows 7 and the software setup is Eclipse Oxygen IDE with OpenSTM32 plugin, the project files created using STM32CubeMX. I created a debug configuration in Eclipse and the project compiles and creates debug binaries and all is hunky-dory until I am trying to run a debug session using OpenOCD. The damn thing cant connect to the board no matter what - I have attached a full log from OpenOCD, the meat is in the last few lines where it fails. The problem is I cant figure out why. Here is the related part from the log:

Code: [Select]

Debug: 258 166 hla_layout.c:42 hl_layout_open(): hl_layout_open
Debug: 259 169 stlink_usb.c:1698 stlink_usb_open(): stlink_usb_open
Debug: 260 169 stlink_usb.c:1716 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x374b serial:
Error: 261 207 stlink_usb.c:1729 stlink_usb_open(): open failed
Debug: 262 207 hla_layout.c:49 hl_layout_open(): failed
Debug: 263 208 command.c:628 run_command(): Command failed with error code -4
User : 264 208 command.c:689 command_run_line(): in procedure 'init'
in procedure 'ocd_bouncer'

Now, I also downloaded the ST-Link programming utility from ST and when I run it, it is working, it finds the board no problem. So the board and the USB link is operational. I checked and made sure the board's USB PID/VID in Windows are the same as in the OpenOCD script files, and they also can be seen in the attached log, all is matching. Still, OpenOCD in Eclipse fails to see the board, while ST-Link can. I went one step farther and installed a standalone version of OpenOCD to no avail, still not working, so the problem is not with Eclipse.

I wonder if there is a secret sauce that you know about, how to get OpenOCD connect to an STM32 board that has a built-in ST-Link v2.1, or if it is known to be flaky and maybe I should not waste my time on it. Again, the vendor utility is working no problem.

[stj]

i have read about this before,
i think you will find it's a windows problem because the usb interface presents itself as multiple devices.

go look at ST's website, i think there are some drivers there.

there is a link in this article
https://dannyelectronics.wordpress.com/2016/05/01/uart-debugging-over-st-link-v2-1/

[Gixy]

Same problem here. I've installed SW4STM32 environment (Eclipse) but even downloading the binary to the target from IDE doesn't work. I've to download with STLINK and then, after some resets openocd eventually starts. Another problem is that I have a TFT shield with a SD card reader, and when I launch debug with the SD card inserted, this one is corrupted and I have to reformat it!
(Windows 10)

[Bud]

I already have ST drivers for both generic chips and boards. If this is a known problem why openocd developers keep quiet. How difficult is it to say "not working/may not work in Windows with STM32  evaluation boards" so people do not waste time with this crap open source product. 

[stj]

so does windows recognise the virtual comport?

the only other thing, is the ST-link firmware up to date?
http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link007.html

[Koen]

If this is a known problem why openocd developers keep quiet. How difficult is it to say "not working/may not work in Windows with STM32  evaluation boards" so people do not waste time with this crap open source product. 

Well, use ST's ST-Link GDB server then.

[Bud]

OK found the culprit. The board was connected to a USB 3.0 port on the computer. Unplugged and connected to a USB 2.0 port and OpenOCD is now working. Wasted two days. The problem is reproducible, switched back and forth a few times, clearly OpenOCD is not working on USB 3.0 on Windows 7. You are welcome.

[gmb42]

Windows 7 doesn't support USB 3.0 out of the box, it relies on drivers from the USB port manufacturer, and these are typically lower quality than those from MS.  Certainly that was my experience with a Renesas USB 3.0 card.

If you'd taken up the free offer from MS for Windows 10 then it's likely that this wouldn't have been an issue for you.

[Bud]

Not sure what you mean.... i've been using this 3.0 port with a bunch of periferials, including this Nucleo board which works with the manufacturer's (ST) software. Over the last what, 5 years or something, OpenOCD is the only thing that did not work.

[Bud]

Well, use ST's ST-Link GDB server then.

Thanks for the hint, i will try that.

[ntfreak]

I already have ST drivers for both generic chips and boards. If this is a known problem why openocd developers keep quiet. How difficult is it to say "not working/may not work in Windows with STM32  evaluation boards" so people do not waste time with this crap open source product. 

I am a OpenOCD dev and as far as I know this is not a known problem. You could always file a bug report?

Regards.

Sent from my XT1562 using Tapatalk

[ntfreak]

If this is a known problem why openocd developers keep quiet. How difficult is it to say "not working/may not work in Windows with STM32  evaluation boards" so people do not waste time with this crap open source product. 

Well, use ST's ST-Link GDB server then.

Did not realise ST had their own gdb server - do you have a URL?

[Bud]

I am a OpenOCD dev and as far as I know this is not a known problem. You could always file a bug report?

Sorry I am too old to learn how submit bug reports. There is a D3 level OpenOCD log attached to my original post, it was made on a USB3.0 port, please see if it is of a value to you.

[ebclr]

Try udated the stlink firmware


http://www.st.com/content/ccc/resource/technical/document/data_brief/fd/97/c6/b3/6c/16/44/1b/DM00218296.pdf/files/DM00218296.pdf/jcr:content/translations/en.DM00218296.pdf

[ntfreak]

Sorry I am too old to learn how submit bug reports. There is a D3 level OpenOCD log attached to my original post, it was made on a USB3.0 port, please see if it is of a value to you.

OpenOCD uses the USB lib "libusb" to communicate with the ST-LINK. The version of libusb used depends on who built OpenOCD that you are using - in your case this is ac6 who develop "System Workbench for STM32".

All I can suggest is to check you are running the latest version of "System Workbench", if you are then I would tell them they need to build with the latest version of libusb as this usually fixes most USB3 issues.
If they are already building with the latest then ac6 should probably report the issue to the libusb devs - in an ideal world anyway.

Regards

[that_guy]

OpenOCD uses the USB lib "libusb" to communicate with the ST-LINK. The version of libusb used depends on who built OpenOCD that you are using - in your case this is ac6 who develop "System Workbench for STM32".

This is usually it. "Official" windows applications will use Microsoft WinUSB but open source programs always use the free libusb. Confusing? Yes. There's a very useful utility called "zadig" (google it) that will allow you to switch between drivers for a specific peripheral on the fly if you run into this problem.

[ntfreak]

This is usually it. "Official" windows applications will use Microsoft WinUSB but open source programs always use the free libusb. Confusing? Yes. There's a very useful utility called "zadig" (google it) that will allow you to switch between drivers for a specific peripheral on the fly if you run into this problem.

OpenOCD uses libusb as a cross platform USB lib - the driver will still be winusb on windows (ST-LINK v2 and above). zadiag should not really be required when using the ST-LINK.

Regards

[Bud]

I did try Zadig and it bricked the Nucleo. It stopped working with the vendor ST Link utility, and still did not work with OpenOCD. I had to reinstall both the vendor drivers and ST Link utility to return to the status quo.
As i said, i eventually figured out it was USB 3.0 causing thd problem with Open OCD.