Is ST Cube IDE a piece of buggy crap?

[NorthGuy]

But still if a compiler was to optimise x >> 1000, it should set x=0, not leave x unchanged.

In theory, the C compiler should generate a code to produce calculations in run time. It may do the calculation at the compile time, but this would be an optimization. When applying such optimization, the compiler must produce the same result as you would see without the optimization. So, on most processors you should expect x >> 1000 be the same as x >> 8.

However, when you write x >> 1000 it is a bug, because the operation is defined for right size of up to 31. So "x >> 1000" is undefined and therefore a bug, same as "x/0". You just don't do it. If you use it for some sort of special purpose, do it at your own risk.

On the other hand, even when allowed by the specification, the compiler shouldn't turn openly hostile. Compiler is a tool, not a cerberus for the C standard. Imagine, if you pressed a wrong button on a hand drill and it would jump and drill a hole in your eye to punish you for pressing a wrong button. Who would've used such a tool?

[SiliconWizard]

I think anybody who has to rely on standard implementations of undefined behaviour is going to - at best - product illegible code.

... just don't?

I think it's just hopeless at this point.

[SiliconWizard]

Pascal was a teaching language at universities. I had to do it, in the 1970s. It was useless for doing anything practical

As we discussed in another thread, this statement is just bullshit.

[nctnico]

Pascal was a teaching language at universities. I had to do it, in the 1970s. It was useless for doing anything practical

As we discussed in another thread, this statement is just bullshit.

I tend to agree with peter-h here. When you try to write real applications with Pascal you quickly run into problems because the structure is too rigid. Borland has tried hard to work around that by adding all kinds of C-isms but that ended up being a hot mess with 2 programming languages mashed together. Been there, done that and won't do it again.

[ataradov]

I used Turbo Pascal quite intensively for a lot of real applications with graphical UIs. I actually made first money making software in Pascal. It was fine and did not feel bad at all. Programming graphics in DOS 100% felt better than programming modern graphics.

But I did not care (and still don't) that there is a standard. To me Turbo Pascal was the standard. Same with C - I rely on GCC behaviour and extensions and don't care if something does not work in some obscure proprietary compiler. It is not may problem at all.

[NorthGuy]

Borland has tried hard to work around that by adding all kinds of C-isms but that ended up being a hot mess with 2 programming languages mashed together. Been there, done that and won't do it again.

I think it worked great. You could do most of the things you can do in C, but Pascal is more verbose. If you didn't use Pascal strings and alike, it was actually very close to C. Borland's Delphi had very fast and efficient compiler which produced very decent code. Delphi had very buggy and bloated libraries, but you were not obligated to use them. Later on the IDE became buggy as well. But at any rate Borland's Pascal was miles better than more canonical Think Pascal.

[Bassman59]

Someone else had fun here:
https://community.st.com/s/question/0D53W00001PudP1SAJ/issue-with-version-190

One person wrote, "My workaround is: uninstall CubeID 1.9, reinstall Version 1.8.0 and pull the Projects out of the backup - i LUCKILY made before upgrading to 1.9."

Another "engineer" not using revision control in 2022. Sheesh.

[Bassman59]

I did not get the comment about code legibility, especially in relation to UB? That depends a lot on the programmer, style guides and design can only do so much.

re: undefined behavior. To me this means "anything can happy." Maybe that shift will open up a black hole under Putin's feet, saving the world? Maybe it caused that bagel with lox I had on Friday to give me food poisoning? Which one of you guys gave me food poisoning?

*E.g, real story: friend came to me with "gcc in the new Ubuntu is broken" "fat chance, show me your code" "... a[j] = j++...".

This calls for an armed response.

[harerod]

...
One person wrote, "My workaround is: uninstall CubeID 1.9, reinstall Version 1.8.0 and pull the Projects out of the backup - i LUCKILY made before upgrading to 1.9."

Another "engineer" not using revision control in 2022. Sheesh.

Revision control plus Virtual Machines with known working configuration of toolset (e.g. IDE's and libraries).
And since this a rather big hassle - never change a running system.
My group is still running CubeIDE 1.3.1, because it seems to work for all the dozen or so different STM32's that we have in active production / support.

The Virtual Machine approach is also useful for checking out different toolsets. Or all kinds of experiments that might foul up your setup.

[peter-h]

Indeed; I have been running Cube in a win7-64 VM also, for various reasons. The one thing however which can be a challenge is connecting to a debugger. I vaguely recall that in Cube / Project properties / Debug you need to check the "shared debugger" checkbox, though it is not clear why. And of course you need to "archive" the debugger also

VMs tend to be troublesome in general when it comes to connecting to physical peripherals, although simple USB should work. What you probably can't do is use Cube with a debugger on the base machine, and use Cube in a VM with another debugger.

[wilhe_jo]

Just stumbled across some code-generation quirk and wanted to "unload" my fury somewhere...

The $%§$%§$%§$ morons at ST make code generators featuring a crapy-as-hell HAL and guess what?, they don't even get clock gating right.

DMA for the ADC doesn't work on the up-to-date dev-tools because DMA init comes after ADC init.
So all the DMA stuff in the ADC init doesn't work because the clock to the DMA is not enabled (seems to make a difference on STM32F303).

Perfect!
I just searched around for 4 hours, because I expected the most trivial thing would be generated correctly....
That's a selling feature and it does not work out-of-the-box!

Seriously, just use the GD32 stuff with vanilla eclipse with the embedded tools!
That's around 15min of work to take a STM32 template and implant the GD32 stuff.

They have decent (up-to-date) samples with their firmware-package and the docs are ok (you get used to the slightly odd wording quickly).
As a bonus, their stuff is cheaper, has better availability (to me at least) and they document quirky stuff if there is one.

15year back, I did not use a Nxp stuff because their dev-tool-package was garbage in a 500k/year product.
Now, I'll phase out ST ...

73

[rsjsouza]

I used Turbo Pascal quite intensively for a lot of real applications with graphical UIs. I actually made first money making software in Pascal. It was fine and did not feel bad at all. Programming graphics in DOS 100% felt better than programming modern graphics.

But I did not care (and still don't) that there is a standard. To me Turbo Pascal was the standard. Same with C - I rely on GCC behaviour and extensions and don't care if something does not work in some obscure proprietary compiler. It is not may problem at all.

I also used Turbo Pascal back in the day. The feeling of getting graphical applications running on a text-based DOS was quite the achievement (the famous EGAVGA.BGI), and it provided me with a foundation that I carry to this day. 

[peter-h]

Cube 1.9.0 appears to now detect if a source file has been externally edited i.e. it has a later timestamp.

I am pretty sure this didn't work previously; after any external editing, or dropping in of files from elsewhere, you had to Project/Clean and Project/Build.

[tellurium]

Oh boy I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too. For the common good.

https://vivonomicon.com/ is a pretty descent write up.

[Simon]

Oh boy I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too. For the common good.

https://vivonomicon.com/ is a pretty descent write up.

If only I could find the index on that awful site layout so that I can start from the beginning.

[tellurium]

If only I could find the index on that awful site layout so that I can start from the beginning.

https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
https://vivonomicon.com/2018/04/20/bare-metal-stm32-programming-part-2-making-it-to-main/
https://vivonomicon.com/2018/04/22/bare-metal-stm32-programming-part-3-leds-and-buttons/
https://vivonomicon.com/2018/04/25/bare-metal-stm32-programming-part-3-5-supporting-multiple-chips/
https://vivonomicon.com/2018/04/28/bare-metal-stm32-programming-part-4-intro-to-hardware-interrupts/
https://vivonomicon.com/2018/05/20/bare-metal-stm32-programming-part-5-timer-peripherals-and-the-system-clock/
https://vivonomicon.com/2018/08/23/bare-metal-stm32-programming-part-6-multitasking-with-freertos/
https://vivonomicon.com/2018/09/05/bare-metal-stm32-programming-part-7-embedded-c-inheritance/
https://vivonomicon.com/2018/12/28/bare-metal-stm32-programming-part-8-learn-to-debug-timing-issues-with-neopixels/
https://vivonomicon.com/2019/07/05/bare-metal-stm32-programming-part-9-dma-megamix/
https://vivonomicon.com/2020/06/28/bare-metal-stm32-programming-part-10-uart-communication/
https://vivonomicon.com/2020/07/26/bare-metal-stm32-programming-part-11-using-external-memories/
https://vivonomicon.com/2020/08/08/bare-metal-stm32-programming-part-12-using-quad-spi-flash-memory/
https://vivonomicon.com/2020/09/10/bare-metal-stm32-programming-part-13-running-temporary-ram-programs-and-using-tightly-coupled-memories/

Also some Github repos with example bare metal projects:

https://github.com/ataradov/mcu-starter-projects - quite extensive list
https://github.com/trebisky/stm32f103 - stmf103 only
https://github.com/fcayci/stm32f1-bare-metal  - stmf1 only

https://github.com/WRansohoff/STM32F0_minimal_C
https://github.com/WRansohoff/GD32VF103_templates
https://github.com/WRansohoff/cortex-m-rt - minimal startup for cortex-m micros
https://github.com/WRansohoff/ESP32_minimal
https://github.com/WRansohoff/STM32_UART_Examples
https://github.com/WRansohoff/STM32_quickstart
https://github.com/WRansohoff/min_freertos_blink

https://github.com/cpq/mdk - bare metal esp32 / esp32c3 SDK
https://github.com/cesanta/mongoose/tree/master/examples/stm32/nucleo-f746zg-baremetal - bare metal stm32f7 ethernet http server

[Kjelt]

https://github.com/ataradov/mcu-starter-projects - quite extensive list

FYI: He is a large contributor on this forum 
https://www.eevblog.com/forum/profile/?u=26419

[tellurium]

FYI: He is a large contributor on this forum 
https://www.eevblog.com/forum/profile/?u=26419

Well, kudos to Alex. There is a large deal that could be learnt from https://github.com/ataradov/mcu-starter-projects .

[westfw]

I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too.

I somewhat like the tutorials and info from "EmbeddedExpertIO"  Such as:

They seem to be primarily a training company, so if you provide your email to get one of their "free" guides, you'll also get periodic (but not too frequent) ads for classes.  The free documents I've downloaded and looked at are nicely concise, cover a log of "bare metal" examples, and have especially nice references from each line of code to the STM datasheets...

[Simon]

https://github.com/ataradov/mcu-starter-projects - quite extensive list

FYI: He is a large contributor on this forum 
https://www.eevblog.com/forum/profile/?u=26419

Ah, right, that is a separate website from the one in his profile.

[xrunner]

I've just spent some hours trying to find out why code which compiled last night doesn't compile today.

Nothing was touched - also not touched according to file date stamps (as seen in windows explorer).

But I appreciate that if you leave any editor on-screen with a file open, a slip of the finger on a keyboard can "do stuff". But this should not change a file if you don't then save it.

I just tried this in VS code (compiling 3D printer firmware). I changed one single digit in a number in a comment. The date of the file on disk didn't change because the file wasn't saved. But when I compiled it, the system saved the file at that time. So even if you changed something and don't save it, it will be saved right at the time you compile it. Maybe your IDE is doing that.

[Simon]

Yes as far as I am aware both microshit IDE's do this, how many times have you been asked to save your files before exiting? me hardly ever as they were saved in the last build and I usually close the IDE after a build.

[DavidAlfa]

Normally there're options for that, ex. in eclipse it's "Save files before building" or something similar.

[peter-h]

Cube IDE is on V10 now
https://www.st.com/resource/en/release_note/dm00603738-stm32cubeide-release-v1-3-0-stmicroelectronics.pdf

Can anyone tell if the GCC version has changed again?

EDIT: probably not since v10, running in a win7-64 VM, produces an identical binary to Cube v1.9.

[peter-h]

v 1.10.1 has just come out. Some bug fixes to do with file corruption in MX.

What I have been finding repeatedly over the last ~2 years is that when running under debug (compilation with F11) the system always breaks at some point, generally after some hours. This is with STLINK V2 or V3 debuggers, ISOL or not ISOL. PC comms with the debugger are lost. The problem is that this also kills the target.

It isn't a problem with normal breakpoint debugging but you can't have a target running for days looking for a breakpoint to get hit, because it will crash before then.

Can anyone reproduce this?