Is ST Cube IDE a piece of buggy crap?

[peter-h]

I wonder if somebody out there has actually used that feature - other than in the simple scenario of reverting to the last version of GCC upon upgrading Cube.

Re bug fixes, one doesn't need to update the IDE or the tools at all.

STM fairly comprehensively broke Cube 1.15.0 anyway, so as well as GCC 12 breaking some stuff you have Cube breaking the debugger etc.

[mr ed]

Retired sw guy here. Yes, it's buggy. It was buggy 6 years ago when I last worked with it. It will always be buggy as it's chasing the latest flavor of stm cpu. It's part of marketing the stm hw chips.

The cube is a way to help get projects off and running fast, not bug free running. No project leader wants the team to struggle through 20 chapters or 2000 pages of hw register descriptions with a prototype pcb coming. STM knows this. We all should understand this too.

The cube will put down some code to initiate the cpu and get run of the mill code up fast. Run of the mill being some io, ethernet, irq's and setup some calls to your preferred os slicer etc. The idea of leavng the code as a base is horrible with so many bugs.

If you want a quality product, the cube generated code will have to be frozen, debugged, patched, whatever and never updated again. It will converge to a stable base after a while.

[peter-h]

You are talking about Cube MX - the "code generator". I would never recommend using that other than to generate a code fragment for a particular peripheral and then see what it did and rewrite it in your own style etc (stripping off all irrelevant crap).

MX will do working code for stuff like SPI and such. The chances of getting MX to produce properly working code for complex stuff like ETH (with LWIP) or USB (VCP, MSC, etc) is basically zero. You need to google for fixes and apply them. One problem is that probably only 1% of the devs who fixed something go public with it; the rest are doing it commercially and don't want to help a potential competitor.

Cube IDE is the editor / compiler / "automatic makefile generator" package, which does work but has a few annoying features - see further back up this thread.

[DavidAlfa]

Just use LL, no magic behind the curtains, optimized and universal don't dance together.
No more ranting, full HW control, still mu h easier than sleeping with the RM.

[MathWizard]

Today I had a real hard time trying to uninstall the latest STMCubeProgrammer. I installed it in a non-default place, IDK if that did it, but I had to go try and uninstall it by deleting it and the registries.

[peter-h]

Is there an archive of Cube IDE install packages anywhere?

I decided to freeze my project on 1.14.1 (1.15.0 was next and broke various things; including GCC 12 having some different option defaults) and obviously kept the installation package for 1.14.1 but when I came to download the linux and mac versions of this, just in case they were needed by some future dev, I found them gone.

ST keep 1.13.0, 1.14.0 etc for some time on their website, and I downloaded the 1.14.0 versions, but they don't keep the .1 versions. No response on their forum as usual. Maybe there is no difference. I know for a fact that ST's errata sheet is far from the whole story.

[elektryk]

I've switched to 1.14.1 from 1.9.0 because H5 series was unsupported with this version.
First thing which annoyed me was that they now want me to login for firmware packages download/update, another one is the good old bug with random files opened during debug/run operation.
As far as I know it is still present in 1.15.1.

Is there any workaround to overcome this?

ST keep 1.13.0, 1.14.0 etc for some time on their website, and I downloaded the 1.14.0 versions, but they don't keep the .1 versions. No response on their forum as usual. Maybe there is no difference. I know for a fact that ST's errata sheet is far from the whole story.

There is 1.14.1 on their website, but only for Windows. Rather, it's worth asking  if 1.14.1 ever existed for Linux.

[DavidAlfa]

1.12.1 was the latest version without the annoying login crap, try it out.

[peter-h]

There have been many changes from 1.12. I would not recommend 1.12.x

I am looking for 1.14.1 but maybe 1.14.0 is the same on the linux and mac versions.

Rather, it's worth asking  if 1.14.1 ever existed for Linux.

Indeed, but nobody at ST responds to anything

First thing which annoyed me was that they now want me to login for firmware packages download/update, another one is the good old bug with random files opened during debug/run operation.
As far as I know it is still present in 1.15.1.

You can download as guest, giving them an email address and they email you a download link.

The random file opening issue (see past posts here) has always been there and remains unfixed in 1.15.1. The file which gets opened isn't quite "random"; it is wherever the CPU was when it was stopped. If e.g. you use an RTOS then (with well written code) the most common stop point will be the scheduler wait function. The way to stop this behaviour is not trivial but it is fairly easy to work out a way to do it, and it was posted back here, maybe a year ago. But ST are clearly not willing to do it.

EDIT: ST replied to my post on their forum (pretty unusual):

The STM32CubeIDE 1.14.1 is supported only on windows in order to resolve the issue with Prebuild or Postbuild commands.

So 1.14.0 should be fine for linux, debian and mac. Never actually used any of these; I thought debian was "unix" same as linux

I also see they have moved on pretty fast from v 1.15 and are now doing 1.16.0
https://www.st.com/resource/en/release_note/dm00603738-stm32cubeide-release-v1-3-0-stmicroelectronics.pdf
I can't see many devs spending time following this constant stream of releases and more importantly doing regression testing of their product after each one!

[glenenglish]

I NEVER use the HAL, not ever.

IMO You will never learn about the peripherals and chip in depth using the HAL

I might use the HAL source though if I cant get something working and want to see ' how they did it'

glen

[glenenglish]

Recommend Rowley Crossworks if you want pro kit.

[peter-h]

I NEVER use the HAL, not ever.

That is a different thing. The "HAL" code is generated by Cube MX, which is a "click and drop" code generator. MX is useful if you want to get started quickly. The code is generally bloated, usually stupidly (e.g. for SPI they might enable CRC but only if CRC is enabled, which they find out by, guess what, reading back the CRC enable bit ).

So one starts off with this auto generated code and strips out the dross. A lot faster than reading the 2000 page RM, or spending the day googling which most devs seem to do.

I might use the HAL source though if I cant get something working and want to see ' how they did it'

Precisely!

Recommend Rowley Crossworks if you want pro kit.

USD 1500 per seat And I bet they enforce the licensing by checking online. So your project will be dead if/when their license servers are taken down. Adobe CS3, anyone? This kind of stuff is no good if you need to revisit a project say 10 years later. Cube IDE doesn't do online checks (except for updates, which you disable) so a whole project can be archived.

I am sure corporate users go for this because they want support.

Cube IDE has lots of problems (perhaps the best is the ability to set breakpoints where there is no code, e.g. on comments ) but it works ok.

[SiliconWizard]

I NEVER use the HAL, not ever.

IMO You will never learn about the peripherals and chip in depth using the HAL

Well, yes, or no. Unless you're doing very simple stuff, it's often required to learn about the underlying peripherals in order to understand the parameters that you pass to HAL functions.
But for those not "curious", it may (?) push them to just use basic features of the MCU instead of really taking advantage of it. (Then again, if we take the extreme of the Arduino framework, you get the same problem, but even much worse.)

As we said in other threads, the main benefit IMO, in a longer term than just when you discover the chips, is for portability across MCUs of the same vendor. And, admittedly, it does help with that.

I might use the HAL source though if I cant get something working and want to see ' how they did it'

Yes, that can be used like that.
And yes, I don't like using third party-code either, unless it's very good. It has very little chance of matching my requirements in terms of code style, robustness, readability, testability, and whatnot.

[westfw]

Quote

You will never learn about the peripherals and chip in depth using the HAL

So?  What makes you think people WANT to learn all about the grimy details of the peripherals just to get some meaningful application working?  (The same principle that makes Arduino successful.)
Although, the last time I looked at HAL, you pretty much had to look up all the details of the peripherals in the HAL reference, instead of details in the hardware reference' a sort of meaningless abstraction that didn't really simplify anything :-(  (And then you had to look in the HW documentation anyway, to see what the abstracted enum actually meant...)  Sigh.
(Arduino has the opposite problem - the abstractions are pretty good, but they only cover a tiny portion of the features offered by the HW.)

[NorthGuy]

And yes, I don't like using third party-code either, unless it's very good. It has very little chance of matching my requirements in terms of code style, robustness, readability, testability, and whatnot.

The amount of work required to assert that the code is very good is similar to the amount of work necessary to write your own code.

[peter-h]

As I said, the HAL stuff is ex-MX, not related to ST Cube IDE.

But I can tell you from spending the last few years on this project (it is finished now, btw; just struggling with a totally inept PCB assembly firm which bodged the pre-production batch) that there are way too many subtleties in interfacing to hardware to just simply disregard code written by others which you know in all probability does work even if not optimally written.

I never actually ran Cube MX myself. The guy who started this project a few years ago used MX to generate various code fragments, incorporated them into the project in Cube IDE and then binned the MX sources. I suspect a lot of people do that, because MX is just too clumsy and inflexible by the time you get your project beyond flashing some LEDs. You can get as far as getting e.g. FreeRTOS and an HTTP server with LWIP working and it makes a great demo but the code has many problems which you then spend months picking apart. But I have used various "HAL" functions I found on the internet, simplifying them as needed.

[glenenglish]

Cube MX has LWIP on freeRTOS ?.

When are these people going to get into the 21st century and use freeRTOS+ TCP. LWIP is something from  and constrained by   the 1990s for a 4 bit microcontroller having to respond to ping.....

Yes, I am exaggerating, but those with experience will get my cynical drift.

[ataradov]

What is "TCP" in this context?

LwIP is a fully featured TCP/IP stack that is pretty performant. There are not a lot of embedded TCP/IP stacks that are much better.

[glenenglish]

except that it is written with the expectation that is operates largely asynchronously, - that is to say, without a higher level supervisor / RTOS / task switcher......it's written to run when there is no supervisor- a single thread if you will for the whole system.... which makes debugging problems absolutely maddening .

and which is very much against the grain of having FREERTOS as a host. FreeRTOS+TCP is full synchronous, blocking code so is far easier to debug because it doesnt keep jumping away and restoring state etc each time is has to wait for something

Sorry, anyway, off topic. back to CUBE.

[SiliconWizard]

I haven't worked with lwIP, but in general, each approach has its own set of issues. Preemptive multitasking may look easier to work with, somewhat, until you run into nasty synchronization issues. That's a different beast. "Cooperative" non-blocking approaches indeed require managing internal state, while there is no state to care of with an RTOS: it's all handled "transparently". Yeah, mixing the two may be a bit uncomfortable, but that would pretty much all boil down to synchronization issues.

[elektryk]

1.12.1 was the latest version without the annoying login crap, try it out.

I tried to create a new project but IDE 1.12.1 doesn't let me to choose the latest H5 FW 1.1.1 even though it is currently installed in C:\Users\myUsername\STM32Cube\Repository folder.

[DavidAlfa]

Just use the damn ST account you already have, you must login to download the IDE anyways 

Edit:

To use latest v1.3.0 in IDE 1.12.1:
 - If present, delete C:\user_profile\STM32Cube\Repository\STM32Cube_FW_H5_V1.0.0.
 - Download FW package v1.3.0.
 - Extract to C:\user_profile\STM32Cube\Repository\STM32Cube_FW_H5_V1.0.0.
 - Edit package.xml, change <PackDescription Release="FW.H5.1.3.0"> to <PackDescription Release="FW.H5.1.0.0">.
 - Choose FW v1.0.0 CubeMX (Project Manager -> Firmware package).
 - Done.

- You can check the current HAL version in Drivers/STM32H5xx_HAL_Driver/Src/stm32h5xx_hal.c:

Code: [Select]

@brief STM32H5xx HAL Driver version number 1.3.0

[paulca]

HAL is a great attempt.  It is just badly done.

Reusable, canned code is the mainstay of modern software dev.  Without it we simply would not be where we are today.

For example, if I write a webserver I don't need to interface with the Ethernet hardware to do so.

The trouble with the MCU platforms is they suffer from more strict "non-functional" requirements than most software.  So large "do-all" abstraction layers are expensive.

HAL tries to handle the hundreds of permutations of hardware combinations... and mostly fails.  However it does it via 1960s C style IFDEFs to limit the code which is actually compiled to make for "lean binaries".  Understandable, however Unix has shown us that this approach is not scalable.  HAL is just a rather late and sad attempt to make it work.

I would expect that STM would benefit from giving up on writing software and farm that out elsewhere or invest into making it properly opensource.

[wek]

(Arduino has the opposite problem - the abstractions are pretty good, but they only cover a tiny portion of the features offered by the HW.)

That's not a problem, but a fundamental feature.

"Abstraction" means using only the common mutual denominator; so, by definition, only a fraction of what's possible with all the variants of the hardware.

Also, any "library", even if not trying to "abstract", inevitably covers only a miniscule fraction of what's possible with the hardware. You have dozens of features in each peripheral, times dozens of peripherals per mcu, times dozens of usage modes; and just that many time/energy/money to write any "library", which - if has to be of any worth  - then has to be tested in dozens of instances.

"Abstraction" proponents cite the success in realm of "big computers"; but those are almost stupidly simple compared to mcus, when considering the fundamental working principles. This is hard to explain to "pure programmers" (especially the variety occuring in academia).

JW

[paulca]

(Arduino has the opposite problem - the abstractions are pretty good, but they only cover a tiny portion of the features offered by the HW.)

"Abstraction" means using only the common mutual denominator; so, by definition, only a fraction of what's possible with all the variants of the hardware.

Also, any "library", even if not trying to "abstract", inevitably covers only a miniscule fraction of what's possible with the hardware. You have dozens of features in each peripheral, times dozens of peripherals per mcu, times dozens of usage modes; and just that many time/energy/money to write any "library", which - if has to be of any worth  - then has to be tested in dozens of instances.

"Abstraction" proponents cite the success in realm of "big computers"; but those are almost stupidly simple compared to mcus, when considering the fundamental working principles. This is hard to explain to "pure programmers" (especially the variety occuring in academia).

JW

This is utter bollox unfortunately.  "big computers" are stupidly simple compared to MCUs?  In which fantasy are you living?  Have you ever even looked at low level Unix or Windows?  They are a 100 times more complex, no 1000s of times more complex.  The average off PC today has 8 async cores, async memory, async hardware buses.

You go and try some "bare metal programming" on big iron and come back and re-read your post.

Also, before we had all thus abstractions when you wrote code, you wrote it for the CPU and configuration of the device at hand.  It did not work on any other device without a rewrite.

Yet today I can write code which will run on anything including MCUs.  How?  Abstraction.  This is the true meaning of it.  Not "simplifying to an interface" which is actually called "Facading" not abstraction.