Mission impossible: trying to install the firmware package for L152 on CubeMX

[infoinfo971]

I'm having issues while trying to generate a project for the L152. When I attempt to install the firmware package for this micro, CubeMX prompts me to log in. However, the login window displays some oscillating bars and then asks me to check the internet connection. Interestingly, when I click to check for updates, CubeMX successfully verifies the installed package versions using the network.

I tried to manually download and install the STM32Cube MCU Package for STM32L1 series, but when I try to install the latest patch, 1-10-4, it indicates that it cannot find the file stm32cube_fw_l1_v1100.zip. The downloaded package is named stm32cube_fw_l1_v1-10-0.zip, so I attempted to rename it, but the same error persists.

In summary, creating a project for the L152 using CubeMX seems impossible.

[Bob S]

I've had manually-downloaded patches also fail to install via the CubeMX GUI.  You can manually install the patch.  Find the dir that the 1.10 package is installed.  Then un-zip the patch file into that directory.  It does not matter that the directory name still has the 1.10.0 version in it.

[unsigned_char_array]

This is a known bug, ST is saying they are working on it. Now there are at least 8 threads about this problem:

https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-login-issue/td-p/658990
https://community.st.com/t5/stm32-mcus-boards-and-hardware/connection-lost-issue-during-firmware-packages-downloading-in/td-p/674601
https://community.st.com/t5/stm32cubeide-mcus/i-can-t-log-in-myst/td-p/673955
https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-13-2-myst-login-doesn-t-work-with-intermediate/td-p/600164
https://community.st.com/t5/stm32cubemx-mcus/stm32cubemx-version-6-11-1-users-in-my-office-can-t-login-via/td-p/674518
https://community.st.com/t5/stm32cubemx-mcus/help-with-mx/td-p/675509
https://community.st.com/t5/stm32cubemx-mcus/mission-impossible-trying-to-install-the-firmware-package-for/td-p/675385
https://community.st.com/t5/stm32cubeide-mcus/ide-login-issue/td-p/675379

[SofLit · Accepted solution]

Dear all,

Seems the issue has been solved please check from your side.

[rdl_42]

Bob,

I tried your approach for an update from STM32Cube_FW_L4_V1.18.0 to V1.18.1.  The patch zip file appears to have overlaid on the original fine.  I did not change the name of the directory from the original _V1.18.0.  When I open the Embedded Software Packages Manager from STM32CubeMX V6.12.0, it shows "STM32CubeMCUPackage for STM32L4 Series" v1.18.0 installed (same as before), but v1.18.1 is still shown as available but not installed.

Any ideas?

Thanks,

-Rob 

[Bob S]

I haven't tried with the newer CubeMX versions. If you open the "package.xml" file in the root directlry, does the "PackDescription" element contain a Patch string (for example, Patch="FW.L4.1.18.1") in addition to the a Release string?

If it does, maybe rename the directory just in case the newer CubeMX versions DO pay attention.  It is a long shot.

[rdl_42]

I stumbled on the ability to update to STM32Cube_FW_L4_V1.18.1 through the Embedded Software Packages Manager from CubeIDE v1.16.0.  I've always needed to update from a local downloaded file, but this worked with the default click Install and let the tool download and install automatically.

-Rob

[BarryWhit]

You will notice that the zip files of patches (e.g. 1.8.5) are much smaller than the the zip files of point release (e.g. 1.8.0). That's because patch releases are not self-contained. Unlike point release (I'm discussion manual installation of course), you're not supposed to install them via the package manager, but to directly extract their contents into the same directory as a previously installed point release, overwriting files as needed.

One of the files that is overwritten is the xml file which contains package metadata so that, after restarting CubeIDE, the Embedded SW Manager should show the patch release being installed rather than the point release.

You may find it odd that version 1.8.5 (for example) ends up installed in a directory named foo-1.8.0 but, remember, most users use net installation only and never actually interact with the package repository directory on the filesystem level.