🔧 STM32 Samples: A Developer’s Time Sink

[islavv]

:wrench: STM32 Samples: A Developer’s Time Sink

I’m not a novice in software at all  — and this isn’t just about one sample. It’s about STM’s consistent failure to respect developer time across their software stack especially modules of other vendors like MXCHIP EMW3080.

Take this gem from the B-U585I-IOT2A sample:

How to use it?

• WARNING: Before opening the project with any toolchain be sure your folder installation path is not too in-depth since the toolchain may report errors after building.

• Open your preferred toolchain

• Build all files and load your image into target memory

That’s the entire instruction. No toolchain version. No dependency list. No build script. No error map. Just “don’t put it too deep” and “open your preferred toolchain.”

STM is not a software company — and it this proves it. No UMLs. No sequence diagrams. Even no consistent pin configs. No architectural overview of how module like the MXCHIP 3080 interact with U585 - wake, notify, etc. Just megabytes of samples and a scavenger hunt to make them work.

STM does not care how many weeks developers waste trying to compile and run their demos. This isn’t onboarding — it’s obstruction. What a shame

[Ozone]

I am not affiliated with ST in any way, just an interested user - to put this upfront.

But to give a general remark, after almost 3 decades in this business.
Most developers would be surprised to learn how tiny many software departments even of huge companies are.
Despite the fact that the company's reputation in this field solely rests upon those few people.
And, the upper managers in those non-software fields most often have a very simplistic and idealistic idea of the complexity of software projects.

I suspect this might be the case here ...

[islavv]

IMHO Take a look on Nordic and follow them :)  U-585I-IOT2A is complete mess with lot of things not working properly or at all.

[Ozone]

Looking at the U-585I-IOT2A, I read "M33 core with TrustZone", and have an idea what might happen here.

At the moment authorities in Europe are pushing a new "IT security" machine guideline, which forces commercial users to implement certain access restriction measures for their products containing embedded IT. Trust Zone and TPM in general are methods to implement this.
However, it is another step-up in complexity, obviously flooring many of the already chronically understaffed development departments. And I guess the team at ST creating the example & demo applications for new silicon falls into this category. While I came across discussions about this "Cortex-M + TPM" variants on other vendors' fora already a few years ago, I observed it here only recently.

Fortunately my employer, a mechanical engineering company, gave up dabbling in hardware design a few years ago and resorted to use off-the-shelf ECUs. Proper support of the underlying hardware, including the TPM stuff, is expected to come with the package.

I pity those who are tasked to deal with those immature and halfhearted evaluation tools on a professional basis ...

[LCE]

> I pity those who are tasked to deal with those immature and halfhearted evaluation tools on a professional basis ...

It's not that bad - if you have learned to expect not too much from the given software in general, and / or CubeMX and the examples.

I'm coming from the hardware side, in the first few years I only did schematics and layouts, then added FPGA firmware, then 8-bit µCs, now working also with STM32.

I still see this as hardware development, so I have the same standards for "my" STM32 firmware: I need to know and understand how things work a 100% (almost...). So I'm not relying on precompiled and / or HAL libraries at all, with some rare exceptions.

And for some very basic, simple, and quick evaluation it's just good enough.

What I really like from ST: the Nucleo-boards. Good and inexpensive hardware. Doesn't hurt too much if one board gets bricked...

[islavv]

Agreed Nucleo is good stuff and in general STM hardware engineering is strong. Software support is on weak side

[Ozone]

> I'm coming from the hardware side, in the first few years I only did schematics and layouts, then added FPGA firmware, then 8-bit µCs, now working also with STM32.

That's the difference.
My company sells work machines which happen to contain ECUs, and needs to conform to certain safety (and soon security) regulations. Field maintainance and updates are equally important as sales. A higher initial investment in a properly designed ECU and certified RTOS and toolchain pays off later, a lesson that took us some years to learn ...

I had been in more hardware-focussed companies and departments similiar to yours before, and I very much agree. Nowhere assumed any professional that evaluation software and free tools were ready for commercial use, nor did any of those companies use them for this purpose.

I only think ST sales trying to insinuate otherwise is disingenuous.

> What I really like from ST: the Nucleo-boards. Good and inexpensive hardware. Doesn't hurt too much if one board gets bricked...

ST's hardware is good and solid, definitely.
But after the initial HAL/Cube version, their "free software support" team never catched up with the release of new silicon, both in regard to example coverage and quality per MCU, and overall IDE / toolchain quality.