- I can't access the ST-Link dongle from System Workbench for STM32
- How to uninstall a third-party driver using the ST-Link dongle
- Why does the IDE freeze when accessing to the build settings (Properties > C/C++ Build > Setting) on Linux ?
- I installed System Workbench for STM32 on Fedora 64bit version, but I can't compile any project
- System Workbench behaves strangely on Linux and even crashes on some operations; what could I do?
If you have libusb-win32 (libusb-0.1) installed on your PC, you may have installed a Windows driver for the ST-Link debug interface.
In this case the ST-Link utilities and OpenOCD in System Workbench will not be able to access the device, as they use libusb-1.0, that can only work on unclaimed USB devices (devices for which there is no Windows driver attached).
In this case you must uninstall this Windows driver by following the instructions in the entry How to uninstall a third-party driver using the ST-Link dongle below.
In some cases it is not possible to access an ST-Link dongle from System Workbench for STM32, due to an error when starting openocd, like for example:
- Error: 176 1031 libusb1_common.c:67 jtag_libusb_open(): libusb_open() failed with LIBUSB_ERROR_ACCESS
- Error: 177 1031 stlink_usb.c:1601 stlink_usb_open(): open failed
This is usually due to some third-party driver (for example installed by libusb-win32) being installed on the device.
To uninstall it you must:
- Ensures the ST-Link debug interface is plugged on your PC
- Start the Device Manager (right click on your computer then select "Manage" then "Device Manager")
- Search for the "STMicroelectronics ST-Link dongle" device (it should be in the libusb-xxx category)
- Uninstall the device, checking the "Suppress the driver for this device" box
- Unplug the ST-Link debug interface
- Download and install the ST-Link driver if needed
- Plug the St-Link debug interface
Now, in the Device manager, the "STMicroelectronics ST-Link dongle" should again appear, but in category "Universal Serial Bus devices" or "USB controller"
This is a known Eclipse bug with the GTK graphical library on various recent Linux distributions (Ubuntu, Mint...). It can also cause other problems in Eclipse causing incorrect behavior or even IDE crashes.
Recent Linux versions install GTK3 as the default library for all programs, thus Eclipse is running with GTK3, while it was coded for GTK2. To force Eclipse to use the older GTK2 version, you need to set the environment variable SWT_GTK3=0 before running Eclipse.
This can be done either in the environment (adding export SWT_GTK3=0 to your $HOME/.profile file) or by calling Eclipse as SWT_GTK3=0 /path/to/eclipse; you can also create a small script to start Eclipse.
Another way to use GTK version 2 instead of 3 is to modify the eclipse.ini file in the System Workbench for STM32 installation, adding__
Most compiler tools are 32 bit programs; you should check you have the 32 bit C library installed.
On recent Fedora distribution, this is in the libc.i686 package, so you should install it, for example by
dnf install glibc.i686
or using your favorite package installation system.
On recent Linux versions, Eclipse may not work correctly as GTK3 was installed as default, while Eclipse needs GTK2; see this FAQ, just above, for more details and a possible solution: Why does the IDE freeze when accessing to the build settings (Properties > C/C++ Build > Setting) on Linux ?
Newest Forum Posts
- Importing a CubeMX project with Debug and Release Targets, 09:17
- Importing a CubeMX project with Debug and Release Targets, 2017-01-18 21:43
- Importing a CubeMX project with Debug and Release Targets, 2017-01-18 20:33
- OpenOCD stopped working, 2017-01-18 20:11
- OpenOCD stopped working, 2017-01-18 18:35
- OpenOCD stopped working, 2017-01-18 16:49
- OSX System Workbench for STM32 installer is corrupt, 2017-01-18 13:15
- Ymail Helpline Contact Phone Number 1-888-411-1123, 2017-01-18 12:38
- sprintf / _sbrk make error, 2017-01-18 10:47
- OpenOCD stopped working, 2017-01-18 10:01