Is ST Cube IDE a piece of buggy crap?

[peter-h]

I did both (suspecting as you suggest) but the same result.

Yes on a proper installation I always uninstall (both Cube and the driver), delete c:\ST, and download a fresh .exe (1GB now ).

There is something funny about the GCC v12 generated code, because my target dies when I do a firmware update over http (the target has an http server for this), or using ST Utility (which runs via the STLINK debugger). The most direct method, Cube IDE -> STLINK debugger, does not work, as described. There are hundreds of config options in Cube and the tools and the new install failing to pick these up correctly (from the project files) could bugger it up.

There is however one thing which I changed together with going to Cube v1.15: I removed the call to __libc_init_array() as described here
https://www.eevblog.com/forum/microcontrollers/mcu-programming-101-writeup/msg5402906/#msg5402906
My project does not use C++ so this should be safe. However I am not 100.000% sure; I have some note in the project that __libc_init_array() is also needed for the libc printf(). Maybe I will revisit this one day. But if ST cocked-up there will be Cube IDE 1.15.1 out soon

I don't have the sources to the __libc_init_array() in the libc distributed by ST. But e.g. this
https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32
is ambiguous about __libc_init_array().

Update: with the libc stuff put back in, Cube v1.15.0 still a) fails on the debugger and b) the compiled code does not run even with the libc put back in.

I am going to leave the libc init call in there. Google hits tend to suggest is applies to C also, not just C++, and is used to set up some statics in some libc functions. Entirely possible since ST do not distribute libc.a in source form, and some of the functions e.g. malloc() had to be mutexed for my project. This is not worth the risk. I have started various threads in the past on the mystery of libc.a and some people found probable sources, but nothing definite.

[DavidAlfa]

Doesn't __libc_init_array initialize all system variables? 

[radiolistener]

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.

Yeah, Cube is a kind of library of code snippets which helps to write initialization code with no need to read a bunch of datasheet and manuals, but then you're adapt generated code snippet for your needs

I even think that it will be better to not generate entire project, but to allow user to generate a short code snippet for specific peripherals with different options and then just copy-paste it into your project

[peter-h]

Doesn't __libc_init_array initialize all system variables?

Not according to about 80% of google hits (which say C++ only, like wek in the linked thread) and the other 20% are non-specific (meaning it could be C also).

As I said, I strongly suspect the ST supplied libc.a does use this function to set up other stuff like static variables, but the time I spent messing with this was c. 2021, and my final decision back then was to leave it in there.

If you have a reference, I am all ears

I have just stepped through the code (has to be done with Cube switched to displaying assembler) and there is very little code being run.

I also posted the Q here
https://community.st.com/t5/stm32cubeide-mcus/the-mysterious-libc-init-array-in-cube-ide-is-it-only-for-c/m-p/652829#M25352
and got the usual vague reply.

I even think that it will be better to not generate entire project, but to allow user to generate a short code snippet for specific peripherals with different options and then just copy-paste it into your project

Well, yes, thera are two schools of thought on this. The experts say you should read the 2000 page RM (the bits which your project uses, plus other stuff because the code won't actually run if you do just that) while others use Cube MX to generate chunks of code for the project (and these people then get stuck after they got the LED flashing and end up posting "please help" all over the internet). I think the best approach is halfway: use MX to generate bits of code, see what it generated, and then edit it to do what you actually want, only.

[tru]

I don't have the sources to the __libc_init_array() in the libc distributed by ST. But e.g. this
https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32
is ambiguous about __libc_init_array().

Update: with the libc stuff put back in, Cube v1.15.0 still a) fails on the debugger and b) the compiled code does not run even with the libc put back in.

I am going to leave the libc init call in there. Google hits tend to suggest is applies to C also, not just C++, and is used to set up some statics in some libc functions. Entirely possible since ST do not distribute libc.a in source form, and some of the functions e.g. malloc() had to be mutexed for my project. This is not worth the risk. I have started various threads in the past on the mystery of libc.a and some people found probable sources, but nothing definite.

I believe that __libc_init_array() is only for calling the array of C++ constructors - which will be empty if your program is just C.  If ST is providing minimal functions using the newlib library, then the sources are available: https://sourceware.org/newlib/

For easier viewing on github, a google search of an unofficial newlib mirror, the function is here:
https://github.com/bminor/newlib/blob/master/newlib/libc/misc/init.c

[peter-h]

1) See here
https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg4363183/#msg4363183
for a discussion about the libc.a sources. This is extremely tricky. Sure, one can find some src on github etc... For example which printf() source was used??

2) Stepping through the __libc_init_array(), in assembler of course, one can see a loop taken about 3 times, so it isn't completely empty.

From my project notes, from c. 2021:

The likely original printf source in libc.a was
https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=6a198e2c657e8cf44b720c8bec76b1121921a42d;hb=HEAD#l866

Probable scanf sources

The likely scanf source in libc.a is
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/sprintf.c;h=be66ec6f5d73589e5147afeb7634b9de0daba09d;hb=HEAD
or
https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/stdio;h=0f5e4dd0dc465029d0b6c0a5d03fc2cc70e8df87;hb=HEAD
and that does use malloc but it’s not clear if the one in the Cube lib uses it. A breakpoint on _sbrk is not hit.

Other Newlib sources can be found here
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Probable heap sources

If looking for heap source code, this may help:
https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/
Note that our libc.a contains the heap code also.

The current heap code seems to allocate 4 bytes for each block, and sometimes 4 more bytes are added for alignment. See here
https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/msg4835657/#msg4835657

However the suggested candidate source code
https://github.com/devkitPro/newlib/blob/master/newlib/libc/stdlib/_mallocr.c
appears to not be the one (unless fixed since) because the problem described here
https://stackoverflow.com/questions/39088598/malloc-in-newlib-does-it-waste-memory-after-one-big-failure-allocation/76138157#76138157
(which does refer to the above source) is not present in ours. A malloc of a block larger than heap space fails correctly but subsequent reduced mallocs work fine.

A more likely candidate sourcecode is the “nano”
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=13b72c99ffd7007b53c2e3270a56da237857742a;hb=HEAD

but it probably is not, or not quite
https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/msg4845821/#msg4845821

[peter-h]

Cube 1.15.0 emits this warning
Description   Resource   Path   Location   Type
xxxx.elf has a LOAD segment with RWX permissions

But it happened only once. Others have seen it
https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-15-0-elf-has-a-load-segment-with-rwx-permissions/td-p/652335
and the solution is pretty complicated.

Anyway 1.15.0 is unusable.

Here is the function



and



The code from 306: to 31e: is executed twice.

The whole thing is weird with 1.15.0. The debugger fails as posted above. And when that fails, ST Utility, while programming the chip OK, also fails to deliver a running target, suggesting that code generated by 1.15.0 is faulty in some way. But when I reinstall 1.14.1 everything immediately works, including the ST Utility loading working code. And obviously without a working debugger there is no way to track down the problem.

[DavidAlfa]

To remove that warning just add "--no-warn-rwx-segments" and "--no-warn-execstack" to the linker flags under "Miscellaneous" tab.

Source: https://lore.kernel.org/all/20220802083023.1488625-1-joel@jms.id.au/T/

[SiliconWizard]

The linker RWX warning appeared in more recent versions of binutils and is likely to be triggered by most linker scripts for ARM Cortex-M targets.
Adding the "--no-warn-rwx-segments" option to the linker is enough to silence it.
The rationale for this warning is rather simple, but it's pretty annoying for the usual "embedded" targets.

[peter-h]

This started with GCC 12.

Does it affect code generation?

I never had a running target with any ex-GCC12 binary, but could not debug it because Cube IDE 1.15.0 fails on the debugger

[SiliconWizard]

No, it doesn't affect code generation. It's only a warning from the linker.
Here are more details about these warnings: https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments

[peter-h]

Executable stacks... !!

But I wonder where GCC gets the idea that my stack is executable. In reality it is because it is RAM and STM32 does not have exec protection on selected RAM areas (AFAIK). But I am not declaring the stack in the linkfile. It is defined by loading SP and making sure there is room below it. And in the RTOS environment, each task has its own stack, quite a small one because there are many of these.

[bson]

Doesn't __libc_init_array initialize all system variables?

Not according to about 80% of google hits (which say C++ only, like wek in the linked thread) and the other 20% are non-specific (meaning it could be C also).

It runs constructors.  For C++ this obviously means any static object that has a constructor gets it run at this stage.  But any C function can be annotated with __attribute__((constructor)) - this will cause a call to this function to be added to the constructor list.  It's not quite the same as C++ (where ctor's are called with a reference to what's to be initialized).  You need to be careful not to omit these, because they are used by libraries.  Take a look at for example libssp, the stack protector support library: https://github.com/gcc-mirror/gcc/blob/7a5a4a4467b2e18ff4fe24f565e120280d3e6ba7/libssp/ssp.c#L72 - just a quick example that's probably never used in bare metal type scenarios, just pulled it up to illustrate it's actually used.
While it's not frequently used, assuming it's not present is a good way to introduce incredibly subtle bugs caused by uninitialized data deep in some compiler support library...  It's also a moving target, so would need to be reverified (through manual inspection) every time the tools are changed.  I'd just leave the ctor init list in place.  (If your code never exits, which firmware typically doesn't, the destructor table can be completely omitted, including the code sections it refers to, assuming section-per-function code generation.)

[tru]

Sorry, I know is slightly offtopic and havn't had time to install ST Cube IDE 1.15.0 just yet.
I'm still on 1.13.1.

I've just tried a breakpoint on a led blink sample with the Nucelo 144 STM32H753ZI dev board.  In mine, the same code is only executed once.

Line 2400c065 is a jump to the empty _init() stub function, which simply push/pop (save and restore some registers), executes a nop instruction and then returns.

Lines 2400c07d to 2400c083 corresponds to reading the .init_array list of C++ constructors.  The newlib library added in a frame_dummy() function to the init_array list and that is what blx r3 jumps to.  The execution goes in and shortly returns, and since there are no constructors the loop ends.

[tru]

I forgot to mention, you can see that the .init_array section is 4B (bytes), which means there is only the one function pointer in the list, which is the frame_dummy().

[SiliconWizard]

Executable stacks... !!

This is what happens when one only reads titles or just the beginning of articles.
It deals with both executable stacks and executable segments in different sections of the article. For your case, read the section about executable segments.

[newbrain]

STM32 does not have exec protection on selected RAM areas (AFAIK)

Many STM32 (and other vendors'MCUs) have an MPU, even the cortex-m0+ ones.
E.g: https://www.st.com/resource/en/datasheet/stm32g071c8.pdf

Depending on core type and vendor implementation, it can have either 8 or 16 memory areas, from 32 bytes to 4GiB (plus the default optional background attributes) and control RW privileges, memory ordering,  caching and executable permissions.

FreeRTOS can be MPU aware: https://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html

[peter-h]

OK, so to summarise, if you declare a function in C using the Constructor attribute (which I have never heard of but potentially anybody can do this) that adds that function to some list of function addresses (the list being stored "somewhere" in RAM) and then calling __libc_init_array() calls every function address in that list, once.

Yeah, potentially useful but also why would anyone do something so relatively opaque? If you need to initialise a UART you just call init_uart() or whatever. Then you know exactly when that happens, rather than using some indirect method where you don't actually know the order in which the list is processed. Presumably the order is according to when the compiler comes across the Constructor attribute, which could bite you in the bum big-time. A lot of hardware initialisation is order-critical.

Many STM32 (and other vendors'MCUs) have an MPU, even the cortex-m0+ ones.

OK; many thanks. My 32F417 does have an MPU but with just 8 areas whereas I have some 20 RTOS tasks. Still, unless your product has an LCD or some accessible error log, there is no way to report access violations It is the old embedded problem, around since for ever, with stuff like division by zero traps.

It could be useful. In my system I can display RTOS stack usage with a graphical utility (custom written for me by a guy on Freelancer) which shows unused parts of stacks, so I can check, over time, the max usage.

[newbrain]

OK; many thanks. My 32F417 does have an MPU but with just 8 areas whereas I have some 20 RTOS tasks.

Have you read the linked FreeRTOS article?
Protecting each task individually is not really advisable (or even possible without pointless contortions).

I use the MPU to prevent caching for some DMA buffers, while I am at it I also make the ITCM and external QSPI not writable, and all data RAM areas not executable, so FreeRTOS stacks and heap (and all the rest) are 'protected'.
This happens after static variables (optional) and ITCM (mandatory) are initialized by the startup code.

This helps not for security, given the application, rather to give a MemFault error in (some) case of a rogue function or data pointer.

Not that the linker is aware of this, though.

As for the "constructor" attribute, it might be useful to initialize HW needed before main starts, like e.g. external memories.
I have my own startup code, so I don't really have an use it, but it comes handy if you want to use the standard one.
OTOH the vendor/CMSIS standard startup code declares a SystemInit() weak function to put your stuff into.

[peter-h]

Yes; thank you. Unfortunately I am on FR V10.0.1. But I get the drift. You reconfig the MPU as you switch tasks, so for protection in the RTOS task context you just need one protected block.

It may also be possible to aggregate all FR task stacks into one block which could be exec-protected in one go?

Protecting flash address 0 (well 0x8000000 or whatever) from writing might yield interesting results in many running products

The general stack (used by ISRs, startup, etc) could be protected. One day I might give this a go. I have some personal hobby applications for this product and can play then

Yes I can now see the intention behind systeminit() etc. I re-hashed that ex-cube-mx code greatly, discovering e.g. that some of the init was duplicated. No surprise that nobody noticed The project was started c. 2016 by a 0.5 day a week colleague, was on the back burner for years while he was doing stuff like setting up a Magento online shop, etc, and he used MX to generate the original code. Predictably it was a right mess.

[eutectique]

OK, so to summarise, if you declare a function in C using the Constructor attribute (which I have never heard of but potentially anybody can do this) that adds that function to some list of function addresses (the list being stored "somewhere" in RAM) and then calling __libc_init_array() calls every function address in that list, once.

Correct. The implementation of __libc_init_array() can be easily found and scrutinised: https://github.com/bminor/newlib/blob/master/newlib/libc/misc/init.c

Yeah, potentially useful but also why would anyone do something so relatively opaque?

This mechanism is mostly used by libraries, Newlib being one of them. You link the library into your binary, and the (opaque) library stuff is being initialised automagically, before your main() is called. You don't need neither to remember nor to know that some (opaque) library feature needs initialisation. Who ever reads the boring implementation notes of snprintf() or rand()?

If you need to initialise a UART you just call init_uart() or whatever. Then you know exactly when that happens, rather than using some indirect method where you don't actually know the order in which the list is processed. Presumably the order is according to when the compiler comes across the Constructor attribute, which could bite you in the bum big-time. A lot of hardware initialisation is order-critical.

Correct. Sane design should not use gcc constructors to initialise hardware, for exactly these reasons.

[peter-h]

Thank you. That all makes sense, and explains why I have project notes from 2021 saying about putting this back in because weird stuff was happening, even though 80% of the internet says it is C++ only

What is the difference between the 1st and the 2nd loop?

Code: [Select]

  count = __preinit_array_end - __preinit_array_start;
  for (i = 0; i < count; i++)
    __preinit_array_start[i] ();

#ifdef _HAVE_INIT_FINI
  _init ();
#endif

  count = __init_array_end - __init_array_start;
  for (i = 0; i < count; i++)
    __init_array_start[i] ();
IOW, what is the difference between preinit_array and init_array? I've had a dig around but can't see anything. Well, apart from finding yet more posts from experts on the ST forum saying this is only C++

The fini_array should never be called in an embedded system.

[eutectique]

... even though 80% of the internet says it is C++ only

Sounds like a Pavlov's dog reaction: "constructor" --> "C++"

IOW, what is the difference between preinit_array and init_array? I've had a dig around but can't see anything.

Newlib, in its embeddable flashable static-library variant, originates from bigger systems where shared libraries are loaded into RAM and linked dynamically with an executable object in RAM. Some parts of that shared libraries might require early initialisation just after mapping but before the main initialisation happens. Consider preinit_array a rudiment, it doesn't play any special (or useful) role in embedded systems.

[peter-h]

That suggests that the preinit_array list is populated with an attribute other than constructor?

[eutectique]

Having __attribute__((preconstructor)) would be too easy, life is struggle!

preinit_array should be populated manually.