Is ST Cube IDE a piece of buggy crap?

[dietert1]

If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different. It may be tempting to save the work and try using the same Cube project for different MCUs, yet it's an error and results are not guaranteed, even for somewhat similar MCUs. Those devices are complex.

Regards, Dieter

[westfw]

If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different.

That's rather awful, especially if there's no way to clearly delineate the application and the "system part."For instance, I maintain an AVR bootloader (Optiboot) that can be compiled for literally dozens of different chips without being overly cluttered with per-chip dependencies.  (It uses manually created source and Makefile(s); this sort of multi-target solution doesn't fit well into other IDEs (like "Atmel Studio" or "MPLabX"), either.

[peter-h]

There is a legitimate case for being able to buy a 32F437 (because you can't get the 32F417, for example) and just drop it in in production.

And this works (the only known diff is around Vbat monitoring using the ADC).

What I am saying is that Cube might do some funny stuff - evidently it uses the CPU ID (which it reads back via SWD) and if this doesn't match the Cube project settings, it breaks something, at least in the memory display.

That said, it took me a year to notice the CPU markings so within the 32F417 memory ranges, Cube works on a 32F437 ok. It's just that if you do something like a power-up RAM test, and then use that to size your heap size, etc, that will work, but you will have some fun doing debugging on the extra memory.

[newbrain]

If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different.

That's rather awful, especially if there's no way to clearly delineate the application and the "system part."For instance, I maintain an AVR bootloader (Optiboot) that can be compiled for literally dozens of different chips without being overly cluttered with per-chip dependencies.  (It uses manually created source and Makefile(s); this sort of multi-target solution doesn't fit well into other IDEs (like "Atmel Studio" or "MPLabX"), either.

I don't use the ST Cube IDE, due to its Eclipse descent,  but I use sometimes the ST Cube MX (i.e. the stand alone code generator).
There is a way to migrate a project to a different MCU keeping the user code (the one between the /* USER CODE START nnn */ comments) - it works resonably well if you move in the same family, I changed from a STM32F072 to a STM32F042 with no issue, and IIRC provides a good amount of helpful diagnostics.

So, yes: different MCUs need separate projects.

[peter-h]

One bizzare behaviour is how you can place a breakpoint on a line of code, and the code gets removed because the compiler decided that it is unreferenced or unreachable, and very funny things happen.

It can take quite a while to spot this.

Could it have been programmatically detected?

[ataradov]

What funny things?

The correspondence of the source code and assembly becomes obvious after compilation is done and the final binary with the debug information is available. Often IDEs don't parse the binary until debug session is started. And when it is started and the line is not available in the code, I've seen seen different behaviour - just mark the breakpoint as disabled, move to the next available line.

Usually breakpoints are treated in two separate ways - one is the desired set and another one is the actually possible set. There are many ways setting a breakpoint can fail. One of them is the code optimization. But there may also be not enough hardware breakpoint comparator, or your function may be located in SRAM. So, debuggers typically just treat your set breakpoints as a best desired set, and check what can be done in practice once the debug session is started.

[peter-h]

That sounds about right

The best one recently was setting a breakpoint on an ISR callback. The ISR should have never been called but I had a suspicion it was because the interrupts were left enabled. Old code done 2-3 years ago, not by me. The breakpoint was never taken (in days) but the reason was that the ISR itself didn't exist (because no vector table entry pointed at it anymore) so got optimised away, so the callback got optimised away, but the breakpoint was shown perfectly

[ataradov]

Don't rely on the IDE. I don't know how many times you need to run into issues until you figure it out. Set breakpoints in disassembly where you control where it is set and can notice that some code is missing.

[ataradov]

This would require close coupling of the compiler and the IDE at the very least. And working on individual functions would require some sort of a way to tell the compiler what to do on a per-function basis.

It is possible to do, of course, but time investment probably not worth it.

godbolt-like view should not be too hard to implement and may be a good starting point. And probably the limit of what is actually useful in a day to day life.

And yes, disassembly view in most IDEs ranges from completely hopeless to somewhat usable at best. I have not seen one that I could point as standing out from the rest.

[peter-h]

Set breakpoints in disassembly where you control where it is set and can notice that some code is missing.

That would avoid the issue but clearly this is not meant to be a requirement. It is a bit like telling somebody to never change directly from 3rd gear to 5th gear because the engine might blow up

It is stupid software, to fail to detect that there is no code at that address. But clearly the IDE source code display has no idea that the displayed source has no relation to what was actually left, after optimisation.

A good Q might be whether using -O0 (no optimisation) stops removal of unreachable code.

[ataradov]

It is stupid software, to fail to detect that there is no code at that address.

If IDE would only allow to set the breakpoints on reachable code, then you won't be able top set a breakpoint until you recompile everything. And if you make a temporary change that eliminates some code, your breakpoints would be gone.

Also, debug information is not perfect, and the breakpoint may still not work, even if the code is technically there. You may not like it, but using assembly is unavoidable in some cases.

A good Q might be whether using -O0 (no optimisation) stops removal of unreachable code.

Not guaranteed, depends on the compiler and other settings. There is no guarantee that a line of code would correspond to anything.

[harerod]

Hint: CubeIDE projects remember breakpoints. A project may contain breakpoints that have no longer any representation in code. In the "Run"-menu you will find "Remove all Breakpoints" to get a clean slate.

[peter-h]

This is interesting stuff.

The other stupid behaviour is that if say you have some source

line1
line2
line3
line4
line5 - breakpoint here

and you insert a line before line2, the breakpoint moves to line4 It stays in the same line # in the source file.

[peter-h]

Not sure if I've posted this before.
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/

and
https://www.eevblog.com/forum/microcontrollers/32f4-hard-fault-trap-how-to-track-this-down/

Quite relevant to ST Cube users. The standard C library libc.a is a load of crap. It is not thread safe so it uses mutexes to protect itself. It also uses the heap (for long and float output) and uses more (recursive) mutexes to protect malloc and free. But ... wait for it ... the mutex calls are empty stubs.

So your project will crash every once in a while

I discovered this by accident when tracing the asm code (no source is supplied).

It looks like sscanf (in the same lib) is not as bad; I see no heap calls and no mutex references in the disassembly, and no breakpoint hits on _sbrk so it isn't doing a normal malloc(). And I am doing some %f parsing.

[westfw]

Quite relevant to ST Cube users. The standard C library libc.a is a load of crap.

Does the ST package not use newlib (like nearly everyone else) ?

[ataradov]

It does. peter-h just likes to call things that don't absolutely perfectly fit his use case crap.

[newbrain]

Quite relevant to ST Cube users. The standard C library libc.a is a load of crap.

Does the ST package not use newlib (like nearly everyone else) ?

IIRC, it allows to choose from newlib and newlib-nano, at least.
NXP also include their "redlib".

I generally use picolibc though.

[peter-h]

That personal attack is BS and not necessary. If you think sending out an IDE with this hacked garbage
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/
is acceptable then you need to get a life.

Cube seems to come with a newlib libc.a but no sources. So anyone using an RTOS (which ST do a port of too) is in for a whole load of fun and games. It crashes only once every few days, which is ok.

[ataradov]

NewLib source are available. But you don't need the sources to use the binary library. IThe mutex functions are dummy stubs, but they are usually weakly linked. If you define your own implementation, it would be used instead. This is how it is supposed to be used.

None of that is crashes if you know how to use it properly. All those components are used in the industry without any issues.

[peter-h]

but they are usually weakly linked.

They are not, but if you didn't read what I posted you won't know.

I did solve it eventually, and posted the details to help others.

NewLib source are available.

Perhaps you could be helpful and point me to these? If you read my posts you would know that someone did locate a likely source for the ST Cube printf family (an ex BSD unix 1990 job with some C99 stuff) but nobody has yet found the scanf family, which I was interested in to see if it uses the heap (which the printf does for longs and floats, according to disassembly).

None of that is crashes if you know how to use it properly

Not everybody was born knowing everything. I had to learn what I know. Takes time...

it allows to choose from newlib and newlib-nano, at least.

Not in an obvious way. I posted the screenshots. But to save you looking it up (which few want to do, while being quick to criticise), for example selecting this



gives you the "1990 ex BSD" newlib regardless of whether those checkboxes are checked...

[westfw]

nobody has yet found the scanf family

Isn't that in the same place at https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/stdio;h=0f5e4dd0dc465029d0b6c0a5d03fc2cc70e8df87;hb=HEAD

[peter-h]

Thanks very much!

Bad news... malloc in here
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfscanf.c;h=cfeea987628b1bc5d78a5a7109ae2a47f31f3b89;hb=HEAD

Funny I didn't see that when debugging. Maybe a compile option, or maybe only with a specific scanf format.

[westfw]

Maybe a compile option

AFAIK, newlib has many compile options, as well as the assorted stubs that need to be set up correctly for a particular environment.  Perhaps many of your troubles are caused by using a newlib that has not been properly configured for your particular setup.
Maybe start here: https://hackaday.com/2021/07/19/the-newlib-embedded-c-standard-library-and-how-to-use-it/

[newbrain]

Not in an obvious way

Of course.
It is, after all, Eclipse.
A huge mound of user-hostile elephant dung which 2022 still has problems with a dark theme  .

I went to the trouble of installing the monster in a Windows sandbox, but it'll be gone after this post.

Those two check boxes will only have effect if you select the "Reduced" library - i.e. newlib-nano, as per the attached screenshot.

[peter-h]

Perhaps many of your troubles are caused by using a newlib that has not been properly configured for your particular setup.

For sure, but ST didn't supply the sources or any build data. What you get when you install Cube is a separate directory c:\st\all-kinds-of-stuff and in there are about 20 different libc.a versions which they precompiled. I spent many hours working out which one of these is selected for my project. Much of it was by elimination (some were for arm32 chips with DSP instructions, etc) and eventually I found the one file which was "standard C, no nano". You can tell if you have nano because int64 etc is not supported, also a sscanf can't read into a uint64_t (which I am doing). Then, as I posted on another thread, I made a permanent local copy of it, ran objcopy to weaken the entire lib, then I replaced the printf family with another one.

So far I see no evidence that malloc is getting called by the scanf family, but perhaps somebody with super C expertise can suggest which % formats might trigger that.

The modern thread-safe design is to use stack storage. If one uses statics one must have mutex calls within the code. These were originally empty stubs. If one uses the heap one must also have mutex calls to protect the heap, but these could be outside (around malloc and free). I have since secured the heap functions with mutexes, so the sscanf should be basically thread-safe even if it does use the heap, but (if calling sscanf from more than 1 RTOS task) one still gets fragmentation which will eventually crash the product.

Those two check boxes will only have effect if you select the "Reduced" library - i.e. newlib-nano, as per the attached screenshot.

Yes; I worked that out but it took more hours. I realised what was going on when I selected the nano options but my uint64_t sscanf still worked... Stupid interface design.

Anyway I wrote it all up so others don't have to do it all again.