STM32H7 series revision: Beware of the changes!

[Berni]

This month the entire STM32H7 series of high performance ARM microcontrollers has gotten a new revision "V" So whats so special about a little bit of a chip revision?

The first thing to notice is that the max CPU clock speed has changed from 400 MHz to 480 Mhz. This is not something that commonly happens with just a revision, but ST has already changed all of its specs and datasheets to reflect this:
https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html#products

All the chips in the STM32H7 series now claim 480MHz. The front page of the datasheet claims 480MHz (With no mention of the older 400MHz). But since the revision is brand new all chips you buy from Digikey, Mouser, Farnell/Avnet... etc will be the older 400MHz revision. They are all the same partnumber with no special sufix after it so when you buy any STM32H7 in the future it will be the luck of the draw if you get the 400MHz or 480MHz version (At least until all old stocks around the world are depleted).

But it doesn't stop there. There is a pretty hefty list of changes, enough for them to write app note AN5312:
https://www.st.com/content/ccc/resource/technical/document/application_note/group1/95/22/7c/0c/57/de/4b/f9/DM00609692/files/DM00609692.pdf/jcr:content/translations/en.DM00609692.pdf

Some of the major changes are:
-Changes to the flash writing sequence
-Changes to the pinmux by adding extra alternate functions to pins
-Overhaul of a lot of USB controller registers
-ADC Now has a extra 'divide by 2' on its clock inside it, making existing clock configurations too slow
-Changes to the ADC registers (For example a value in a register that used to set the ADC to 8bit mode is now setting it to 'reserved' so likely doesn't work)

So quite a bit of existing firmware could fall on its face when run on the new revision chip. There own STM32CubeMX software that generates initialization code for you, has at the moment no way of telling it what revision chip you have so that it could set it up accordingly. Tho the HAL libraries did receive some updates for the new registers.

Call me picky but i think this is far too big of a change for a simple revision. The chip should at least get a extra suffix to the partnumber, how else do you make sure you actually buy the right one.

[Psi]

Call me picky but i think this is far too big of a change for a simple revision. The chip should at least get a extra suffix to the partnumber, how else do you make sure you actually buy the right one.

It's the same issue as you get with errata except this is added functionality.
True, it would have been better if they picked a new part number suffix but i'm not all that fussed.

Of course, i didn't order a 1000 reel from digikey only to find they don't go at 480mhz. I can imagine that would be annoying and maybe costly

[capt bullshot]

Matches my experience.
The STM32H7 series chips were heavily delayed, and the nucleo boards were (somewhat) hard to get where all the others were easily available. They admitted that the chips had issues and didn't supply you with demo boards as generously as with other STM32 series if you didn't have a particular project.
My guess, the new revision isn't just a bug fixed chip but heavily revised, which is rather unusual. I think their strategy was to keep the amount of the older revision chips in the wild low enough so they can prepare to replace them silently with the new revision if you just ask hard enough rather than provide full support for the older chips. At least that was my experience with a bunch of STM32F7 chips that had the ethernet MAC bug, they've sent us free samples of the fixed revision to replace them on the boards.

[Berni]

Yeah we had trouble getting our hands on the STM32F7 series in one of the products that used them. We had to constantly nag multiple distributors to eventually get the chips a while later, so that we could finally make our prototypes.

Tho at least we didn't hit any huge errata snags on it.

Story is repeating itself with the brand new STM32MP1 series tho. I looked around for dev boards but it was impossible to find anyone having them in stock.

[capt bullshot]

Story is repeating itself with the brand new STM32MP1 series tho. I looked around for dev boards but it was impossible to find anyone having them in stock.

Yes, of course, every brand new chip is "dangerous" in this sense. But I was told at the embedded world fair that the development of the MP1 took advantage of the H7 series development, they "simply replaced the M7 core by the A7" and I was told the chips and boards would be readily available just with the launch a few days before embedded world. If one did look around a bit, one could see hints to the MP1 maybe a year before its official launch (e.g. somewhere appearing MP1 specific drivers in linux kernels ...).
Didn't check that in detail, but they apparently had a generous supply of MP1 discovery boards at the fair.

[ogden]

Story is repeating itself with the brand new STM32MP1 series tho. I looked around for dev boards but it was impossible to find anyone having them in stock.

Right. Kinda similar story here, just different parts. Lesson is - do not rush to use components that are not mature and/or widely available, especially those coming from ST. They have hopeless support and literally worst corporate culture in the industry. Yet honestly I still "use" and suggest various kinds of stm32, but with extreme caution.

[Kjelt]

Agree that this is a large change that needs proper identification.
Esp. if there are already products using this chip they should offer a way the firmware can determine which version it is, so the companies can adjust their firmware accordingly.
Perhaps they have changed something to the 96 bit Unique Identifier or something like that ?

[ehughes]

Thanks for the heads up.   I traditional use NXP stuff but am looking at the =H7 for a new project as it has a MIPI interface.

[Scrts]

I have a feeling that the 400MHz frequency was documented on the safe side initially and they went to 480MHz after additional validation.

[Berni]

Well the datasheet does not claim that any chips before the revision can go faster than 400MHz. It claims only the latest revision chips can.

But yeah i think there is some way to find the revision number of the chip from some ID register, so it should be possible for software to detect that and adapt, but really if you ask me revisions of a MCU should all be firmware compatible, not shuffle registers around for no reason to break compatibility.

As far as the STM32MP1 goes im expecting lots of trouble with that one because its the first CPU running Linux from ST and Linux support is notoriously bad for a lot of embedded CPUs that aren't something like a Raspberry Pi. I don't care for Linux that much so the reason i wanted the dev board is to see how well it can run bare metal C code, to effectively turn it into a ridiculously fast MCU rather than a MPU its meant to be.(Tho that built in GPU is probably completely useless without Linux)

[andersm]

As far as the STM32MP1 goes im expecting lots of trouble with that one because its the first CPU running Linux from ST

No, they've had eg. the SPEAr series for a fairly long time (though most of the line has been dropped by now).

[rounin]

Of course, I just sent a PO last week for a prototype order of 50 units with an H750, that is mainly a USB product  ... timing is perfect. I would have waited a few weeks.

[rounin]

I really wish this was like automotive grade parts where the silicon revision is part of the part number  .

The revision is indicated at DBGMCU->IDCODE at least. Time to start making my code revision aware...

[Scrts]

I'd be interested to see if the older revision parts fail to run at 480MHz? It is also worth raising an official request to explain from ST.

[JPortici]

Call me picky but i think this is far too big of a change for a simple revision. The chip should at least get a extra suffix to the partnumber, how else do you make sure you actually buy the right one.

It's the same issue as you get with errata except this is added functionality.
True, it would have been better if they picked a new part number suffix but i'm not all that fussed.

Of course, i didn't order a 1000 reel from digikey only to find they don't go at 480mhz. I can imagine that would be annoying and maybe costly

I wouldn't call this just an errata revision, as it has major functionality changes and not just fixes.
When microchip does things like this it changes the partnumber, usually something as simple as adding the "A" suffix (dsPIC33FJ128GP706 was a disaster and was substituted with dsPIC33FJ128GP706A which was working but with a very different set of erratas. Or, the PIC32MZ EC that was substituted by PIC32MZ EF)

i'll add to the

[free_electron]

as long as they did it in such a way that those extra features are turned off by default no code changes should be required.

[Berni]

Well people ran the chips at 500MHz just fine, but this is overclocking that is not guaranteed by the manufacturer.

Sure id have no problem if all the new functionality was placed in new registers, or on configuration bits that used to be labeled as reserved. But the fact that the ADC now has an extra 1/2 clock divider on its input means that every firmware will run the ADC at half the speed after being put on the new revision chip. Makes no sense for such a change in a chip revision.

I haven't looked in detail at the USB part because i don't use it, I think it has a good possibility of working on the new revision if DMA was not used with it.

[Siwastaja]

I have a feeling that the 400MHz frequency was documented on the safe side initially and they went to 480MHz after additional validation.

Nope, they have actually added a new Voltage Scaling Level, meaning a boosted LDO output voltage. This has a specific turn-on algorithm.

Of course you could run it at 480MHz with the "old" core voltage, and it would most likely work out, with reduced internal signal integrity and timing margin. But they didn't just change the spec.

One strange thing I noticed in the updated reference manual is that you supposedly MUST use the LDO with this new voltage scaling level; so supplying external Vcore is only supported up to 400MHz.

[Siwastaja]

as long as they did it in such a way that those extra features are turned off by default no code changes should be required.

It seems completely fucked up. Take the ADC, for example - not only they have the new clock divider added by default, it can't be disabled at all. It's well possible that in some specific case, this can't be dealt with even with software changes. Usually you could change the PLL configuration to compensate, but still...

[PCB.Wiz]

.. the max CPU clock speed has changed from 400 MHz to 480 Mhz. ..
Some of the major changes are:
-Changes to the flash writing sequence
-Changes to the pinmux by adding extra alternate functions to pins
-Overhaul of a lot of USB controller registers
-ADC Now has a extra 'divide by 2' on its clock inside it, making existing clock configurations too slow
-Changes to the ADC registers (For example a value in a register that used to set the ADC to 8bit mode is now setting it to 'reserved' so likely doesn't work)
..
Call me picky but i think this is far too big of a change for a simple revision. The chip should at least get a extra suffix to the partnumber, how else do you make sure you actually buy the right one.

Yes, purchasing managers will eat ST alive over that.
Anything that improves speed is fine, but ANY stuff that breaks existing code, is very much a no-no !!
Other vendors add a rev suffix into the order code, even for minor errata, but they are more automotive focused.
That said, you would not expect ST to be this slack/lazy. They should know this stuff.

[Scrts]

.. the max CPU clock speed has changed from 400 MHz to 480 Mhz. ..
Some of the major changes are:
-Changes to the flash writing sequence
-Changes to the pinmux by adding extra alternate functions to pins
-Overhaul of a lot of USB controller registers
-ADC Now has a extra 'divide by 2' on its clock inside it, making existing clock configurations too slow
-Changes to the ADC registers (For example a value in a register that used to set the ADC to 8bit mode is now setting it to 'reserved' so likely doesn't work)
..
Call me picky but i think this is far too big of a change for a simple revision. The chip should at least get a extra suffix to the partnumber, how else do you make sure you actually buy the right one.

Yes, purchasing managers will eat ST alive over that.
Anything that improves speed is fine, but ANY stuff that breaks existing code, is very much a no-no !!
Other vendors add a rev suffix into the order code, even for minor errata, but they are more automotive focused.
That said, you would not expect ST to be this slack/lazy. They should know this stuff.

ST, by the way, is also a major automotive microcontroller supplier.

[rew]

as long as they did it in such a way that those extra features are turned off by default no code changes should be required.

Agreed! But that's not the case here: For example, the "ADC is 8 bit" configuration has moved from codeword 4 to codeword 7 (100 to 111 in binary). That's what "reserved" is for in the documentation: you can upgrade without requiring changes to the firmware.

Similarly, the ADC now has an extra "divide by two" inside. If that had been enabled by a configuration register bit that is documented "reserved" in the old version: No problem. But here you have to rethink your clocking strategy and arrange a 2x higher clock input to the ADC module.

[Jope]

I've just got an email from Digikey with a "Part Life Notification" for the STM32H7 Nucleo board I bought a while ago, stating that the status of this board has changed to obsolete. The ST part number is "NUCLEO-H743ZI".
On the ST website there is information about a second H743 board, part number "NUCLEO-H743ZI2", which is not yet available.
I guess this board comes with the new chip.

[lucazader]

It also looks like they are planning to release a few new H7 chips in the near future.

Int he release notes for the latest HAL in the STM32CubeMX,
From what i can see they will be the H7x7 or H7x5 series (no idea what extras they will provide)
And i did see some mention of a dual core part somewhere, but cant find the info now.

[rounin]

I asked digikey if the new stock of STM32H750VBT6 coming in a few weeks is new revision, they said they won't know until it arrives, but they'll do rev specific orders if they have stock and I note it on the order. Filled out a contact form on ST's website about rev V availability & logistics, got a pushoff to my local sales channels .

I need to bribemake friends with a sales guy I guess to find out.