Is ST Cube IDE a piece of buggy crap?

[dietert1]

So let's recap...
..

I think yes. You use what works. And work around problems. I think software design at that level isn't completely logic anymore, but more like psychology. The days of "clean design" and "bare metal" are gone. Nobody - not even the makers of those MCUs - can tell you the last detail nor predict what will happen after the next silicon or HAL revision. The SPI ambiguity mentioned above is a good example. Obviously the reference manual contains dead information that may have applied in the past but is no longer true. So it is good we have both HAL and a reference manual.
Anyway nowadays we can't rely on anything but have to implement automated test procedures to guarantee a product works. We have to repeat those tests and solve issues after each and every revision. I admire those developers who dare to publish an IDE supporting thousands of MCU variants. It starts with Arm technology being a disaster in complexity.

Regards, Dieter

[NorthGuy]

As usual the truth is somewhere in the middle. 

Or there are many different "truths".

Whoever used the Cube for 20 different projects and knows nothing about the underlying hardware cannot live without Cube. Someone who knows the hardware wonders why would he need the Cube. The choice is who of these two you want to be.

[Kjelt]

Whoever used the Cube for 20 different projects and knows nothing about the underlying hardware cannot live without Cube. Someone who knows the hardware wonders why would he need the Cube. The choice is who of these two you want to be.

Even the latter only if that person only has to cope with single uCs family or has years of exoerience on more.
If that person knows for instance the F2 and F4 series and his boss wants to cut down costs of an existing project by switching to the F1 series, he might be in a potential minefield. Reading all the errata of the F1 series and checking all peripheral workarounds with their existing codebase might still cost tons of work not to mention the testing and certification of the end product. Guaranteed something is overseen and does not work as expected. A quickly generated Cube project and checking if the peripheral works as expected in that case might help. Checking the deviation in order of initializing and the calls for using a peripheral might than be a timesaver.

[dietert1]

Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.

Regards, Dieter

[peter-h]

I think the % of people programming a 32F4 or similar who actually read the RM, and who are hardware experts as is required to understand much of that, is quite small.

I've been doing hardware for decades, including FPGA design, so I understand what I am reading in the RM, but the interaction of the various configs, e.g. the pin assignments, DMA channels, etc, is quite complex.

So a code generator which gets you started, especially with stuff like clock divider configs where a code generator works naturally well, is useful. It is a pity that ST's code generator is not more granular - see e.g. the HAL SPI function above, which tests loads of conditions which may or may not apply at all.

I am going to waste another day of my life to try to work out what actually can be made to work under win7-64. I know Cube 1.6.1 works (on two machines) but special conditions apply. And 1.7 may work also. Somebody in ST may know... but those people rarely post.

Wasn't there some site which enabled M$ updates to be applied as if they came from M$?

The usual error is 0x80240017 and with no apparent solutions.

[peter-h]

Does anyone know how to copy a 1.6.1 Cube installation to Cube 1.5?

If copying 1.6 to 1.6, the easy way is to install Cube on the 2nd machine and copy over the project (in my case c:\kdexxx\project1, which also contains c:\kdexxx\ide for some reason) and then copy over the configuration directory which is under c:\ST. Then it all just starts up fine.

But this doesn't work for 1.6.1 to 1.5. I get all sorts of problems like it cannot find the toolchain, etc. And as previously discussed
https://www.eevblog.com/forum/microcontrollers/how-to-duplicate-a-st32f4-cube-ide-project-on-another-pc/msg3568595/#msg3568595
the various "import" or "open project" functions in Cube don't work.

I also notice that 1.5 uses a "workspace" directory which is under c:\users which 1.6 does not use. There are bits of this crap all over the place and different Cube versions used different places.

BTW Cube 1.5 has a compiler version 7.3.1 20180622. Cube 1.6.1 is 9.3.1 20200408.

EDIT: after a few hours I worked it out. When Cube is installed initially (a clean install, with all of its directories deleted beforehand) it presents you with a list of options for opening existing projects, and one of these actually worked! You do not get that option with an existing working Cube installation if you just want to open a new project. It is a right POS.

Funnily enough -Og builds a smaller project (159k v. 162k) using the v7 compiler I did try to load the 1.6 .exe tools into the 1.5 directory structure but that just blows the whole thing up

It is quite fun to be able to build the same project on the base machine, or inside a VM. You can't share the same debugger though, or at least I have not found a way, probably due to USB conflict. But the VM Cube can certainly drive a different debugger, and could drive a different target, so you could run two targets concurrently. I believe you can do that anyway, with two copies of Cube running on the base machine, but the advantage of a VM is that you know there is no accidental cross-linking of files. The project inside the VM is 100% definitely self-contained, plus the whole VM can be moved to another machine very easily which is obviously impossible with a base machine installation of Cube, which is tightly linked into the base OS.

I just wish I could install the VC++ 2015 or later redists in the VM. I've posted the Q in various places and will advise if I ever solve this. Cube 1.5 works ok (with the same bugs as 1.6 e.g. the Build Analyser works only at xmas) but with 1.6 you would get the v9 compiler. But is v9 any better?

[NorthGuy]

Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.

Sure. Eventually AI surpasses humans in every aspect. This will be the end of human dominance on the planet.

[harerod]

Well, this is interesting:
https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/

Is anybody reading this, who has CubeMX running in an ?NIX-environment? How is your experience debugging with Segger J-LINK and ST-Link? My current setup is CubeMX 1.3 under either Win7-64 or Win10 and J-Link is rock solid.

I mean "never change a running system", but it wouldn't hurt to know alternatives to Win10++.

[SiliconWizard]

Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.

Sure. Eventually AI surpasses humans in every aspect. This will be the end of human dominance on the planet.

Through human-made tools.

[dietert1]

Just downloaded and installed en.stm32cubemx-lin_v6-3-0_v6.3.0.zip on a Debian Jessie 64. Fast and easy and started working without any complaints. Maybe i will try other parts of cube as well.
Before i have been using CubeMX 6.0.0 under W7 Pro 64 (offline workstation).

I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.

Regards, Dieter

[JOEBOBSICLE]

It's fairly easy to use non st tools, I have fully reproducible builds using docker containers that contain arm-none-eabi-gcc.

Much better than having lots of 20 GB virtual machines around

[dkonigs]

Well, this is interesting:
https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/

Is anybody reading this, who has CubeMX running in an ?NIX-environment? How is your experience debugging with Segger J-LINK and ST-Link? My current setup is CubeMX 1.3 under either Win7-64 or Win10 and J-Link is rock solid.

I mean "never change a running system", but it wouldn't hurt to know alternatives to Win10++.

All the tools work perfectly fine on Linux.

(Though to be fair, they also work fine on an up-to-date Windows system, if you're not dedicated to trying to break them in unique ways so you can then complain.)

But really, if your local user has full permission to the installation directories of these tools, you're unlikely to have any issues when updating them.

The OSX issues stem entirely from the platform's more unique approach to permissions, combined with software developed by a company that doesn't really focus on Mac support as much more than an afterthought. (Which is kinda a common issue with anything developed by a large organization who's developers aren't heavily involved in the unique peculiarities of the Apple developer ecosystem.)

My main development system is running the latest version of Fedora Linux, where all the ST stuff has worked perfectly fine for me.

(But I also run the tools on a Windows 10 machine at my lab bench, and a MacOSX laptop, depending on the situation.)

[lucazader]

the only issues I have running cubemx and the cube programmer on fedora are:

Cubeprogrammer will only launch properly when running x11. will not launch on wayland
Cubeprogrammer will fail to launch the stlink firmware updater.

The installers etc are much better than they used to be now that they include a bundled version of java (openjdk). They now "just work" (tm)

[peter-h]

Just heard that you can run a win10 VM under any version of Windows (and presumably other OSs) and since win10 seems to be the baseline for Cube now, that ought to work. No need for win7-64 as the lowest common denominator.

[harerod]

Just heard that you can run a win10 VM under any version of Windows (and presumably

other OSs) and since win10 seems to be the baseline for Cube now, that ought to work.

No need for win7-64 as the lowest common denominator.

A major reason why one would prefer Eclipse/GCC over IAR or KEIL in a professional context, with a long product lifecycle, is that the tool comes without a dongle and without an internal killswitch. Same as using Kicad or EAGLE7 instead of modern EAGLE. With any Windows version up to and including Win7-64, I know of a legal way to set up a virtual machine that can be reactivated offline anytime.
As far as I know, that same triviality would require a special version of Win10. I would love to have that statement proven wrong.
This is the major reason why I am interested in the development at the ?nix-front. And no, I am not married to Win7. That last machine is only operative, because it holds some old perpetual Adobe and Microsoft licenses. There are three Win10 machines and one Linux box here as well.


Another plus regarding GCC is that a broken IDE shouldn't be a showstopper for a competent developer. One could always build from the command line. And that brings me to the reason why I don't find CubeIDE all that painful - I have seen and worked with other STM32 development tools in the last fifteen years: aside from IAR-EWARM, I remember GCC with make, homebrew Eclipse with openOCD, CooCox, Atollic and now CubeIDE. The thing is - I could still use GCC with make, but somehow I find a carefully setup CubeIDE 1.3.0 more appealing for handling 435 source files in three production build configurations. (mainboard STM32F407-firmware for current project, FreeRTOS, LwIP, wear-leveling filessystem in MCU-FLASH and -CCM, several UARTS, SPI, I2C, USB, all the classic peripherals). Btw, I only started using CubeIDE/CubeMX last spring. Since then I have build five commercial designs, three STM32F4 and two STM32F1.

[NorthGuy]

I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.

Sure you can. You can manually instantiate every element - LUT, flops, BRAM, DSP. You can place them at will. You can even do custom routing at will. ISE had XDL language, sort of an FPGA assembler, which describes the elements, settings, and routing. ISE compiles VHDL (or Verilog) code into XDL then it gets transformed into a bitstream. Pretty much like the C code compiles into assembler and then the assembler code gets transformed to binary/hex.

Now Xilinx switched to Vivado, which doesn't have XDL, but you still can write pure structural VHDL/Verilog and do low-level things with TCL scripts if you wish.

[peter-h]

I have paid for software I actually use, and too would avoid anything online-licensed because it will die once the license servers stop working. Look at how Adobe killed CS3; they had to give away CS2 keys for free to get around the outcry.

IMHO if you have paid for software then nobody can complain if you fix it so it continues to work for ever. I have late-1990s CAD/EDA software which works perfectly and which has been de-dongled.

WinXP seems to run for ever now; it looks like MS no longer implement deactivation if the hardware changes. Also it uses offline activation - just a key. So XP is popular for industrial/test rigs because you can be sure it won't suddenly blow up. Win2000 was even better (no online activation at all) but much less solid than XP. Also XP runs fine indefinitely with no internet access which is important in many scenarios. Win7 is heading that way; I recently changed a VM from 1 CPU to 2 CPUs (stupid move) and it said the OS is counterfeit (it wasn't) but that message never reappeared (but I am sure it did some sort of online reactivation). So MS probably is still running online activation for win7. Also there are easy hacks for win7. With Win10 it will be a long time before it reaches that "safe" stage. All that will happen soon is that when win11 comes out, you will be able to buy a legit win10 license on Ebay for 30 quid

I've been using Cube for 8 months now and it is certainly usable. Irritating bugs, but it does the job and is free. Sometimes I am writing and debugging code several hours a day. If there was a course on it, I would do it but nobody runs them. You just get Youtube videos which tend to be a useful overview but you can't ask questions.

Is IAR a floating license? That is a nightmare for long term projects.

[dietert1]

I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.

Sure you can. You can manually instantiate every element - LUT, flops, BRAM, DSP. You can place them at ..
Now Xilinx switched to Vivado, which doesn't have XDL, but you still can write pure structural VHDL/Verilog and do low-level things with TCL scripts if you wish.

No, that approach may have been practical for CPLDs, but not for FPGAs. With FPGAs you won't get anywhere within your lifetime. Nowadays we use abstraction to get things done, including constructs predefined by others, e.g. language contructs or configurable IP. And the same happens with MCUs.

Regards, Dieter

[peter-h]

Don't people use "schematic capture" (a once fashionable term for drawing a circuit diagram)? I did loads of Xilinx X3000 FPGA design (using Viewlogic 4 + XACT 5 - two dongles!) and drew all the circuits. When I had to implement a state machine I used a Viewlogic utility which converted the boolean equations into a logic circuit diagram and merged that in.

Can't see where Cube would work in that way. It is just for text, AFAICT.

Nowadays CPUs must be designed using a language, which is compiled to the logic.

[dietert1]

The entities in a schematic are abstract, they don't exist in the FPGA. With an MCU you use language abstractions and trust the compiler implement them right (loops, arrays, pointers whatsoever). With cube you have a graphical configuration utility to configure abstract entities and you trust it to implement it right.
Of course there needs to be verification. It can be automatic, like measuring the actual CPU clock using some other redundant clock, or checking actual RAM size. Verification can also be manual, like looking into configuration registers at debug time.

Regards, Dieter

[NorthGuy]

Nowadays we use abstraction to get things done, including constructs predefined by others, e.g. language contructs or configurable IP.

Sure you do. But since you think that this is the only way, what's your alternative?

The entities in a schematic are abstract, they don't exist in the FPGA.

You can create a schematic which uses logic ICs, or you can create schematic which uses built-in hardware blocks in FPGA, or you can create schematic which uses discrete FETs, or you can create schematics which uses abstract logic gates and registers. These will all be different schematics, but will do the same thing. If, for some reason, you need to produce all of these, you can write abstract Verilog code and use various tools on the same code to create all these schematics automatically. Write once, run everywhere. This is an example of a good abstraction.

But, if you want to build a bitcoin FPGA farm which produces $10M/year, and then you decide to use abstract Verilog code which is 10% slower and consumes 10% more power over what you could have developed specifically for your target FPGA, this is pure stupidity which costs you $1M/year.

As any tool, abstractions may be good or bad. For example, when you write a program for PC, there are graphics drivers which create an abstraction layer. With this model, you can write your program without even knowing what PC it will run on. Your program will run fine even on PCs with graphics adapters which hasn't been designed yet. My programs from last millennium runs fine on modern PCs. How wonderful.

Or look at the TCP/IP protocol which uses abstract packets and can be used seamlessly with different transport layers. This is a useful abstraction and 50-year old TCP/IP is widely used now even though technologies made a huge leap forward.

Or C. You can use it to write code and compile it for different CPUs. Isn't it amazing?

On the other hand, nowadays "abstraction" is used to create tremendous amount of bloat making today's software 100x and 1000x times bigger, slower, and more complex that it could have been. This introduces lots of bugs which are nearly impossible to fix, and this is getting worse and worse. That's a different kind of abstraction. People get obsessed with this form of abstraction. Perhaps not so much embedded developers, but the so called "full stack" developers. They perceive all this tremendous bloat as useful and necessary, while it is clearly harmful.

So, a designer needs skills to implement good abstraction, needs guts to reject bad abstraction, and needs brain to tell them apart.

[peter-h]

After a few hours' work I can confirm Cube 1.7 installs and runs under win7-64 SP1.

It also builds my existing 1.6.1 project, to a binary image of exactly the same data - crc32 checked!

Compiler version is: gcc version 9.3.1 20200408 (release) in both Cube 1.6.1 and 1.7.0

More detail:

I started with an old win7-64 VMWARE VM. Made sure there was >10GB free space left I was able to install SP1 (downloaded from https://blog.simplix.info/update7/ which is a brilliant resource).
Then applied VC++ 2019, from M$ website.
Then I applied all updates up to August 2021, again using the above site. These updates are normally available only to paying M$ contract customers (M$ stopped auto updates for win7 a while ago). I have no idea if this last step makes a difference, or whether SP1 with the VC++ stuff is enough. But I am quite sure VC++ 2015 or preferably 2019 is required for Cube 1.6.1 or 1.7.0.

Then installed Cube 1.7.

Being a virgin Cube install, it shows



Choose Import Projects



My project is in c:\kde420\project1



and it opens it and it all works!

Have ST fixed the Build Analyser not showing up bug? Not really. It does now show up on the second build

I can see some changes e.g. more here



so they probably did change a whole lot of stuff, none of it documented in the official change log. I notice that F5 and F6 seems to work more reliably. F6 (step over) often stepped into the function.

To run Cube in a VM you need to check the "shared STLINK" box otherwise you get verify errors on the STLINK code load.

[peter-h]

There is a variety of issues running Cube in a VM if you are using a debugger, due to USB device sharing issues. Well, a USB device cannot be shared

I successfully ran one Cube on the base machine, to one STLINK debugger, and another Cube in a VMWARE win7-64 VM to another STLINK debugger. The debuggers were STLINK 3 & STLINK 2 but that is probably not material. So this way you could run two (perhaps interacting) targets, two debuggers - potentially useful!

What is more messy is if you have a debugger connected and then start the VM. The VM will not pick up the USB device(s) because the base machine is holding them. You have to, as a minimum, unplug and replug the debugger USB cable and then the VM should pick up the debugger. And same if running the USB VCP for debug text. It isn't all that reliable, and I've had WMWARE do a BSOD which is otherwise very unusual.

[peter-h]

A further data point:

I decided to take the risk and update the 1.6.1 Cube on my win7-64 PC. I had previously tested it in a VM.

Installed the latest x32 and x64 VC++ redist package "2015-2019". This is essential, though it's not clear which exact VC++ version is needed by which Cube version. I think 1.6.1 needs VC++ 2017.

Updated Cube 1.6.1 online to 1.7.0.

It also offers to update the USB driver, and then the firmware in the STLINK V3 debugger.

As noted above, the compiler version is the same as 1.6.1 and the generated binary is identical byte for byte.

Most curiously, after 1.7 installs you get a PDF release note pop up which gives the system requirements as win7-64 or higher:



The other Cube "system requirements" I saw, somewhere on the ST website, stated win8.1 or higher. This new PDF is called DM00603738.pdf.

Fixed issues: https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.7.0

It does overwrite the project dir irreversibly so you can't go back to a previous version (it says).

SWV ITM data console is now much more reliable; that's an immediate benefit.

[MWP]

There is a variety of issues running Cube in a VM if you are using a debugger, due to USB device sharing issues. Well, a USB device cannot be shared
I successfully ran one Cube on the base machine, to one STLINK debugger, and another Cube in a VMWARE win7-64 VM to another STLINK debugger. The debuggers were STLINK 3 & STLINK 2 but that is probably not material. So this way you could run two (perhaps interacting) targets, two debuggers - potentially useful!
What is more messy is if you have a debugger connected and then start the VM. The VM will not pick up the USB device(s) because the base machine is holding them. You have to, as a minimum, unplug and replug the debugger USB cable and then the VM should pick up the debugger. And same if running the USB VCP for debug text. It isn't all that reliable, and I've had WMWARE do a BSOD which is otherwise very unusual.

Maybe they are VMWare issues, not "VM" issues?
Ive run my STM32 Eclipse devel environments under VirtualBox (Win10 host, Linux clients) for 5+ years. I've had very few USB problems.