CubeIDE doesn't start a workspace on Linux Mint 20.3

[XR.1]

Hi,

While trying to open a project inside a workspace the CubeIDE stopped loading:

As you can see from the log, nothing happen after a while, CPU isn't used at all, and my OS gives me the option to exit the application. You can also see a drop in RAM using. The IDE just stucks at that point. Any ideas?

[Semer CHERNI]

Hello @XR.1 

First let me thank you for posting.

• Which Linux distribution you are using in your machine?
• Could you share the .log and .IDE.log file from the .metadata folder found under the workspace folder.

BR,
Semer.

[XR.1]

Hi, after hundreds attempts I was able to start a session and I have kept it open since then; I'm affraid not being able to start it again and lose my precious time.

Of course I'll to close it in the near future, but not now, so in this very moment I can't show you the logs for when the IDE fails. Nontheless I can tell you that I'm using Linux Mint 20.3:

$ inxi
CPU: Dual Core AMD A6-7400K Radeon R5 6 Compute Cores 2C+4G (-MCP-)
speed/min/max: 1475/1400/3500 MHz Kernel: 5.4.0-171-generic x86_64
Up: 6d 17h 20m Mem: 4411.7/6893.2 MiB (64.0%) Storage: 1.13 TiB (12.7% used)
Procs: 237 Shell: bash 5.0.17 inxi: 3.0.38
$

CubeIDE version is: 1.12.1

Newer CubeIDE versions are worst!

ASAP I got in the same problem I'll provide you the logs.

[Pavel A.]

Mint 20.3 is not a supported Linux version. Supported versions can be found in the Installation guide section 1.2.

[XR.1]

Hi! Linux Mint uses the same kernel and packages base as Ubuntu. I'm pretty busy right now, but ASAP I'll install Ubuntu so it's clear that the problem is in your side (as I've pointed out here: https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-doesn-t-start-first-time-after-being-installed/m-p/643820#M24637)

[Pavel A.]

@XR.1 Linux unfortunately is much more than the kernel and some packages. All the Java, GUI stuff, libraries... etc... etc.. can be different in various distros. (This is why Windows has a huge productivity advantage, btw. Freedom is great, but it has its price).

[HenryHil]

I can share my files under metadata folder from Arch Linux installation that has the same problem as XR.1 has.

I'm using stm32cubeide 1.16.0-1 and stm32cubemx 6.12.0-1 versions, both from AUR. (Newer versions exist, but I don't want to risk installing new version in a middle of development)

.ide.log is too large for text version, attached the file below.

And here is .log

!SESSION 2024-10-04 13:11:53.897 -----------------------------------------------
eclipse.buildId=Version 1.16.0
java.version=17.0.11
java.vendor=Eclipse Adoptium
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=fi_FI
Command-line arguments:  -os linux -ws gtk -arch x86_64

!ENTRY com.st.stm32cube.ide.mcu.informationcenter 4 4 2024-10-04 13:13:46.720
!MESSAGE CubeMX plugin appears to be active, Log4j initialization might be too late.

!ENTRY com.st.stm32cube.ide.mcu.informationcenter 1 1 2024-10-04 13:13:46.720
!MESSAGE Log4j2 initialized with config file /home/hchar/STM32CubeIDE/workspace_1.16.0/project-name/.metadata/.log4j2.xml

^real project name changed.

I have noticed that this occurs after .ioc file won't open during normal use of STM32CubeIDE (5 % CubeMX UI fails to show up, or it shows up as a grey box) and if trying to close the .ioc file it will result this unusable workspace in next the session. Also the "!Message CubeMX plugin appears to be active" suggest the IDE thinks the CubeMX is open, even if you are just opening a workspace in a fresh boot.

A "workaround" exist, it just creating a new workspace to a new folder. I keep a copy of project that I know 100% works if new project is created from it. Thus you need to just then move essential source and header files from the broken project to the new one, which should then work again. You just need to setup the MCU in question. If .ioc fails to load, the best you can do is to close the IDE (not the .ioc tab) and check via htop or similar viewer nothing stm32cube related is running and start the IDE again.

[HenryHil]

Just in case someone has this same problem: Another workaround with broken workspace is to rename the .metadata folder (inside the broken workspace) to something else (e.g. metadata_backup). You should then be able to open the workspace, however you then might need to import the same workspace folder to it (odd, I know). This is easier than creating a new workspace and copying files to it, since you are using same workspace before it got broken.