Is ST Cube IDE a piece of buggy crap?

[SiliconWizard]

Peter.  To be honest.  I'd give up.  All of your posts in this thread just say you aren't cut out to be a developer.

That's probably true, but what he said about Java just above holds 100% true. Most Java apps are distributed with a compatible JRE that the app has been tested against, and a whole range of issues can occur if you use another JRE.
Java has never been all that stable in terms of compatibility, unless maybe you used only very basic libraries. Anything using fancy GUI Java libraries is a compatibility nightmare.

If you did my day job you'd go postal in weeks.

Don't know what your day job is, but certainly a pure software development position would make a lot of us go nuts very quick. It's become, uh, very special.

[peter-h]

I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.

Similar to having a macro in a .h file which actually generates executable code.

Re "cut out to be a dev" well obviously not, because a real dev

- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing

[NorthGuy]

because a real dev ...

Real programmer may or may not know the name of his spouse, but he knows all the ASCII codes.

[jgrossman]

I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.

I agree in general, but that code is literally a HAL library. It's not generated for you to modify.

[DavidAlfa]

I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?

this code is generated for people to use as example in general.

Absolutely not.
You should call the HAL function (SPI send, UART TX, whatever) and check the return code, not randomly call __HAL_LOCK, which is meant to be internally used by HAL, not by you!
It would be 100% your fault if you randomly call it without understanding what it does.

[Karel]

Re "cut out to be a dev" well obviously not, because a real dev

- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing

It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.
"Release quick, if people complain, we can fix it later with an update."

p.s.: I do use pointer arithmetic a lot, simply because I like it and because it's usually the most efficient way.

[NorthGuy]

It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.

People used to have integrity and would refuse to do crap if asked to.

"Release quick, if people complain, we can fix it later with an update."

But then new update will have two new bugs for every bug fixed.

I had to upgrade my Mac to Monterey OS because Apple has changed their "notarization" rules. This covers about 5 years of updates. It has become very slow and acquired new bugs.

[peter-h]

that code is literally a HAL library. It's not generated for you to modify

We will have to agree to disagree.

This is not the age of the Z80 when you had to read a few pages, and to get a working system you copied a Nascom 1 circuit - basically a CPU+EPROM+RAM and some latches for I/O.

This is the age of a 300 page DS and a 2000 page RM. Lots of people use Cube MX to generate code fragments (they are fragments really because MX is great for knocking up quick demos and then you have to do lots of real work to get a finished product) to save time and save many hours of googling to see how others did something e.g. drive the SPI controller.

Lots of times one picks up a function and uses the "body" of it. Yesterday I picked up the "HAL" function for the random # gen and put a mutex at the start and end of it (because it is called both by TLS and other user code) and a macro which contains a return() will obviously blow it up, because the mutex will never get released. I would not be randomly calling just hal_lock, obviously.

Everybody posting here is an expert (except me; I am learning from a low base and 40 years of asm) but this is a great way to get bitten in the bum.

[jgrossman]

that code is literally a HAL library. It's not generated for you to modify

We will have to agree to disagree.

I guess to be more specific, what I meant was:

It's intended use is to be generated and used wholesale. They are not trying to provide a template, and so are free to do literally whatever. If you want to use it that way, you just have to be mindful of what it is you are taking. I think we agree that it is kindof poor form to hide a return behind a macro that, to me, is named is if to imply "wait until ready", not "if not ready, bail". Trailing on that:

I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?

Nothing at all, as long is it isn't slightly misleading like __HAL_LOCK, where my first impression would be a wait until not-busy. __HAL_LOCK_OR_RETURN(), no problem there, clear as day what happens. Should you pay attention and understand what it is that means? Absolutely, but there can be friction in doing so where it is not obvious what something does.

[DavidAlfa]

Well, yeah, I do most of the time, specially "__HAL_” stuff, before taking anything for granted I find its declaration and check what it does.

[peter-h]

Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".

[DavidAlfa]

Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.

[newbrain]

Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.

No it does not under any  non cooperative threading model (time slicing, preemptive, multi core etc.).

Checking and setting the lock flag should be an atomic operation, and it's clearly not.

It's just a place holder for a possible RTOS compliant HAL.

[DavidAlfa]

Sort of. Still ST quality 

[NorthGuy]

Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".

You can re-define the macro to nothing. Having an easy way to annihilate unneeded locks is a good thing.

[paulca]

I just fresh installed Cube on Windows 10.

I cloned an old (year) project from git and opened the IOC.  It said I could upgrade it, so I said, "Aye on ya go then."

Then I hit Run.  Did the your STLink has a new firmware dance and .... it worked.

It worked.  Just worked.

Nothing to report here, nothing to see.

[peter-h]

Yes; apart from Cube IDE occassionally changing the GCC tool version and introducing different default compiler/linker options which bring up new warnings, I have found Cube updates to "just work".

Occassionally I uninstall Cube totally and reinstall fresh, just to make sure.

[zapta]

>> a macro which contains a return() will obviously blow it up, because the mutex will never get released

If you use C++, you can define mutexes that release automatically when leaving their scope. Very handy and safe IMO. Example:

https://github.com/zapta/daq/blob/main/controller/platformio/lib/data_queue/data_queue.cpp#L98

[zapta]

TL;DR, using CubeIDE for configuration only and platformio for the rest.

A few months ago I started a STM32H7 project and had a dillema which IDE to use. My favorite IDE is platformio, for all MCUs, but realized the value of the CubeIDE value in generating the initial and updated configuration code from the .ioc file. As a result I setup an environment with a combination of the two. A CubeIDE project is used only for editing the .ioc file and generating the code, with no manual editing whatsoever, and a platformio project is used for the rest of the code development. I use a small python script to automatically update the platformio library when I make configuration changes in the CubeIDE project.

Overall it works great for me, being able to use the CubeIDE configurator with the platformio project.

This is the python script I am using. It does a few patches to the CubeIDE code to simplify having a separation between the CubeIDe files and the code files I edit in platformio.

https://github.com/zapta/daq/blob/main/controller/cube_ide/update_platformio.py

[peter-h]

Just updated Cube IDE from v13 to v14 and the binary generated is identical. So thankfully they haven't changed the tools.

The random file opening issue (basically when you stop a running project, breakpoint, etc, a random .c file gets opened) has not been fixed. It still opens whichever .c file the CPU was executing at the time, which tends to be some bit of FreeRTOS in my case. The way to solve this has been worked out and documented but clearly ST don't want to do it.

[DavidAlfa]

Documented where?

[peter-h]

I believe there is a post somewhere here where somebody found a way
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/td-p/246693/page/9

Basically it involves putting a bit of code into the debugger interface so that when the breakpoint (which can be a Stop i.e. not necessarily an explicit user BP) is taken, it checks whether there is a user breakpoint at that address and, if not, it carries on. Or some variation of that... the inner workings of Eclipse (as modified by ST) and the debugger interface are a mystery to me.

[peter-h]

ST may have done something to the random file opening issue
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/m-p/633716/highlight/true#M23914

However I have forgotten the exact circumstances under which it was a really bad problem

[peter-h]

Cube IDE is now v15. They changed the compiler etc version, and the generated code changes... gone from 483,332 bytes to 482,308 bytes! So (-Og) 1k less code



Sometimes a new GCC version changes the meaning of compiler/linker command line switches, but not this time, at least not for my project [NOTE at this point I did not test code execution; I just did a Build with ctrl-b]

Well, they broke the STLINK V3 debugger. Cube v15 offers up upgrade the debugger firmware and trashes it.

Encountered Error when opening C:\ST\STM32CubeIDE_1.13.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.200.202311302303\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer

and then



Does anyone know what this is? I now have two dead development systems and two dead targets which don't run even if the software is loaded using the ST Utility.

That "missing" ...CLI.exe file is in the right place, with the correct case too.

Update: downgrading to Cube 1.14.2 runs ok. The STLINK V3 upgraded using the firmware from Cube v1.15.0 also runs ok with Cube 1.14.2, which is just as well!

I am sure that GCC tools v12 break the code in some subtle way. Even loading the software using ST Utility produces a dead target. I will probably not spend much time on this since a) I do not need to just blindly keep upgrading Cube (it's actually a stupid idea to make work for yourself, since every tool update ought to need regression testing of the product) and b) I can't debug the target since the debugger also does not work with Cube v1.15!

[DavidAlfa]

Don't update, It always breaks things.
Instead, uninstall old, install new, delete workspace .metadata folder.