Is ST Cube IDE a piece of buggy crap?

[newbrain]

(some were for arm32 chips with DSP instructions, etc)

DSP extensions are optional for Cortex-M4, but I would be hard pressed to find an M4 MPU without them.
STM32F4 family for sure has them.

[peter-h]

OK. I can't remember the exact process I used. I posted about it e.g. here
https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/

Searching that c:\st\ tree yields 66 items - see attached screenshot for a part. The one I picked is 1033kb.

Then, based on the project properties settings Cube selects one of these and copies the appropriate one to a more local location, which right now I can't find. But with a lot of work I eliminated most of the candidates; most of them won't even link, due to the .elf file not compatible with something (as usual, loads of google hits). In the end I had 2 options: v7 and v8. Actually you can see them in the screenshot below. So I went for the v8 file. Then I used a linker config to hard-select my copy of the file and to get the new printf to override the relevant part of it, as described in the above link.

Everything works and is rock solid, runnin 24/7 with a fully loaded RTOS. I also traced through the printf code to make sure it really is running what it is supposed to be.

AFAICT none of this is documented anywhere. As given this code is PD, why didn't ST provide the sources, and a .h file with a load of #defines in it? It would have been a lot easier than doing 66 compilations, each with different CPU etc options. The one Cube supports the whole range of ST CPUs, hence so many libc.a files.

Maybe a paid IDE (Keil?) is better supported, but ST Cube was chosen because it is free and that was a key criterion because in some cases the customer will be writing his own modules, so I can just point them to ST Cube and give them setup instructions for importing a sample project. Years ago I did another somewhat similar product which had a £400+ compiler kit but today the customer acceptance of that is zero.

[newbrain]

STM32F4xx are Cortex-M4 with SP floating point and DSP.

The core version is Armv7E-M, this is usually reflected in the library path, like the hard or soft floating point bindings (also a project choice).
ArmV8-M is for Cortex-M23,33 etc.

[peter-h]

Dammit; the mystery is back

I managed to get a screenshot of the tails of the directories which hold the libc.a files - attached.

Would I be right that the right one is the highlighted one?

Actually probably, based on v7em, it would be the 1030k one, 2nd from bottom. Standard C library, not nano, hardware floats.

Many thanks.

EDIT: 2nd, bigger, screenshot attached.

[newbrain]

In the second screenshot, if you are using soft FP, it's the highlighted one.

For hard FP it's the one in the 2nd row above the highlighted one.

In both cases, the toolchain knows what to choose, based on project settings; they should be similar to those in the screenshot below.
(From MCUxpresso (barf), for an iMX RT1062 based project, but probably almost the same).

[peter-h]

I don't have an Architecture item on mine.

The 32F417 does have hardware floats (not double floats).

So it looks like the v7 e m fp. 1030k.

[newbrain]

I don't have an Architecture item on mine.

The 32F417 does have hardware floats (not double floats).

So it looks like the v7 em fp. 1030k.

Ah crap...at work now, but maybe I''l put the STM32CubeIDE in a VM tonight and check where this is on that (other) crap pile.

Yes the MCU does have HW SP FP, but it's up to your choice to compile towards a hard or soft ABI.

[newbrain]

WTF, I went and did it, instead of coffee (the effects of eclipse on my blood pressure is probably worse).

It's in MCU settings, still in the property page for the project, right where you select newlib vs. newlib-nano!

[peter-h]

OK



That means that this should be the right file



Thank you very much for your help.

EDIT: @westfw I have had a look through the link you posted. I don't think the writer actually did any of that himself. As he says, one can replace the printf family with any number of the PD printfs (like the one I am using now) but the problem is that this stuff is in libc.a which contains a load of other stuff - basically the whole stdio and lots of other stuff. None of these - as supplied in the ST libc.a - are "weak" so it can't be done simply. Also I have not found a way to "edit" that library. Well, nobody else has posted a method. Even deleting modules from it doesn't work.

[eutectique]

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

You can see who is calling what in the cross-reference section of the mapfile. Here is the example from my current project at hands:

Code: [Select]

Cross Reference Table

Symbol    File
malloc    /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-malloc.o)
          /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(eh_alloc.o)
          /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(new_op.o)
          /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-svfiscanf.o)
          /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-svfscanf.o)
          /home/CENSORED/libCENSORED.a(hash.o)
          /home/CENSORED/libCENSORED.a(lfs.o)
          ...

You can also see the full path of the library object, with thumb/v7e-m+fp/hard in it.

I am using CLion and Makefiles, so the corresponding line for gcc looks like:

LDFLAGS += -Wl,-Map,$(MAPFILE),--cref

Don't know how to do it in Cube.

[westfw]

Do you still use the soft-float libraries to get double support for chips that only have single precision hardware?

[peter-h]

That cross ref was a great idea - many thanks



The result is interesting

Code: [Select]

_malloc_r                                         ../LIBC/LIBCW\libc-weakened.a(lib_a-mallocr.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-signal.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-makebuf.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-fvwrite.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-svfiprintf.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-findfp.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-ungetc.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-svfprintf.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-reallocr.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-malloc.o)
                                                  ../LIBC/LIBCW\libc-weakened.a(lib_a-callocr.o)
_malloc_trim_r                                    ../LIBC/LIBCW\libc-weakened.a(lib_a-freer.o)

I see svfprintf has sneaked through my printf replacement. But nothing uses it; it's hard enough to find any examples on google.

You can also see the full path of the library object

I now remember that was how I found which libc.a was being used. From the .map file. Then I copied over the wrong one

Do you still use the soft-float libraries to get double support for chips that only have single precision hardware?

I think that is how it works, yes. Doubles are pretty fast if you have hardware floats.

[eutectique]

For v7e-m+fp architecture, the compiler generates single-precision instructions, and calls to double precision functions:

Code: [Select]

  1556 012a B7EE007A             vmov.f32        s14, #1.0e+0
  1557 012e 77EE677A             vsub.f32        s15, s14, s15
  1558 0132 17EE900A             vmov            r0, s15
  1559 0136 FFF7FEFF             bl              __aeabi_f2d


 Then the libgcc.a library is linked automagically to resolve the symbols:

Code: [Select]

__aeabi_f2d    /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_drsub  /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_dsub   /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_ddiv   /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_muldivdf3.o)
__aeabi_dmul   /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_muldivdf3.o)
...


[eutectique]

... one can replace the printf family with any number of the PD printfs (like the one I am using now) but the problem is that this stuff is in libc.a which contains a load of other stuff - basically the whole stdio and lots of other stuff. None of these - as supplied in the ST libc.a - are "weak" so it can't be done simply.

I have created my implementation of snprintf() in syscalls.c file, built it, and ran in Ozone. My function is get called, instead of one in libc.a :


Here are the corresponding map file lines:

Code: [Select]

.text.snprintf
                0x000000000800dc4c        0x8 /home/[CENSORED]/objs/syscalls.o
                0x000000000800dc4c                snprintf


And this is the map file whith libc function:

Code: [Select]

.text.snprintf
                0x0000000008050388       0x88 /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-snprintf.o)
                0x0000000008050388                snprintf


Are you trying to achieve something similar?

EDIT: syscalls.c lives in the same directory with main.c and contains the system calls which otherwise will be pulled from libc, like _open(), _close(), _lstat(), you name it.

[peter-h]

Yes; this is done and working. So if you call say snprintf then you end up in the one from https://github.com/mpaland/printf which overrides the one in the old newlib libc.a.

https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/

It's all working now. Solved. Took me about a week to work out how.

My complaint was why ST supplied a library which is not thread-safe (while also supplying an ST port of FreeRTOS) but which can't be made thread-safe without a load of acrobatics which I don't believe many people will be doing.

But I am far from the only one complaining about the ST Cube IDE. There is a guy in the ST forum (which has so many posts, mostly unanswered, it is practically useless) who spends half his time slagging off ST for supplying so much crap code. A lot of stuff which is really complicated, so you do need vendor-supplied libs to get going in a reasonable timeframe, e.g. ETH and USB, is only barely working.

[westfw]

Doubles are pretty fast if you have hardware floats.

Really?  I thought I noticed that having single-precision HW doesn't help at all for doubles...

[peter-h]

I was going to run some timings but can't now because I replaced the standard C printf lib

Logically you must be right. I can't remember where I read that single float hardware helps with doubles. A 32 bit barrel shifter, multiply, divide, etc, must help with doubles though. In the Z80 days they would be incredibly slow - of the order of 10ms for a double IEEE FP add or mult (IAR compiler), with a sscanf of %f taking 100ms.

[nctnico]

I was going to run some timings but can't now because I replaced the standard C printf lib

Logically you must be right. I can't remember where I read that single float hardware helps with doubles. A 32 bit barrel shifter, multiply, divide, etc, must help with doubles though. In the Z80 days they would be incredibly slow - of the order of 10ms for a double IEEE FP add or mult (IAR compiler), with a sscanf of %f taking 100ms.

That sounds awfully slow even for a Z80. It would mean that the Z80 would need to execute in the order of 10k instructions for an FP addition. I suspect the soft floating point libraries wheren't very optimised.

[peter-h]

I thought the same and found that IAR's sscanf was taking the string, say 123456.78, going to the end of it, adding the digits up (float add) multiplying each by 10 (float mult) and so on until it got to the first one. Then it would do a divide by 100

All in IEEE floats.

This was used in HPGL data parsing, with the above data format always, and I didn't even bother trying to tweak it; I just rewrote it in Z180 asm, in about an hour, for a 100-1000x speedup.

The arm32 is a different world. None of this stuff is at all relevant now. But it is possible that a software printf (which in newlib will be Double) is quite slow, unless the CPU has hardware doubles. All the more reason for not using a printf which uses Double. It has practically no applications in embedded.

[nctnico]

I'm using printf with doubles quite a lot in several projects to implement text based protocols between various devices. The soft-floating point libraries that come with GCC are well optimised. Unless you are under severe time constraints (several tens of us), I wouldn't bother avoiding floating point even if the device doesn't have an FPU. I have used soft-floating point doubles in telecom audio processing applications as well. In many cases it is just not worth the trouble of using fixed point arithmetic.

[SiliconWizard]

Using printf() per se can be problematic enough (see other thread), but scanf() functions? Eek. Please don't use them.

[nctnico]

Using printf() per se can be problematic enough (see other thread), but scanf() functions? Eek. Please don't use them.

scanf is iffy indeed because you don't always know the input. With checks added, the atoX and strtoXX functions work well. Printf OTOH is perfectly controllable because there is no (uncontrolled) external input. Only real mistake to make is feeding the wrong type into printf that causes it to lose track of the parameters. But in the end that is a programmer's mistake.

[peter-h]

This mostly comes down to programmer productivity.

Given enough time, you could do all input with atoi atol etc, atof is for wimps who didn't scale their values carefully, and you could do all output with itoa, ltoa, ftoa is for wimps who didn't scale their values carefully, etc. But then you spend a few hours instead of a few minutes. You just need to understand the limitations, and this non thread safe newlib printf stuff is one of these (and in a nasty non obvious way too, courtesy of STM). Given enough time you can write everything in assembler - as I have done for some decades - but even if you want to pay for it, your recruitment options these days will shrink by 99%.

Times change. The H8/323 would not be able to host a double IEEE printf and have room for any other code. It cost £9 (10k) over most of its 25 year production run. The 32F417 cost £5 (500) and with 1MB has basically no code space limits. For another £2 you can have 2MB. Most projects are RAM-limited. My point is that nowadays there is no point in using smaller chips unless it is really cost-sensitive. A high volume OEM will be getting the 32F417 for £2.

[peter-h]

I may have found a reliable way to make Cube display the missing Build Analyser page:

Go to whichever directory in your project holds the .map file and click on it.

The alternative is to build the project twice.

[MWP]

I may have found a reliable way to make Cube display the missing Build Analyser page:
Go to whichever directory in your project holds the .map file and click on it.
The alternative is to build the project twice.

Try right clicking on the project and doing "refresh", or hit F5.
It'll be because Eclipse isn't aware the map file exists yet.