STM32CubeMX perspective is broken under STM32CubeIDE on Ubuntu 18.04

[GMinc.1]

I can't get the STM32CubeMX perspective to work reliably when running STM32CubeIDE on an Ubuntu 18.04 virtual machine. I always get the pinout view of the device, but the left pane of device features doesn't draw, neither does the row of tabs at the top (should say Pinout & Config, Clock config, Project Manager, Tools). Lots of other stuff works, such as the board selector and compiler, so I doubt it's related to running on a VM.

I've tried many variations:

·        Ubuntu 20.04 (although that's not listed in the versions tested by ST, whereas 18.04 is claimed to work)

·        Different JVMs including the latest OpenJDK 8, OpenJDK 11, Oracle JDK 8, editing stm32cubeide.ini as appropriate and confirming that they're in use through the Installation Details dialog

·        Windows and Mac OS hosts

·        Different RAM sizes.

·        Upgrading GTK

The problem can always be reproduced by creating a freshly installed Ubuntu 18.04 virtual machine.

·        Create a new Virtualbox VM from Ubuntu 18.04 .iso, 64-bit, 4GB RAM, 20GB hard drive.

·        Allow Ubuntu to install on the guest, minimal installation, typical defaults.

·        Allow the guest to install any available updates.

·        Install guest additions

·        Install STM32CubeIDE 1.3.0 Debian bundle from ST.

·        cd /opt/st/stm32cubeide_1.3.0

·        sudo ./stm32cubeide

·        Accept default workspace path

·        The Information centre shows, but wait for it to discover pending updates. It finds an update to version 1.3.1, allow it to install.

·        Manually restart STM32CubeIDE so you can run as sudo. It displays version 1.3.1.

·        File / New STM32 Project. The STM32 target selector downloads a heap of stuff and displays correctly. Use the board selector to create a new project for a Nucleo F072 board, project name = test1, default options.

·        The firmware package downloads and the project is created, but the STM32CubeMx perspective is broken and unusable. The java process consumes 100% CPU time and continues to do so until I quit STM32CubeIDE. I suspect it’s entering some infinite loop.

On the same VM I can install the standalone STM32CubeMX and it works every time (with openjdk-8).

In STM32CubeIDE the board selector, editor and compiler all work perfectly so I doubt it’s anything to do with any of the VM settings or a broken Ubuntu installation. In any case I’ve tried reinstalling Ubuntu a few times and it’s always the same result.

[Cartu38 OpenDev]

Works like a charm on my side.

Have you got a try allocating more memory to your VM? 4Go sounds quite few considering such modern IDE ...

Same I would recommend >1 cpu if VM setup ... you'll take benefit of some distributed jobs (compilation, ...) helping overall IDE performances ...

[GMinc.1]

Cool. Glad it works for you. Are you using 18.04 under VirtualBox? Have you installed any software other than STM32CubeIDE that may be helping it? Are you using the JVM that ships with CubeIDE or another one? Do you run it as sudo or as a standard user?

I just tried it with 8G of RAM and 2 processors. Same result, see attached screenshot. RAM usage is 1.7G, which is the same as when I'd allocated 4G so that's extremely unlikely to be the problem. One CPU is still kept busy by the JVM, although it's interesting to see the load fluctuated between the two at one stage. In any case, it still doesn't draw properly even when left idle for minutes.

I doubt it takes another 4G of RAM and a processor to redraw the few missing bits 🙂 I'm calling it a bug, not a resource issue.

[Cartu38 OpenDev]

Here is my VM snapshot. STM32CubeIDE 1.3.1 + Ubuntu 18.04 + 4Go memory + STM32CubeIDE native java (none available as part of my VM). I've got a try based on same device as you.

Not helping you sorry but works for me.

[GMinc.1]

Hmmm... Our setups are remarkably similar.

One difference I can see is that you have it installed in your home folder, ~/st/stxxxxx. Mine always installs in /opt/st/stxxxxx and there's no option to change that. I wonder if it makes a difference, due to permissions or something?

Did you install the .deb_bundle, or the generic linux version? Or some other way? I checked the setup.sh in the deb_bundle and can't see any way of altering the installation folder.

[Cartu38 OpenDev]

Relying myself on generic Linux installer (tar.gz delivery)

[GMinc.1]

As luck would have it, after many days of frustration I've stumbled upon a reliable solution. When I allocate two processors to the VM, it always works now. I don't know why this didn't work yesterday when I tried your suggestion of more resources, and you can see in my second screenshot that one of the processors is running at 100% usage. But today this always works correctly.

I've now created a fresh Ubuntu 18.04 VM with 3G of RAM, 20G hard drive, 2 processors and everything else is pretty much the default options. I installed the deb_bundle for STM32CubeIDE 1.3.0 and allowed it to upgrade to 1.3.1. The STM32CubeMx perspective now works reliably.

Only tested on Windows hosts at the moment. I'll try it on a Mac host in the next couple of days.

I'm still calling this a bug. With two processors it always works. With one processor it virtually never works (I had seen it work occasionally, maybe 10% of the time). If it worked slower with one processor then of course that would be understandable. But to hang java indefinitely and not work at all makes it a bug.

[Cartu38 OpenDev]

Possibly issue if single CPU VM setup. I'll not have a try myself guessing ST will do. But frankly speaking is single CPU usage reasonable ? ...

[matte]

Hi @GMinc.1​ ,

I did try with VirtualBox 6.1 and Ubuntu 18.04 to re-produce your problem following yuor step-by-step guide. I allocated 4GB RAM and 60GB of hdd for my guest.

It worked as anticipated, some min icon rendering issues in the MX editor, but just minor stuff, it did not interfere with the usage of the tool.

Also tried reducing the guest to run on only 1 core. No issue there either.

Keep us posted if you narrow this problem down further.

[GMinc.1]

Thanks Cartu and matte for attempting to reproduce the problem. I found it worked equally well with a Mac host as well as a Windows host, provided 2 CPUs were allocated. RAM usage never exceeded 3GB and disk space required was about 13G including the OS and STM32CubeIDE.

But in the end it felt slow and a little unresponsive even when working correctly, and it did some weird stuff like recognising single keypresses as multiple keypresses. e.g. I'd type "GPIOB->" and Eclipse would show "GPIOB ----->>>>>". Lots of slowing down, careful deleting and re-typing... It bordered on unusable, but the original problem was reliably fixed.

In the end I took the plunge and installed it directly on my Mac. Apart from a broken installer that every Mac user seems to know about, it works perfectly. Very responsive, programming a Nucleo board via STLINK worked first time, and it can update itself without needing to run it as sudo! I wanted to use it in a VM because I didn't trust Eclipse/Java not to mess up my pristine Mac OS installation. One of the many things I learnt while messing around with Ubuntu is that STM32CubeIDE brings its own Java package and doesn't need anything else installed. So by now I'm less concerned that it's going to ruin all my other apps, and indeed it seemed to go well.

Oh, I also tried it under Ubuntu 20.04. Turns out it needs an old ncurses library that doesn't come with 20.04. That's easily fixed, but it definitely seemed to run slower than with 18.04 under the same VM specs. I don't think GDB was very happy, so I went back to 18.04 in which everything did work, kinda, then gave up and installed it directly on my Mac. Happy days.