Is ST Cube IDE a piece of buggy crap?

[paulca]

That is why you shouldn't use a debugger to do behavioural verification. Use a serial port with text output for that (and commands to set parameters). Debugging is only useful to find bugs that are not simple to find otherwise (like pointers going wrong or software getting stuck somewhere).

Yes.  Try it.  During the flashing process it restarts the device multiple times making it difficult to set up a test harness which looks for output and then expects a series of data to confirm.  What it actually gets is 3 different attempts to run the MCU.  It doesn't matter if you hit Run or Debug it will restart the MCU multilpe times.

Of course, you can decouple from that too by running the test harness outside of eclipse and not tying it to the build.  Fine for the 1990s and fine in hobby land, but that is not how it would be done in the "real" world.

EDIT:  Anyway, it's neither here nor there, because I'm a hobbyist in this space so while I do ponder about setting up actual automated integration and system test harnesses and even unit testing.    I have more interesting things to do with my free time.   And it's only ME who comes harassing me about bugs and low quality code... because it's only me going to suffer from it in this case.

[peter-h]

Interesting stuff.

STM apparently denies all knowledge of the multiple random file opening bug.

C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini

Jesus, how the hell was one supposed to know about this?

That is why you shouldn't use a debugger to do behavioural verification

What is "behavioural verification"?

Running under a debugger is limiting. AFAICT there is no way to just reset the CPU; one has to (with say F11) reload the project and run it again. Once loaded, and in Debug mode, one can Restart it OK, over and over.

But (as posted in various threads) Cube usually loses the STLINK debugger connection after a while. Some say after minutes, some say after hours. I usually find that it is ok for maybe an hour. It doesn't matter how short the SWD wires are, etc.
https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging-and-njtrst-mystery-does-it-do-anything/msg3564987/#msg3564987
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782
https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging/msg3577722/#msg3577722

It's a bit sad when one does a search and most applicable hits are your own

[paulca]

C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini

Jesus, how the hell was one supposed to know about this?

True.  All that changes is the memory parameters for the JVM Eclipse itself runs in.   The first param is how much to allocate to the VM on start up and the second is how much it can allocate it total dynamically.  In work I tend to have mine set around 1Gb and 4Gb.

YMMV, a lot of build chains items and some plugins etc.  Will actually spawn additional processes and use additional RAM uneffected by that setting.

I am actually going to go and change mine a bit too.  The reason is because I make frequent use of CubeMX and when that gets evicted out of memory and you open it again... well... I minimise the VM and watch YouTube while I wait on it reopening.  Hopefully if I give it another 1/2Gb it may stay in memory.

[nctnico]

Interesting stuff.

STM apparently denies all knowledge of the multiple random file opening bug.

That is why you shouldn't use a debugger to do behavioural verification

What is "behavioural verification"?

Testing the software to check whether all the functionality works as expected. Personally I very much prefer to do this using log output over the serial port so I can check all kinds of things.

[peter-h]

The SWV ITM Console (available in STLINK V3) output should do the same job, and generally it does. What it can't do is use say printf from a boot loader Then, outputting straight to a UART is the only way, but that will hang the code down to the baud rate speed.

[anbr]

The fact that it's built on eclipse automatically means it will be a buggy piece of crap.

I would suggest learning CMake and finding a suitable IDE with plugins. CLion (JetBrains IDE) works well, and VSCode can also work. By doing this, you can just use the standalone CubeMX tool to generate the project files and import them, no longer worrying about hidden changes.

I do not have any proof, but anecdotally, I ran into many issues with ST's IDE. It was nice when it worked, but many times there were small changes in header files which caused a project to stop compiling.

[nctnico]

The fact that it's built on eclipse automatically means it will be a buggy piece of crap.

I would suggest learning CMake and finding a suitable IDE with plugins. CLion (JetBrains IDE) works well, and VSCode can also work. By doing this, you can just use the standalone CubeMX tool to generate the project files and import them, no longer worrying about hidden changes.

I do not have any proof, but anecdotally, I ran into many issues with ST's IDE. It was nice when it worked, but many times there were small changes in header files which caused a project to stop compiling.

In my experience it is a much better workflow to let CubeMX create example code (in a seperate scratchpad project) and then use that in your own project that doesn't use any automatically generated code. I've learned a long time ago (long before ARM microcontrollers where a thing) that automatically generated code is asking for the trouble you describe. It has nothing to do with Eclipse in itself but the code generator tool that has been created by ST.

Which IDE to use is a matter of personal preference. IMHO Eclipse is very useable though with some tweaking and tuning (which any IDE requires anyway).

[peter-h]

In my experience it is a much better workflow to let CubeMX create example code (in a seperate scratchpad project) and then use that in your own project that doesn't use any automatically generated code

Yes that is a good way to do stuff. Use the Cube MX code generator and then cut it down to what is actually needed.

For example if transmitting via SPI the code generator adds all kinds of junk like checking if CRC checking is enabled (by reading back some flag) but if you didn't enable that feature then you obviously don't need that. The auto generated code does actually (usually) work so this is an easy starting point, even for a "bare metal" project.

The fact that Cube is free is generally pretty important, though maybe not for the obvious reasons. A corporate user can buy say 10 licenses for a paid product but in general paid products "phone home" regularly to check licenses, which will eventually bite you in the bum when the vendor stopps running the license server. So the project you last worked on 10 years ago "blows up" because the tool no longer runs. Not even in a VM. So while I happily pay for software which I actually use, I totally avoid any software which "calls home".

[dietert1]

It's complicated.
As soon as you want to use CubeMX for a MCU variant you did not use before, it will call home to install support packages. In that moment you not only depend on their servers but they may also have a look at what you are actually doing with their software. Of course we won't know whether they do that but in general it's enough to know they can.
Is there a reliable way of installing support packages offline?

Regards, Dieter

[peter-h]

Yes you can do everything manually.

AFAIK only Cube MX (the GUI editor + code generator) needs explicit support for the CPU type. Obviously it does because it displays the package, the pins, and you can choose what the pins do, etc.

Cube IDE is just an editor + makefile generator.

The "HAL" libs pull in #defines from .h files for the CPU type, so a HAL function for setting some pin state may use different code for different CPUs, and certainly for setting up the clocks, but you don't need to use that code. You can just write it bare-metal from the RM, and probably should do that anyway, although you may use the HAL function as a starting point to save time.

IME, once a product is out, one rarely just changes the CPU. People did this during the covid craziness shortages, replacing STM chips with ESP32 etc, but this is rare. Normally, you archive the old product (PCBs, schematics, code, IDE, the lot) and generate a fresh one.

There is some telemetry in Cube and they ask you if you agree, but I choose No and anyway could not care less. There is no licensing, floating or otherwise. The other day I had a conversation with some EDA vendor about their floating licenses and asked him what I am supposed to do if (when!) their license server stops working. He said I can run my own license server, to enforce the max # of concurrently running copies. Later it turned out that their code is tied to the MAC # of the ETH card in that "server" PC. So if that PC blows up, you are screwed. Unless you bought a spare ETH card, of a type whose MAC # can be user-programmed (most can't but some can) and then you can create a duplicate server.

In the corporate world people pay for this sh*t because they think if they pay they get support (true, to an extent) but nothing is for ever. I had this lesson with $20k Xilinx software many years ago. They simply washed their hands of if when the two dongles eventually broke (they were flimsy) and I carried on when I found a Russian crack for both Viewlogic 4 and XACT 5.

With $$$-licensed products you get this crap. It's a big advantage of free tools to not have that. You can archive a project, perhaps even in a VM (and I actually have that right now, albeit the VM is ~30GB) for ever, for free.

Of course the extent to which this matters depends on whether it is your company, or you just work somewhere. In the former case you have very specific archival and futureproofing requirements. In the latter case, bread on the table at home = bread on the table at home

[paulca]

So the project you last worked on 10 years ago "blows up" because the tool no longer runs. Not even in a VM. So while I happily pay for software which I actually use, I totally avoid any software which "calls home".

You want 10 year old software to "just work".  Right.  Unless it's been maintained it wont.  Projects in work, maybe a year, maybe a little more, but all projects need to keep moving or they build up cobwebs.  Cobwebs - "This used to work, why does it not any more?"

Just wait till you get to some area which has legal certifications for what you do.  Then try and use ANY software that is more than a few months old to meet those requirements.

MCUs are not completely immune to these issues, the crypto space etc. and military probably have a careful eye on the security space there in.  As for the banking sector, MCUs are generally treated like the plague.  All USB ports and all comms ports on physically machines are locked down to prevent rootkit USB keys and other exotic MCUs.

Based soley on the sheer volume of "Lets hack a hardware device" - in 99% of cases it's not hacking, they leaves the front door open and even give you a nice map to find the valuables....  and the increasing annoyance of the general consumer base around MCU security, it won't be long before people like OWASP, GEM, CVE etc. get into your space. 

When that occurs they will define a whole range of security vulnerabilities existing in your space.  "Open UART" for example.  Releasing a consumer product riddles with known vulnerabilities is perfect fine "today" for most cheap MCU devices, but that is changing.  Soon doing so and then having that consumers device get hacked, they get scammed etc.  Your devices fault.  Soon that won't be a shrug and "its the nature of the devices", "it's the consumers fault."

I don't think those dogs are far from your door.

When the InfoSec/PenTesters have to pass your product.  When every Monday you receive a new updated list of libraries, tools and framework versions which are now BANNED outright from use.  Every single project in current use, must be upgraded immediately.

If that happens to be a bug in STM-HAL Verion 1. 2. 3 and version 1.2.4 won't be released for 2 weeks because STM are slow....  it's YOUR problem.  At worst you have to ask for an temporary "capability" but that requires a lot of higher up people to approve why you want to put/leep insecure software into production.

[paulca]

I feel it fair to give back one point to the MCU pros.

You do have a partly unique challenge.  In software security we would consider "Physical access to the hardware" == "Game over".  If the perp can sit down at the physical machine, you are not stopping getting at least access to the machine, if not the data.

In MCU space, 99% of the time the device is sitting in the user or abusers hands. 

In my view the MCU should always be considered compromised and zero-trust principle regarding any and all communications or otherwise it has with the outside world... such as when it phones home.  That's pretty much how we treat client connections, almost across the board.  "Least Trust principle."

[peter-h]

You want 10 year old software to "just work".  Right.  Unless it's been maintained it wont

That's not my experience at all, and I probably push the boundaries here more than anybody else

I run a ton of 20 year old tools in a XP VM. They were basically pre-XP, even WFWG tools, like Protel PCB 2.8, 1995. But they ran under XP OK. Win7, especially win7-64, breaks them, hence the VM.

I got 10-20 years out of these before moving them into the VM.

Just wait till you get to some area which has legal certifications for what you do.  Then try and use ANY software that is more than a few months old to meet those requirements.

Never seen such a thing, and would not touch such a liability.

All USB ports and all comms ports on physically machines are locked down to prevent rootkit USB keys and other exotic MCUs.

That is a long term drift now, for many years. Corporately, you roll out locked-down PCs.

Soon doing so and then having that consumers device get hacked

In 99% of embedded cases there is no physical (access control) security so there is no security whatever.

Every single project in current use, must be upgraded immediately.

I would not work in such a field

In MCU space, 99% of the time the device is sitting in the user or abusers hands.

That's what I typed above, before I read your 2nd post

Hence back to the old debate that if you are selling IOT boxes, your customer simply must not install them on some "open port". Lots of reasons, starting with the impossibility of deploying firmware updates. If you are selling a box which sits on an open port, the ch-i-n-k-s will be in there in hours if not minutes (faster if there is a published DNS record) and no IOT box will withstand that, if it has any sort of "attack surface" e.g. an obvious remotely accessible file system. A lot of IOT boxes are running linux and they have basically no hope because everybody knows where to start. Whereas if you sell a box which is fully custom, has no evident OS, with a 32F417 whose attack surface is a RJ45 + PHY + ETH + LWIP then somebody might DOS it and maybe crash it (I am sure LWIP can be crashed with malformed packets) but that's about it. Obviously HTTPS does not help at all.

If I was making remote access gear for substations in Ukraine then that would be different

But this is digressing. I just don't see what advantage a commercially licensed IDE would have over Cube, in these scenarios. It is just an editor + compiler platform. Would your customers object to using some free PCB software?

[nctnico]

You want 10 year old software to "just work".  Right.  Unless it's been maintained it wont

That's not my experience at all, and I probably push the boundaries here more than anybody else

I run a ton of 20 year old tools in a XP VM. They were basically pre-XP, even WFWG tools, like Protel PCB 2.8, 1995. But they ran under XP OK. Win7, especially win7-64, breaks them, hence the VM.

Agreed. Having the ability to run old stuff in VMs is a real blessing. I'm very sure I can support all the projects I have made over the past 25 years. I have all the software available on my PC (I mean, on my PC as a file I can access in seconds, not somewhere on a floppy disk in a box). And if a VM doesn't do the trick, you can always use an emulator.

[NorthGuy]

You want 10 year old software to "just work".  Right.  Unless it's been maintained it wont.  Projects in work, maybe a year, maybe a little more, but all projects need to keep moving or they build up cobwebs.  Cobwebs - "This used to work, why does it not any more?"

Non-sense. I use lots of software from last millennium. It all works very well. Believe me or not, there were times when software wasn't as buggy as it is now.

BTW: The "maintenance" is one of the root causes which makes the modern software so buggy.

[peter-h]

For many years it was very clear that the best version of a given program was the last release before it was either abandoned or replaced by a new major version.

And it makes perfect sense if you think about the software business cycle.

It applies to all software. CAD/EDA, which was always full of bugs (due to complexity right on the edge of computing), and the vendors were constantly releasing new versions because - absent the rental option - the only way to maintain the money stream with a product which basically works just fine was to constantly pack in new features. It is true for all M$ stuff too; the last versions of winXP were outstanding and XP remains popular in industry, running all kinds of process monitoring and test stuff (the "lack of security" is BS in these applications). Same for win7-64, for which there is still an update process (simplix). Same for graphics apps.

With Cube, we aren't there yet and may never get there because

- it is based on Eclipse which is not an ST product
- ST seem to think Cube is for hobbyists
- it is not a direct money generator (but ST don't have to support it, and indeed don't, as is obvious from their mostly dysfunctional forum)
- it is written in Java, so it is beyond any hope of "fixing" because with this lot you have no hope



Yes I know only a small % of those 18k files are directly related to Cube and its operation, but still... no hope.

[Kjelt]

With Cube, we aren't there yet and may never get there because

- it is based on Eclipse which is not an ST product
- ST seem to think Cube is for hobbyists
- it is not a direct money generator (but ST don't have to support it, and indeed don't, as is obvious from their mostly dysfunctional forum)
- it is written in Java, so it is beyond any hope of "fixing" because with this lot you have no hope



Yes I know only a small % of those 18k files are directly related to Cube and its operation, but still... no hope.

Good you finally understand it, good that you are a hobbie-ist and not a company that depends on that Cube crap to make products to generate revenue. 

[paulca]

Those files as I have repeated told you are mostly documentation and examples.

Delete them and stop whining about them.

I gather there is an ocean between us in terms of software development.  You pair honestly sound exactly like amateurs in terms of software. 

It all comes down to complexity.  MCU projects are so often Single, One man band endeavours you will never actually have to do any software engineering, so you just don't understand it, evident from this thread.

Since you know what's wrong with Eclipse.  Would you mind telling which parts you think are written in Java and which arent?

[peter-h]

No idea, of course, and why would I need to know?

Why get "personal"? Why not write something helpful? Well, this is the internet, of course

[peter-h]

Does anyone know if there is a way from Cube to get the versions of the GCC tools?

The only way I know is to change into the directory where the tool executables are and run something like

arm-none-eabi-gcc --version > toolsversion.txt

[paulca]

Why get "personal"? Why not write something helpful? Well, this is the internet, of course

Sorry, I was in a particularly grump mood yesterday.  You are right, no need to be personal.

[dkonigs]

From th

Does anyone know if there is a way from Cube to get the versions of the GCC tools?

The only way I know is to change into the directory where the tool executables are and run something like

arm-none-eabi-gcc --version > toolsversion.txt

Not sure about from the GUI.  But if you want to know for the purpose of your build process, look for info on adding "makefile.defs" and "makefile.targets" to an Eclipse project.  I've used those to add extra defines and steps to my build process, while still being able to keep it within STM32CubeIDE, to do various things.  You could certainly add something in there to run the above command, and then place the output somewhere useful.

In my case, its stuff like embedding build information in the binary, embedding checksums, and producing output in formats suitable for UF2 and DFU.

[Simon]

The default maximum is a couple of thousand lines

Make sure to give the indexer enough memory

Interesting. Where is the config for this?

and start finding out that also there life ain't perfect.

Nobody said it was

What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?

i spent 12 hours trying to use it and gave up. I'm sorry but if you are willing to use a tool that is so clunky to the point that a clock division register entry does not subtract 1 from the number you put as it will add one in the hardware then yes, if you use this in your professional work, you must be some damn amateur.

What happens when you need to use counters that share a clock source? Micro controllers are not computers, to try and treat them as such is childish. Any application you create will need to take into account the workings of the chip because the combinations are endless and no "configurator" will ever be able to do that and be easy to use, it's easier to just use the damn chip. so grow up, and realize that you will spent 10 times the time writing your application code anyway, and if you write the code for your peripherals you will be able to make your life easier. Configurators are for people who just don't know what they are doing, it's simply a marketing tool for the stupid to get sucked in by.

[dietert1]

I hope you are better now.
Let's not forget how complex STM32 products are. Many developers have to use these imperfect tools and building blocks to be efficient. One cannot get TouchGFX or the AI components going if one starts reading reference manuals about the clock system. If there are errors that deserve research, no problem, as all components are open source, so one can debug into them.
There are people making good money using this approach.

Regards, Dieter

[Simon]

in order to setup basic hardware you have to be very familiar with the chip, you have to read the datasheet (manual) and understand it, or you won't get anywhere with the configurator as nothing is explained. My junior colleague told me to look at examples and watch videos. Yes I have to watch a 10 minute video for a 10 second segment that told me the function name I needed to turn the damn counter outputs on.

It took me hours to get a counter working, I then took up my SAMC and wrote code to generate a PWM in half an hour, a counter type I was not familiar with... because I understand the hardware of these sorts of things.

With an ST device I still have to read the datasheet and then figure out cube, it actually takes longer. Yes high level stuff cannot be written quickly and I'd like to find that off the shelf, but then if it comes glued to a system that is just a nightmare, well it's as good as proprietary.

I don't know if this higher level stuff ever comes in a form where they just describe the hardware access required and you provide it.

No ST make no HAL, they make a HHAL - Hardly Hardware abstraction layer, I write a hardware abstraction layer.