STM32 Roadmap?

[harerod]

I have been designing solutions around STM32 for over 15 years, right from the F103 days. The most complex projects have been with F4, simpler applications with F1, F0, Lx, Gx, etc..
As a result of the ongoing Chipageddon situation, most silicon manufacturers have lost my faith. Since my clients and I have put a huge investment into the STM32 family, I am really concerned about how ST is going to proceed with that family. A quick online search for "STM32 roadmap" didn't bring any enlightenment. The "10 year guarantee" is of not much use, when it comes to a F407. At this point and being a simple freelance engineer, I don't expect a useful answer from ST, should I address them directly.

https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html

Question: is there any information out there, regarding which way ST is going to develop the STM32 family? What devices should one use for the next redesign?
At the moment the F407 from the "High Performance"-range would be my biggest concern, simple because of the code complexity. At the same time I am also interested in "Mainstream"-range items. During Chipageddon we already did several redesigns to keep things going with the devices that we could procure. E.g. replacing F407 with smaller FLASH versions, or replacing F1 with any small, slow and buggy A-revision Gx's that we could scratch from the bottom of the barrel.

I am aware of STM32 clones and other ARM MCU's. Let's stick to genuine ST in this thread, please.

[Sacodepatatas]

I expect them answering to this question on tomorrow's event.

https://content.st.com/stm32-innovation-live.html

[mark03]

So the deadline is past, and although I don't have time to sit through a 1.5-hour video, I did take a look at the STM32 product page and tried a google news search for "stm32" and I don't see much in the way of new MCU development.  (The new MPUs are interesting to some, I guess.)

Still no Cortex M55 or M85 parts with the Helium SIMD.  Nothing with neural coprocess (Ethos).  Nothing exciting on the process front either (anyone remember FDSOI?).  No foray into RISC-V either.  I would need at least one of those to pique my interest.

Everyone knows there is a long lag time between ARM's announcement of new cores and real silicon, but if
you compare with Cortex M7, this has already been a longer wait than normal---the M55 was unveiled more than three years ago, and there are still not even vaporware new-product announcements from ST.

That being said, they promised an update on the supply situation... Did anyone tune in to hear what they had to say?  Just being able to buy parts from their current product line would be fantastic in the near term.  But IMO a lack of new products in the pipeline bodes ill for the future.

[peter-h]

Looking at chips I have used over past 30 years, I reckon the 32F407/417 will be in production for another 15-20 years.

ST is in a similar ballpark to Hitachi (now Renesas). Once they get loads of design-ins they tend to keep making the parts. H8/3xx had a 25 year production run and I'd say the 32F4 has had more design-ins. Even in the heyday of sales engineers, Hitachi offered almost no help at all. Painfully, one could extract information on stuff not in the data books.

And then ST will chop some package options, narrowing it down to some tiny BGA package.

These 168MHz-180MHz chips deliver 10x the power of previous generations, which is nice, and necessary for stuff like USB and ETH. The later ones might do 500MHz internally but they risk getting too far ahead of market demand. The applications that need that are far fewer, and you have to charge more for the chips to maintain product spectrum differentiation; this is a key marketing requirement even if it is completely bogus in terms of production costs.

And at the same time you don't want to drop prices on the older chips because nowadays that is a real no-no. The name of the game is shafting everybody who is not big enough to not get shafted. That in turn limits how much you can charge for the later chips.

IMHO the most important thing is to avoid brands which drop parts faster than a whore's knickers - like Atmel

[AVI-crak]

In Russia, everything is very simple - there are simply no ST products.
We use everything that can be used, even very strange and scary solutions. The main purchase opportunity.

[SiliconWizard]

In Russia, everything is very simple - there are simply no ST products.
We use everything that can be used, even very strange and scary solutions. The main purchase opportunity.

What kind of MCUs do you use?
I have seen some russian MCUs, but mostly hardened/stuff for aerospace applications.
I guess you otherwise have access to chinese MCUs with not much difficulties.

[peter-h]

Building cruise missiles and such, you don't need anything beyond a chinese ripoff of a 32F407 The challenges are inertial nav (for where GPS is being messed with) and hi res IR (thermal) sensors, and all that stuff is ITAR.

[Boscoe]

I am too keen to understand where ST is going and id love to be a fly on their wall when it comes to addressing how their company will move forward considering the dent in their reputation - their fault or not.

I moved over to ESP32 for a couple of reasons however sourceability being the main one. The IDF tool chain is light years ahead of the ST offering.

I personally think that MCU companies should drastically reduce their product lines and invest that RnD into tool chain and support. If you had ~15 key products with differing cores, speeds, memories and packages and epic tooling you’d have a winning offering IMHO.

[uer166]

The most interesting series on roadmap are the Stellar MCUs, the first engineering samples are hard to come by though. 6 Cortex-R cores, where you can run different combination of lockstep, checker cores, etc. NEON and all the bells and whistles as well.
https://www.st.com/en/automotive-microcontrollers/sr6g7c4.html

I don't understand the "they don't have anything on the roadmap", these are probably the most complex, feature packed, and FMEA'd CPU/MCUs they've ever made, and are well tailored to power electronics and all kinds of automotive stuff.

[AVI-crak]

What kind of MCUs do you use?

Everything that can swing its paws, well, except for very ancient solutions. Direction - industrial automation. Many products have become inaccessible and too expensive, even Chinese ones. You have to invent your own.

[Sacodepatatas]

I expect them answering to this question on tomorrow's event.

https://content.st.com/stm32-innovation-live.html

Summarizing...

-They Will focus on two families, the entry level STM32C0 for replacing the legacy STM8S designs, something weird as these aren't pin compatible with the later  (and, in my opinion, it's a horrible nomenclature change, the "C" reminds me the time when regular 8-bit MCUs and EPROMs were OTP or Factory masked. A "Z" series would have rocked instead). And they'll stick developing for the STM32H5 family. For STM32F0/1/2/3/4, no dead line in a short term, but no further development of these cores. For entry level, they promote switching among C0 and G0 families depending upon the need of features (quite obvious though).

-For high end MPUs of the STM32MP1 family the're strongly focusing on hardening IP security and trust level so their top MPUs have obtained several certifications (I don't remember which ones).

-They keep holding the 10yr commitment for new design lines.

-They are releasing a new ST-Link V3 extended with power metering and analyzing capabilities.

-They might have reach some agreement with Microsoft because they are going to follow the line of development integrating their ecosystem with VScode and AzureRTOS. They will continue developing the STM32CubeIDE, but this is not their priority right now.

-And that's what I have got in clear from the yesterday's meeting. Oh, one more thing left: they are very happy to anounce that they have reached agreements with their foundry parners (I guess that they refer to TSMC) so they consider the chip shortage something from the past, but It looks more like a promise than a matter of fact.

[harerod]

@Sacodepatatas (ger. Kartoffelsack),
thank you for the write-up. The part regarding the F-family fits my misgivings pretty well.
Instead of giving dates, we hear that a foundry is actually signalling willingness to manufacture devices in the future. We have also heard that ST got new major customers that require huge amounts of silicon. We can assume that the first production runs will go towards those.
Without further input, my recommendation to clients who require long time availability:
- for existing products: keep checking the distribution channels for eventual availability of STM32 devices. Move F4-designs to feature compatible devices
- keep in mind who gave the best support to small clients during Chipageddon. In my personal experience, Microchip sales/support made outstanding efforts to keep us supplied. ADI, ST, TI, only to name a few, have a lot of image reconstruction work ahead of them   
- in the past we used weaker STM32 to replace 8-bitters, simply to use one IDE for all projects. Now I can see us moving back to AVR/PIC, just to reduce the dependence on ST

[Debugging]

The Webinar was interesting because it kicked off talking about the expansion of capacity. the availability of STM MCU has been a pain for very long.
It was like apologizing for the shortages to keep the cold heart of (small) consumers warm that supply is coming....  It may be just a little too late.... We all know the big consumer have
booked all the supply from the fabs keeping no allocations left for retail . This is easy to see as in retail you find that if order K's of MCU's you get reduced leadtimes from 6 months to a year or more. that is not the strategy of Mouser, Digikey, That is the attitude of STM, NXP and all the big MCU brands and that may have backfired for smaller companies that are now switching or have already switched over to other MCU's. some brands have chosen ther priorities and are killing SMB's, some smart brands are focusing  to take their place in that market segment.

Low lights:

- No STM32MP15 with 4 lanes MIPI  display interface
- The STMH5 series is based on single core M33 and not M55. It misses out on DSP instructions and graphics like the H7 has.  Memory is limited to 640K.
   Hopefully they will release a higher end H5 with those features. it seems something between an F/G and the H7 but with higher clock speed.
   A good reason to stay with the H7. M33 is already 7 years old.
- No mention if the the improvement made for MP13 (see below) will also apply for MP15.
- Select speakers with better English.

Here are my notes:

- Supply :  300mm expansion on site (France?), Italy 300mm fan ramp facility, Plans for 400m plans (if I did hear correctly), Capacity increase will happen from now till 2025
- STM32MP13(5) < $4.  Tj=125C, Cortex A7  1Ghz, Low power standby, 4 layer TH templates, Yocto Real time OS as alt to embedded Linux, LinuxRT Factory automation
  AzureRTOS , Bare metal control, Side channel., Root Of Trust, Armz trustzone,  Obtain SESIP level 3,
- STM32H5 adds I3C interface, 2MB Dual Flash , 640KB MAX
- Integration with VSCODE (NXP announced the same for IMXRT)
- WB1MMC BLE  FCC/CE/Anatel precertified. can use Internal antenna and  external antenna
- Cube.AI Developer Cloud
- STM32WBA  BTLE100mhz 407 stone marks BLE 5.3 SESIP 3 + 10dBA gain. Support isochronous mode transmission and LC3 codec
- Several product support SESIP Security Evaluation Standard for IoT Platforms）
- CubeIDE SecureManager - iROT / PSA SESIP 3, PSA API with  SMDK Secure Management Development Kit

Hopefully they don't go into too deep in the love boat with Microsoft because  Micorsoft is dropping Linux support everwhere due to their new GUI engine. Teams is also victim of that and when that continues the STM IDE may loose Linux support ? Hope not.

P.S: A 10 years guarantee does not mean much when parts have soon been 5 years out of stock and with the forecast we may only see there whole situation recovered by 2025..

[MT]

and F429 are 12 years later still manufactured but sold at silly high prices and errata sheet at Rev19 and counting.

[harerod]

...
Hopefully they don't go into too deep in the love boat with Microsoft because  Micorsoft is dropping Linux support everwhere due to their new GUI engine. Teams is also victim of that and when that continues the STM IDE may loose Linux support ? Hope not.
...

Dropping Eclipse and replacing it by anything Microsoft would be serious bad news for all of us who are dedicated to long time support. I'd rather go through yet another "refactoring" of the libs than seeing that happen.

The availability issue extents to other ST products, which also require fab capacity.   
Heck, it seems that ST are hell-bent on killing all arguments in favor of sticking with them. Maybe it is time to accept that small businesses are not their target audience.

[peter-h]

They will continue developing the STM32CubeIDE, but this is not their priority right now.

I have not noticed "development" over past 2 years, other than adding support for new chips.

Maybe it is time to accept that small businesses are not their target audience.

They never were anybody's target audience. Not since I started in this business in 1978.

Select speakers with better English.

I gave up on their videos partly due to this. What country are they made in? There are a couple of places where not speaking English is "culturally mandatory"

[SiliconWizard]

The newer STM32U5 series looks also pretty cool.

Not very fond of the love affair with MS. But we know how MS can be extremely commercially agressive, so "resisting" MS is probably tough shit, especially if you want to expand your IoT market.

[peter-h]

I know nothing about MS VC++ (I pay people on freelancer.com to write apps in it) but I understand that some people have used that IDE for STM chips. Cube IDE is after all not much more than an editor and a makefile generator. How one runs a debugger under VC++ I have no idea but perhaps the clunky Segger ones with the 1970s user interface will run OK.

Obviously as "Cube IDE" only, not Cube MX (which all seasoned programmers seem to hate anyway, but is handy for getting the ST devkit to flash an LED).

Cube IDE getting killed off would not worry programmers working for themselves but it would be a hassle if more than one person is generating code for a project, especially over a long time.

[Sacodepatatas]

Select speakers with better English.

I can't talk with much authority about that, but, the french lady looked too much hot for me to become aware of her speech fluency...

If I can recall properly, when in the Q/A section, somebody asked if there was any H5 (or U5, don't remember exactly) with GPU capabilities, and the answer was  "no" because such family was oriented for industrial environment and not for graphics...

[peter-h]

Where is this video?

Looking back to electronics engineers I knew since univ, all the univ dropouts ended up being sales engineers. But they were way more successful with "night life" than us real engineers

New ST products will be driven largely by large OEM requirements.

[hans]

To be honest I'm a bit confused by ST's new MCUs.

The STM32F103, STM32F207 and STM32F407 were classics that made pavement for a lot of the other MCU models. The F42x series added SDRAM and LCD support, the F446 had QuadSPI memory expansion, and then later the F7 and H7 models were introduced with Cortex-m7, more memory, SDMMC, etc. Some of these chips (in particular F7) had very similar peripherals to the F446 chips. Then ST has sort-of aa 2nd gen of MCUs in the H7 family that introduced a new memory controller e.g. OctoSPI, which follows up on quad SPI so you can utilize dual-bank FLASH and/or even HyperRAM. The U5 MCU also has this memory controller, and it's great if you want to run code from external memory. The QuadSPI FLASH controller can have a random read latency of up to 430ns on a L1 cache miss, which is an eternity (93 cycles @ 216MHz)

That's all great: but meanwhile, they were also able to maintain other useful peripherals of the F4 family. For example, the F4 family has USB OTG FS+Phy and OTG HS+ULPI, which can be useful for high bandwidth PC applications. The U575, G4 and H5 series seem to have left these peripherals out and only includes a "USB FS host and device" peripheral. So I wonder: why a step backwards?
All these chips are on a better level of speed/memory as the original F207/407 chip, so I don't see why these chips wouldn't be able to carry USB HS data. Maybe it's an IP licensing issue, maybe a low customer demand issue, but I find it confusing that they have omitted this peripheral for 3-ish new generations in a row. I do see they list USB HS on the newer U59x chips, which is great, but still makes me wonder why they fragment their U5 lineup with only USB FS on the U575.. If anything I'd make a guess it makes more sense to consolidate several variants to the same die design, so they can be sold from the same wafers.

Ah well, can't complain and probably will never know. I never viewed ST's MCU as especially focused on 1 area, such as industrial, which IMO is a key ingredient to their widespread adoption. I think that with their mainstream line-up listing "ALL" option boxes was a great strategy. E.g. I once tried to design with a Microchip/Atmel Cortex-m7 chip, and was purely shocked that a 300MHz 100QFP device would only have 2 SPI interfaces

[5U4GB]

Building cruise missiles and such, you don't need anything beyond a chinese ripoff of a 32F407

Friend of mine has done some analysis of various STM32 clones/fakes.  Trust me, you really don't ever need one of those.

Your competitors OTOH...

[GromBeestje]

Building cruise missiles and such, you don't need anything beyond a chinese ripoff of a 32F407

Friend of mine has done some analysis of various STM32 clones/fakes.  Trust me, you really don't ever need one of those.

Your competitors OTOH...

I looked into F103 clones myself, back in 2019, and I am about to have another look.
Does your friend have a blog or somewhere they share their analysis?

[5U4GB]

Does your friend have a blog or somewhere they share their analysis?

No, sorry, just an occasional IM'd "WTF, look a this!" :-).  However there's a ton of pages around that cover these things, "stm32 fake" should turn up a good set of results.

[janoc]

I know nothing about MS VC++ (I pay people on freelancer.com to write apps in it) but I understand that some people have used that IDE for STM chips. Cube IDE is after all not much more than an editor and a makefile generator. How one runs a debugger under VC++ I have no idea but perhaps the clunky Segger ones with the 1970s user interface will run OK.

Obviously as "Cube IDE" only, not Cube MX (which all seasoned programmers seem to hate anyway, but is handy for getting the ST devkit to flash an LED).

Cube IDE getting killed off would not worry programmers working for themselves but it would be a hassle if more than one person is generating code for a project, especially over a long time.

Visual Studio Code is not Visual Studio, those are two completely different products, with unfortunate naming (yay, Microsoft!). VS Code is originally built on Atom, an open source editor project and is mostly open source, with support for languages and what not in form of extensions. Some paid, some free (both as in beer and freedom).

I can understand that they would want to drop Eclipse which was slow and clunky in the best of times, VS Code is lot better in that regard, with modern tooling support for developers. Its support for C/C++ (but also Python, Javascript/Typescript and a lot of other things) is very good, even first class. It is also cross-platform (unlike the "big" Visual Studio) - and doesn't need Java, which is another bonus. There is also a huge community behind it, unlike Eclipse these days.

PlatformIO uses VS Code if you want a taste of what it is like.

So in this case I would consider moving to VS Code from an Eclipse-based IDE as a straight upgrade, IMO. The code generators and projects should be convertible if they do it properly - VS Code doesn't have a "native" project format, like Eclipse or the Visual Studio, it completely depends on what tooling you install in it. E.g. C/C++ work is usually done using CMake-based projects but nothing prevents you from using hand-written Makefiles, if you want. The IDE will work either way.