FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

ST-LINK upgrade under Linux fails, do other options exist?

sphil.931
Associate II

‎2019-11-04 01:15 PM

There were several issues so I am not certain which is the real issue.

  1. I am using STM32CubeIDE version 1.1.0
    1. Note I believe ST needs to consider more carefully how to install things and give direction when something seems wrong in installation. I believe one issue is that ST installs under linux assuming the user is part of the group SUDO, this is dangerous, the only thing that should be installed with root access are drivers, which were part of the installation. /opt however ended up belonging to root:root and it should have been root:users so other people than root uses it. Just saying "this needs a bit of thinking" for installation under Linux, I suppose windows installs are more complicated.
    2. upgrading from 1.0.2 did not work and required a full reinstallation
  2. the board I am attempting to use is a NUCLEO-L476RG with version
    1. STM32CubeIDE demands an upgrade for the ST-Linux Firmware
      1. Error in final launch sequence:
      2. Error in initializing ST-LINK device.
      3. Reason: (6) ST-LINK firmware upgrade required.
      4. Please upgrade the ST-LINK firmware using the upgrade tool. Reconnect ST-LINK and click OK
      5. Error in initializing ST-LINK device.
      6. Reason: (6) ST-LINK firmware upgrade required.
      7. Please upgrade the ST-LINK firmware using the upgrade tool. Reconnect ST-LINK and click OK
    2. Execute upgrade tool
      1. version 3.3.1
      2. Open Update mode
      3. version V2J31M21, upgrade version V2J34M25
      4. Reports
        1. Upgrade error, Please try again.
        2. Upgrade successful. (it wasn't)

Those are the details. I would like to use the ST-Link utility as is available under windows, but it's NOT available under Linux. Wine will not work because windows drivers for USB won't work under wine. The last time I had this issue I had to use a windows machine to do the upgrade. I prefer to not to have to do that.

I hope someone has thoughts and suggestions to help rectify this, as I can't do anything if the debugger refuses to work without upgrading ST-LINK on the target device.

Thank you for any help ahead of time!

Labels:
0 Kudos
8 REPLIES 8
Uwe Bonnes
Principal III

‎2019-11-05 03:45 AM

Probably the stsw-link007 is already installed. If not, do so. Locate STLinkUpgrade.jar

> /opt/spare/bon/stm/stsw-link007-201908/AllPlatforms/STLinkUpgrade.jar

Change to that directory

> cd /opt/spare/bon/stm/stsw-link007-201908/AllPlatforms/

Check that you have access rights to the device. Satisfy all requirements for java.

> java -jar STLinkUpgrade.jar

Now you should be able to do the upgrade.

0 Kudos
sphil.931
Associate II

‎2019-11-05 04:33 AM

0690X00000ArhEWQAZ.png0690X00000ArhElQAJ.png0690X00000ArhF5QAJ.png0690X00000ArhEqQAJ.pngI would hazard to guess a few images to give a better description, in addition I ran a few tests.

I've given images to show what I am seeing.

I ran the upgrade JAR as root. With the same results (had to do some work using Xephyr to have any output but that is a digression).

However additional output from the CLI was available:

"libusb: error [udev_hotplug_event] ignoring udev action bind

libusb: error [udev_hotplug_event] ignoring udev action bind"

was output when attempting to upgrade.

0 Kudos
sphil.931
Associate II

‎2019-11-05 08:05 AM

PS Thanks Uwe Bonnes,

I grabbed the stsw-link007 latest and did exactly what you suggested (while you were suggesting it appears).

Their appears to be a number of STLinkUpgrade.jar files floating around in /opt/st/ directory. Each have a different version from 3.3.0 to 3.3.1 I used 3.3.2 when I directly grabbed the update file from ST.

Just in case I used these directions to be sure it wasn't the "same old problem":

http://www.emcu.eu/how-to-update-the-st-link-fw-under-linux/

My install of STCubeMxIDE 1.1.0 seemed to just write over 1.0.2 directory as nothing was added to the structure despite having 1.1 plugins in the directories.

0 Kudos
Uwe Bonnes
Principal III

‎2019-11-06 03:30 AM

Check for flacky cables or some under-powered USB hub or some other problem on your side. Perhaps try on another PC.

The different STLinkUpgrade.jar files come with different stlink firmware versions.

0 Kudos
sphil.931
Associate II
In response to Uwe Bonnes

‎2019-11-07 04:56 PM

Right checked cables switched hubs.

Removed hub and direct connected to computer.

Same results.

Then I turned on wireshark and tested updating with these results:

0.00000   GET DESCRIPTOR Request DEVICE
0.00192   GET DESCRIPTOR Response DEVICE
0.00194   GET DESCRIPTOR Request DEVICE QUALIFIER
0.00592   GET DESCRIPTOR Response
0.00594   GET DESCRIPTOR Request DEVICE QUALIFIER
0.00892   GET DESCRIPTOR Response
0.00893   GET DESCRIPTOR Request DEVICE QUALIFIER
0.01192   GET DESCRIPTOR Response
0.01194   GET DESCRIPTOR Request CONFIGURATION
0.01592   GET DESCRIPTOR Response CONFIGURATION
0.01593   GET DESCRIPTOR Request CONFIGURATION
0.01892   GET DESCRIPTOR Response CONFIGURATION
0.01894   GET DESCRIPTOR Request STRING
0.02192   GET DESCRIPTOR Response STRING
0.02193   GET DESCRIPTOR Request STRING
0.02492   GET DESCRIPTOR Response STRING
0.02493   GET DESCRIPTOR Request STRING
0.02792   GET DESCRIPTOR Response STRING
0.02793   GET DESCRIPTOR Request STRING
0.03092   GET DESCRIPTOR Response STRING
0.03115   SET CONFIGURATION Request
0.08791   SET CONFIGURATION Response
0.08797   GET DESCRIPTOR Request STRING
0.09091   GET DESCRIPTOR Response STRING
0.09109   GET DESCRIPTOR Request STRING
0.09391   GET DESCRIPTOR Response STRING
0.09454   GET DESCRIPTOR Request STRING
0.09691   GET DESCRIPTOR Response STRING
0.09772   SET LINE CODING Request
0.09991   URB_CONTROL out
0.10019   GET DESCRIPTOR Request STRING
0.10290   GET DESCRIPTOR Response STRING
0.89591   GET DESCRIPTOR Request STRING
0.89777   GET DESCRIPTOR Response STRING
0.89803   URB_BULK out
0.90076   URB_BULK out
0.90082   URB_BULK in
0.90176   URB_BULK in
1.11601   GET MAX LUN Request
1.11773   GET MAX LUN Response
1.12204   SCSI: Inquiry LUN: 0x00 
1.12372   URB_BULK out
1.12375   URB_BULK in
1.12472   SCSI: Data In LUN: 0x00 (Inquiry Response Data) [SCSI transfer limited due to allocation_length too small]
1.12474   URB_BULK in
1.12772   SCSI: Response LUN: 0x00 (Inquiry) (Good)
1.12894   SCSI: Test Unit Ready LUN: 0x00 
1.13072   URB_BULK out
1.13187   URB_BULK in
1.13372   SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1.13379   SCSI: Read Capacity(10) LUN: 0x00 
1.13472   URB_BULK out
1.13477   URB_BULK in
1.13772   SCSI: Data In LUN: 0x00 (Read Capacity(10) Response Data) 
1.13774   URB_BULK in
1.14072   SCSI: Response LUN: 0x00 (Read Capacity(10)) (Good)
1.14206   SCSI: Mode Sense(6) LUN: 0x00 
1.14372   URB_BULK out
1.14374   URB_BULK in
1.14472   SCSI: Data In LUN: 0x00 (Mode Sense(6) Response Data) 
1.14473   URB_BULK in
1.14772   SCSI: Response LUN: 0x00 (Mode Sense(6)) (Good)
1.14779   SCSI: Mode Sense(6) LUN: 0x00 
1.14872   URB_BULK out
1.14873   URB_BULK in
1.15172   SCSI: Data In LUN: 0x00 (Mode Sense(6) Response Data) 
1.15173   URB_BULK in
1.15471   SCSI: Response LUN: 0x00 (Mode Sense(6)) (Good)
1.15496   SCSI: Test Unit Ready LUN: 0x00 
1.15572   URB_BULK out
1.15573   URB_BULK in
1.15871   SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1.15877   SCSI: Prevent/Allow Medium Removal LUN: 0x00 PREVENT
1.15972   URB_BULK out
1.15973   URB_BULK in
1.16271   SCSI: Response LUN: 0x00 (Prevent/Allow Medium Removal) (Check Condition)
1.16273   SCSI: Request Sense LUN: 0x00 
1.16371   URB_BULK out
1.16372   URB_BULK in
1.16671   SCSI: Data In LUN: 0x00 (Request Sense Response Data) 
1.16673   URB_BULK in
1.16971   SCSI: Response LUN: 0x00 (Request Sense) (Good)
1.16977   SCSI: Test Unit Ready LUN: 0x00 
1.17071   URB_BULK out
1.17072   URB_BULK in
1.17371   SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1.17375   SCSI: Read Capacity(10) LUN: 0x00 
1.17471   URB_BULK out
1.17472   URB_BULK in
1.17771   SCSI: Data In LUN: 0x00 (Read Capacity(10) Response Data) 
1.17772   URB_BULK in
1.18071   SCSI: Response LUN: 0x00 (Read Capacity(10)) (Good)
1.18076   SCSI: Mode Sense(6) LUN: 0x00 
1.18171   URB_BULK out
1.18172   URB_BULK in
1.18471   SCSI: Data In LUN: 0x00 (Mode Sense(6) Response Data) 
1.18472   URB_BULK in
1.18771   SCSI: Response LUN: 0x00 (Mode Sense(6)) (Good)
1.18775   SCSI: Mode Sense(6) LUN: 0x00 
1.18871   URB_BULK out
1.18872   URB_BULK in
1.19171   SCSI: Data In LUN: 0x00 (Mode Sense(6) Response Data) 
1.19172   URB_BULK in
1.19471   SCSI: Response LUN: 0x00 (Mode Sense(6)) (Good)
1.19505   SCSI: Read(10) LUN: 0x00 (LBA: 0x00000000, Len: 8)
1.19571   URB_BULK out
1.19572   URB_BULK in
1.20271   SCSI: Data In LUN: 0x00 (Read(10) Response Data) 
1.20272   URB_BULK in
1.20571   SCSI: Response LUN: 0x00 (Read(10)) (Good)
1.20582   SCSI: Read(10) LUN: 0x00 (LBA: 0x00000008, Len: 8)
1.20671   URB_BULK out
1.20672   URB_BULK in
1.21370   SCSI: Data In LUN: 0x00 (Read(10) Response Data) 
1.21372   URB_BULK in
1.21670   SCSI: Response LUN: 0x00 (Read(10)) (Good)
1.21677   SCSI: Read(10) LUN: 0x00 (LBA: 0x00000018, Len: 8)
1.21770   URB_BULK out
1.21772   URB_BULK in
1.22470   SCSI: Data In LUN: 0x00 (Read(10) Response Data) 
1.22472   URB_BULK in
1.22770   SCSI: Response LUN: 0x00 (Read(10)) (Good)
1.22806   SCSI: Test Unit Ready LUN: 0x00 
1.22870   URB_BULK out
1.22873   URB_BULK in
1.23170   SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1.23175   SCSI: Test Unit Ready LUN: 0x00

0 Kudos
sphil.931
Associate II
In response to sphil.931

‎2019-11-07 07:11 PM

It looks like it recognizes it as a st-link and then sets it up has a USB mass storage device.

What the Heck?

I suppose next I need to try another computer.

0 Kudos
sphil.931
Associate II

‎2020-09-03 09:25 PM

How I solved this.

The issue was the linux drivers from ST for USB and that specific version of ST-LINK failed to function correctly and or was broken. I am using Debian 10 (buster) 64 bit install, only a few installed applications from source so it was pretty much standard. When I more recently (June) went to use it I had the ST-LINK update utility etc. all updated and installed "the latest" drivers, update was still dysfunctional.

Using a laptop running windows 10 and the windows USB driver that was installed for ST-Link worked without issue. So process of elimination, it's unlikely the JAVA app was different between systems so that only left the Run Time Environment, or the USB driver with that specific version of ST-LINK under linux.

Anyhow it was fixed by bypassing update under linux.

Hope this helps somebody :D

0 Kudos
BZali.1
Associate

‎2021-09-11 06:00 AM

How I partially solved this.

I had the same problem on Linux (Cube IDE 1.7.0 on Ubuntu 20.04) and switching to Windows 10 did not solve it.

What I dit was to go back to CubeIDE 1.1.0 on Linux and to do incremental firmware upgrades from that version (going through: 1.1.0 -> 1.3.0->1.4.0->1.6.1).

The only upgrade that did not work was on 1.7.0.

0 Kudos
Top