Is there a way to find STM 32F CPUs which are upwards compatible with 32F417?

[peter-h]

The 32F437 is, as already discussed, but I am struggling to find a list anywhere. I am after the 100 pin package, too.

I found some migration guides but they were 10 years old.

[DavidAlfa]

If you read the migration docs, you should know it already!
I suggest you talk about this with ST support, nobody will assist you better.
Let me guess, after a lot of hassle, adding external RAM etc, you finally gave up and realized you need a better mcu? 
I think most F4 series will be mostly compatible,  but you only have few parts better than the 417.
Going to the G/H series will need porting at some level, the peripherals are newer.

[peter-h]

Let me guess, after a lot of hassle, adding external RAM etc, you finally gave up and realized you need a better mcu? 

Not at all. The project is just fine with a 32F417, which is just as well since I have a lot of stock, which turned up after a year or so... Bought for £5 each!

The 417 project has ~60k spare RAM, which is absolutely loads, unless somebody wants to use TLS which grabs 48k and then it gets a bit tight if one wants to add more features.

But since all of that 48k is obtained with a single malloc() - note that the heap space is ~60k - this will work especially well with the 437 version which has ~120k heap space.

Nothing wrong with looking ahead!

I think most F4 series will be mostly compatible,  but you only have few parts better than the 417.
Going to the G/H series will need porting at some level, the peripherals are newer.

Right, but you must have found that info somewhere. Where did you find it?

[GromBeestje]

The same series, eg F4, are generally compatible with each other. This can be derived from the fact they share the same peripheral drivers. Even though you have to specify which part you use, disabling certain drivers which are not available.

Moreover there is this list, showing the chips that share the same die. https://www.mikrocontroller.net/attachment/443532/stm32-families.txt Basically, they are the same, just relabelled.

Another source of determining the compatibility of the peripherals is to look at libopencm3. This project has written their own drivers for STM32 MCUs. They generally have drivers named like USARTv1 and USARTv2, Different revisions of a kind of peripheral, and then redirect the drivers for the different series to the versions ,where you can see which one uses which,  this shows mostly how much the different series share with each other,

[wek]

Short answer is easy: there is none.

Long answer is based on definition of "compatible".

JW

[peter-h]

The list from GromBeestje is really interesting. For example we know the 437 is a superset of the 417 (except the ADC1 Vbat measurement) and I have exhaustively verified this experimentally.

But look:

DIE413  STM32F417I(E-G)Hx
DIE413  STM32F417I(E-G)Tx
DIE413  STM32F417V(E-G)Tx
DIE413  STM32F417Z(E-G)Tx

DIE419  STM32F437AIHx
DIE419  STM32F437I(G-I)Hx
DIE419  STM32F437I(G-I)Tx
DIE419  STM32F437V(G-I)Tx
DIE419  STM32F437Z(G-I)Tx

Different dies... but:

DIE419  STM32F439Z(G-I)Yx

So a 439 is probably a superset of the 417 too.

And sure enough the 439
https://www.st.com/en/microcontrollers-microprocessors/stm32f429-439.html
looks like a 417 with extra stuff, which if not needed doesn't matter. But the 439 is a dead end for more RAM or FLASH because you can get these on a 437
https://www.st.com/resource/en/datasheet/stm32f437vg.pdf
The "256k" is a lie because it includes 64k CCM which is on a different address space

I also see the RM (RM0090 Rev 19) is common to all these. There are differences but probably not a functional loss when moving up. I see the 439 CCM cannot do DMA either, AFAICT.

So one doesn't get more FLASH or RAM than with a 437.

There are quite categorical statements like this



I should have been more specific and restricted the Q to more FLASH and/or more RAM. The peripheral variations are obvious where you get say 8 serial ports or 6 serial ports.

But "same die" cannot be the whole story because e.g.

DIE413  STM32F407I(E-G)Hx
DIE413  STM32F407I(E-G)Tx
DIE413  STM32F407V(E-G)Tx
DIE413  STM32F407Z(E-G)Tx
DIE413  STM32F415OGYx
DIE413  STM32F415RGTx
DIE413  STM32F415VGTx
DIE413  STM32F415ZGTx
DIE413  STM32F417I(E-G)Hx
DIE413  STM32F417I(E-G)Tx
DIE413  STM32F417V(E-G)Tx
DIE413  STM32F417Z(E-G)Tx

shows there must be factory programming to disable the hardware crypto on the 407, otherwise nobody would buy a 417

It's interesting...

[DavidAlfa]

Just but a pair of F469/479 and try it out, I'm pretty sure it will work.
Some things needs to be considered, like the flash sector arrangement when migrating from a different density device, but the peripherals will rarely differ within the same family, it's just combinations of enabled/disabled peripherals and different RAM/flash sizes.

[peter-h]

I would be amazed if say the SPI or UART were different. Why would ST do that? It would just cause hassles.

It's funny; I didn't know the SRAM has 3 sections with different MUX connections (and I don't mean the CCM)

Anyway, the 437 is the principal upgrade for my stuff if I need more RAM. The 2MB FLASH may well need different loader behaviour; I know one can program one 1MB portion while running code from the other 1MB portion, so a RAM based loader can be wholly avoided, but then you lose the ability to run a 1MB version so you may as well retain the RAM based loader.

180MHz is absolutely minimal over 168MHz.

What would be interesting in my specific thing would be a faster SPI2. Currently I am limited to 21MHz. SPI1 can go to 42MHz but my SPI1 was a victim of pin allocation, given I wanted four serial ports too...

In a narrow context this was done before
https://www.eevblog.com/forum/microcontrollers/st-32f417-any-way-to-make-an-spi-sram-to-look-like-normal-ram/msg4098865/#msg4098865
https://community.st.com/t5/stm32-mcu-products/are-there-design-change-guides-e-g-32f417-to-32f437/m-p/85071?t=1649194044094

ST should have produced migration guides, listing differences. Currently you have to compare bits of the data sheets / bits of the RMs / compare MX-generated code snippets, which is ridiculous. Yet, whoever inside ST wrote the Cube MX "code generator" must have had access to something like that - or have a really deep knowledge of the various chips.

[GromBeestje]

For the STM32F103, it has been known to have 128 KiB of Flash on the 64 KiB model, and we have seen STM32F101 being used in Aluminium ST-Links, despite the F101 officially not supporting USB. However, I have been told such locks have been implemented on newer dies.

[peter-h]

Just but a pair of F469/479 and try it out, I'm pretty sure it will work.

It does look like a 417/437 with (apart from peripherals like MIPI) with more RAM (320k + 54k CCM) but is not pin compatible in any of the package options, so probably not compatible with the AF mapping which is really key to all this.

Also half of them don't have ETH.

[hans]

I don't think functionally peripherals differ much. If you notice, you will download a CMSIS library for e.g. a F4 or F7 family. Although each device has its own RTL header file, I wouldn't expect there to be any differences in the bit definitions. The peripheral code runs pretty much the same on a variety of devices. The different device models only get certain chunks of the library activated or deactivated (for example, devices that (do not) support ethernet, or devices with more UARTs etc).

Now that doesn't mean that devices cant have pinout differences. E.g. some L4 parts have an integrated DC/DC so that (re)moves some pins. Some H7 parts on the 150+ pin packages may have 2 physical pins connected to the same GPIO (see H725 in LQFP176, pins 18&19), although through a programmable switch. But that doesn't make it an extra GPIO if you disconnect the switch. The F407 is listed to have more GPIOs than e.g. that H725 part.

I think STMCube can list "compatible" MCUs based on pin-out for you. It's then a matter of creating a binary that can work on both MCUs. Doesn't sound like a terrific fun job to sort out. And STMCube will sometimes not find a pin compatible device, as well.. So I'm not sure if there truly is a thing as compatibility. These chips (STM32F407 and STM32F427) still feature different dies. They may have reused the same RTL description of the F407 and only made minimal changes. Yet it is still an unique device.

For example; yesterday I was looking a STM32L431 and STM32L412 device. I want to move to L412 as its slightly lower power (different die). But I've got prototypes with the L431, so wanted to hack-mod a board to try out a risky peripheral arrangement.
I looked at which peripherals could wake-up the device from STOP2 mode. In both datasheets on page 25, the L412 lists that LPTIMx (x=1,2) can wake up the device. On L431, it lists only LPTIM1.
And yes both devices do have 2 LPTIMx's, as it does list them as a wakeup source for STOP0/STOP1 in both datasheets.

On the final prototype I will need to use LPTIM2, but I can use LPTIM1 for now. Nonetheless, I've got no idea why that discrepancy exists. Is it a datasheet error? Does the difference exist for real? Was the L412 made latter than the L431?
L412 is DIE464. L431 is DIE435. So by that numbering, it suggests L412 is newer. They could have found this silicon bug after the L431 entered production but before major release, and so perhaps they removed the feature support from the datasheet.

It does show that backwards or forwards compatibility is not guaranteed. From face value the L412 looks like identical to the L431, but with less RAM and 1 or 2 peripherals removed. I'm sure that someone has already burnt their fingers on such differences given that projects had to be retooled to different parts in the huge shortage times.

[Siwastaja]

I don't think functionally peripherals differ much. If you notice, you will download a CMSIS library for e.g. a F4 or F7 family. Although each device has its own RTL header file, I wouldn't expect there to be any differences in the bit definitions.

ST's peripherals like UART, SPI, I2C notoriously vary all over the place. Of course if you pick two devices from the same family, introduced around the same era, they are likely the same. But having used something like 10 different STM32 MCUs over the whole range, seeing the same SPI seems rare. For example, F0, F2, F4, F7, H7 all have different SPI, UART and I2C. Sure, some differences are small, but still significant.

It's mostly about improving originally nearly unusable peripherals to be less broken, but being ST, they fail at that so the next incarnation tries to fix something again. For example, on F7 SPI, variable-length slave mode did not work and the workaround required resetting the whole peripheral through RCC reset registers which feels dirty. On H7, they tried to fix exactly that, so that reset through EN bit "worked", but some corner cases (e.g., CRC enabled) still got locked in internal faulty state, so the same RCC reset workaround was still needed.

The whole thing should be doable in <500LoC of HDL and simulated for all usual use cases but ST can't do that. And being true hardware (not microcode), it can't be upgraded. So bug fixes happen through new product lines ever few years or so, but their development pattern is "let's try something and see if it sticks" agile 

And that's why we have 5-10 different SPIs, UARTs, I2C etc. You have to take that into account in firmware, but it doesn't need to be compile-time setting, you can cater for all options and choose run-time. Of course it's more work.

[peter-h]

Sticking to a UART or SPI, 8 bit, Master (probably 99% of usage), how different can they be?

I've never met anybody in my life who used a CRC feature on a UART. It is absolutely begging to make your life a misery if you need to use the code elsewhere.

And how much can a UART differ from another UART, if the RM register descriptions are the same?

As I often say, much depends on whether this is your own business, or you work for someone else. In the latter case you probably will use the CRC feature on a UART

I thought all the various ARM32 CPU licensees bought in the peripherals, in VHDL or whatever, and ST is no exception. They certainly bought in ETH and USB
https://www.synopsys.com/designware-ip/interface-ip/usb.html

What ST gives you is a product which should run for many years, unlike say Atmel who drop stuff faster than you can get around to design a new board There aren't many firms like that. Hitachi is one other.

[Siwastaja]

Of course the differences are small, like one UART has "fractional clock divider" and another a simple integral one. Control bits are in different registers, at different positions. With SPI, there's some more complexity, but if you only do simple "write 8 bits into TXDR and poll some status flag" then the only changes you would need are those status bits are at different places. So while you technically need to write a "driver" for each, it's not that much work. It still feels stupid.

I have used CRC on SPI for the obvious reason - data integrity checking - and did it for performance as it was quite high bitrate, forgot what exactly, maybe 40MHz-ish - such hardware acceleration features exist because someone needed them. Of course it won't be portable to another MCU which does not have CRC in SPI. It was before chipageddon so as usually, we design something, trusting the manufacturer can deliver as they promise.

ST has bought as you say USB, ETH and also CAN (e.g. H7 has Bosch MCAN). Still, they differ from family to family, there are many to choose from even if you outsource them! But generally these bought-in IP blocks are of better quality, and better documented, especially considering the complexity. But all the rest, UART, SPI, I2C, DMA, timers etc. are ST's own work and indeed differ from family to family.

[DavidAlfa]

The F series are 10yr+ old anyways, I'd fly away when possible.
When you start your next project, go with the G/H series and don't look back!

[peter-h]

When you start your next project, go with the G/H series and don't look back!

One risk I see, but don't know enough to quantify, is that the 407 has clearly turned out to be immensely successful but we don't know about the successors.

The 407 is the same chip as the 417; factory programmed to switch features on/off. So that's probably ok too.

The immediate successors like the 437 (64k more RAM) and probably 439 (more peripherals) are more distant although I can see the 437 being a success due to the 64k more RAM. RAM is a rare commodity in all these chips.

But a lot of the others may not be so successful. OK they do 500MHz but who needs that?

One can get a good idea from stock levels at distributors of what is selling. I've always tried to do that. Mostly it is blindingly obvious, although these will not show the large-OEM user volumes. Enter a partial P/N like STM32F417 and see what comes up. Maybe not right now because lead times are still stretched ex-covid. But the 407/417 types win by a big margin. The 437VGT6 (basically a 417VGT6 with 64k more RAM) also looks good. Go much beyond that and the volumes look smaller. Maybe because a lot of those ~500MHz chips were targeted at specific high volume OEM applications?

ST guarantee a 10 year production life (see previous link) and usually this is improved on, IME by another 5-10 years. Then you get the LTB so you can buy a lot of stock if the product is still selling.

I recall from ~30 years ago when I did 2 products.

One used an H8/300 and the LTB was around 10 years ago, so roughly 1985 to 2013 = 28 years. They were £9 but ~15 years ago I bought tens of k from US cowboy dealers for $6 Great until the ch1nks woke up to another opportunity to steal money and started making fake ones, empty package; then this trade stopped.

The other, which I did as a consultant, used an H8/500. Also started c. 1985 but was a dead duck 10 years later.

Also the benefits of not having to continually redesign are huge (if it is your own business). You can waste your time on more productive activities...

Of course if you are a hw + sw dev then the benefit is zero I recall when ROHS first arrived and a vast number of products had to be redesigned or scrapped, and vast parts stocks had to be scrapped (of course no small company did that; they just declared compliance, often using the Control & Monitoring exemption ) there were loads of devs posting in the various forums saying how wonderful an opportunity ROHS is because it "promotes innovation and creates opportunities" For every loser there are is an army of winners.

[Siwastaja]

There is nothing wrong in using "old" chips if the manufacturer is committed to producing them, either by directly guaranteeing it, or by the chip being very popular. It's not like parts are discontinued in the same order they were introduced, not at all. Some new chips will be found to sell poorly and are discontinued as soon as possible, if not sooner, while old cash cows will be manufactured for decades.

[nctnico]

The F series are 10yr+ old anyways, I'd fly away when possible.
When you start your next project, go with the G/H series and don't look back!

No, switch to NXP. Then at least you don't need different drivers for each series and have documentation that is correct. Recently I have been doing some projects with STM32 controllers and the benefits of the lower price for the chips has evaporated due to the discrepancies between documentation and actual chip behaviour. And this is for a medium (several k units) volume product.

[peter-h]

Then at least you don't need different drivers for each series

How is that possible?

Speaking of the H7, this is a way to have lots of fun
https://community.st.com/t5/stm32-mcus/dma-is-not-working-on-stm32h7-devices/ta-p/49498

[AndyC_772]

The F series are 10yr+ old anyways, I'd fly away when possible.
When you start your next project, go with the G/H series and don't look back!

I've been using STM32F4xx for years, I know them inside out, and they work well.

Looking at the specs of STM32G4xx parts in stock @ Digi-key, I see that:

- they're a bit cheaper
- Flash capacity tops out at 512k (vs 1M in F4)
- RAM capacity tops out 128k (vs 160k in F4)
- M4 core at 170 MHz (vs 168 MHz)

Begs the question, what have ST been doing all that time? Where's the big upgrade? What am I missing?

[peter-h]

I don't see any of those an upgrade for a 417 unless you are downsizing a product. Bearing in mind Mouser/Digikey pricing is about 2x of real disti pricing, some of them will be down to below 2 quid, which is nice. None have ETH but they have USB and the other usual stuff. Interesting... maybe, but given that one can get a 417 for 5 quid (1k) one won't redesign a product with a different chip to save 3 quid. The total parts cost is likely to be 50-100 quid so it can carry the 3 quid wastage, as the price of getting it to work much sooner and with well tested existing code.

It would be great to have pin- and software-compatible upgrades for the 407 (beyond the 437) but as someone said already most of these chips are not designed for Mouser/Digikey users (nobody uses these distis unless building low volumes, sub-1k); they are aimed at specific high volume OEM applications, and large users like that have the R&D resources to scrap most existing experience and start again on each project.

[nctnico]

Then at least you don't need different drivers for each series

How is that possible?

Because NXP is very strong in using the same peripherals on all their LPC series microcontrollers. I have used these for nearly 20 years and I have been able to move across the entire range without needing to rewrite much due to peripherals being completely different. Ofcourse a new peripheral has been introduced every now and then but nothing major. And NXP's documentation is super clear compared to ST's which saves a lot of time and second guessing yourself. STM32 controllers are excellent though in case you use these from a paid job where the amount of time you spend on getting software going doesn't matter. Bean counters are happy as well because you saved 20 cents on the BOM for a production run of 50 units.

[peter-h]

This is off topic but I've spent a couple of hours looking at NXP and maybe they cost maybe 20% more at Mouser but that will vanish if you are a big OEM, and say 1$ extra is irrelevant on the total parts cost (fashionably called "BOM").

For my project, we started with Atmel but quickly moved to a solution with ETH and USB, 4 serial ports, SPI, 1MB FLASH, ~200k RAM, capable of running LWIP and TLS. It was the only way forward which made any sense for the business, especially as this was going to be the last big project before I kick the bucket. I wasn't really involved in the ST choice then but in retrospect and looking at what others say I think it is all pretty similar. I would have ruled out Atmel simply because their chips remain in production as long as a whore's knickers stay up. Vast amount of time goes into going up a learning curve as soon as you are doing something nontrivial. And ETH+USB+TLS is definitely nontrivial; stuff like UART drivers becomes insignificant. All you need is some little problem and you get weeks sunk into a rabbit hole because nobody else will come and fix it for you. Someone told me TinyUSB is great (over the ST ex Cube code) but then I hear of a number of multi-week rabbit holes there too... and these are absolute bastards.

Which brings me right back to code-compatible upgrades They are priceless.

And for the 407/417 there is only the 437, and maybe a few others with extra work IF you want some funny peripherals like I2S or big LCD driving (which will need so many pins you have to redesign everything anyway; smaller LCDs can go via SPI).

[hans]

Then at least you don't need different drivers for each series

How is that possible?

Speaking of the H7, this is a way to have lots of fun
https://community.st.com/t5/stm32-mcus/dma-is-not-working-on-stm32h7-devices/ta-p/49498

Standard stuff for the Cortex-M7 with D-caches. You need to flush or discard cache lines correctly to sync up your CPU memory perspective on SRAM locations, and the actual memory that got changed by hardware. If I program on M7 and need to get something work fast, then I keep these caches disabled at first.. but it'll be a considerable performance penalty.

I don't think the G series are a replacement of F4 series I think. If any, it is more of a replacement for the F3 series. I think the G series has a similar high resolution PWM peripheral, and it has a faster M4 CPU for things like motor, DC/DC, etc. control  loops. No idea why they call them "mainstream" devices, because it looks pretty niche to me.
Perhaps the only advantage in price is only temporarily, since they will surely work as general purpose devices, but once its locked into more designs and also gets older, it will inevitably become more expensive to keep on buying.

I don't see a problem with using the F407 if it just works. Well, as long as you can get them, because its the main workhorse part of ST that got them big (along with the F103) in the ARM space. So it's good to investigate part alternatives, but that's still much different than a complete redesign.

[Siwastaja]

Standard stuff for the Cortex-M7 with D-caches. You need to flush or discard cache lines correctly to sync up your CPU memory perspective on SRAM locations, and the actual memory that got changed by hardware. If I program on M7 and need to get something work fast, then I keep these caches disabled at first.. but it'll be a considerable performance penalty.

It isn't, IMHO. Just like these high-end MCUs contain peripherals 90% you won't be using (say, JPEG codec), they include caches primarily for external memories. It doesn't mean you should be using caches "by default"; sure enough, they default OFF and need to be turned on explicitly.

For example on H7, the main SRAM is behind a 64-bit wide bus running at cpu clk / 2 (same bandwidth as cache, some more latency), and DTCM RAM is directly coupled to CPU, at CPU clock, and hence as quick as cache (with zero misses).

If you just place everything by default in flash + main AXI SRAM, the performance penalty of not enabling caches is maybe some tens of % in average case, and zero in worst case; only significant in borderline use cases. With selective placement of timing-critical functions into ITCM and timing-critical data (if nothing else, stack) in DTCM, the performance is better than with caches (same latency and bandwidth as cache, but never any misses; predictable worst-case is a plus). There is a tiny bit of learning curve with linker scripts etc. how to choose what to put where, but I think it's worth it - and then you don't need to ever look at caches and all the issues caches bring to the table, specifically difficult to predict worst case timing plus having to invalidate in correct places.

And quite frankly, I think the amount of ITCM+DTCM in STM32H7 is just huge. Timing-critical functions and data, plus some "I'm not sure if this is timing critical, it could be", fit there easily.