STM32H755, is the clock too slow?

[halbeeee]

Hello everyone, I'm working on an STM32H755BI (industrial temperature range), and i'm quite disappointed by the maximum clock reachable from the system.

As can be seen, the MCU can reach up to 480MHz in the core M7 and 240MHz in the core M4.

After months of develpment, a firmware package update blocked me the VOS0 and VOS1, and in fact reading the user manual those modes are unavailable on my package, so i reduced to 300MHz and 150MHz

Today, with an update of cube MX, this error appeared in the clock tree:

And in fact by reading the datasheet APB4 is limited to 100MHz.

Reducing APB4 to 100MHZ could not be a big deal, but the real problem is that considering the clock distribution in the previous image the clock of the APB4 is the same clock of the M4 (CPU2).

Does this means that i bought a 480+240MHz and i'm forced to use it at 300+100 after more than a year of development?

[Tesla DeLorean]

>>On the other hand, there is this note in the datasheet which suggests the change was intentional

Without seeing what changed, I'd assume that relates to the 100 MHz for VOS3

Do you see a specific note that the M4 has to run at half-speed? AHB4 can be DIV1 as far as I can tell.

There is a lot of implied documentation that it is normative, but from a synchronous sense is it actually a necessity?

[Tesla DeLorean]

>>I also think that your pointed note refers to VOS3 (or at least i hope, since FCPU2 of 150MHz is allowed by cube)

That would be my read of it too.

I suspect CubeMX is applying VOS3 rules, not VOS2 rules. The gearing would look to permit 300+150 or 200+200

[Tesla DeLorean]

Me thinks it's a bug..

But I don't use CubeMX to build my clock trees.

The limits on the M4 are going to be critical path related in this context, running the transistors at 300 MHz isn't going make them run any hotter on the M7 vs M4 side of the die.

I've got Cortex-M3's running at 384 MHz on other processes, admittedly I don't have the FPU-S to contend with, but still.

Honestly I'd like to see a lot better analysis of where ALL these limitations are coming from. And what critical paths have been identified.

For example are there good reasons why 300+300, 250+250 or 240+240, etc aren't actually workable?

[TDK]

@Tesla DeLorean You are likely correct that the figure is from before the max frequency was bumped from 400 MHz to 480 MHz. Figure would be consistent with 400 MHz. Good catch on APB vs AHB, I should have caught that.

All that acknowledged, the underlying question remains the same. Datasheet clearly indicates 480/240 is possible on that chip, yet CubeMX doesn't allow it.

Underlying problem seems to be CubeMX doesn't allow VOS0 or VOS1 to be selected on STM32H755. Unclear why, probably a bug, but I could be missing something. They simply don't appear as options. No such issues on STM32H745.

[AScha.3]

The basic "problem" is the allowed temperature range : -3  vs -6 , 125° vs 85° .

When 85° , 480/240MHz max., but at 125° 300/100MHz .

see

https://estore.st.com/en/stm32h755bit3-cpn.html

https://estore.st.com/en/stm32h755bit6-cpn.html

but wrong "promises" : > M7 core operates at up to 480 MHz ..< --- only for -T6 true !!!

And with -T3 only VOS2 or 3 allowed...

[Tesla DeLorean]

>> but at 125° 300/100MHz .

Ok where do you see this? VOS2 = 300/150, VOS3 = 200/100

It's stuff like this that I find fantastically UNHELPFUL

What I'd find helpful is the critical paths in the M4 implementation, and the transistor performance expectations at 125C externally vs junction temperatures.

There are SURELY better options for derated speeds, even with the unhelpful dividers.

If we knew where ST believed the critical paths were it would be possible to characterize, observe failure, and provide adequate safety margins. Or clock gear based on  ADC_CHANNEL_TEMPSENSOR  (ADC_CHANNEL_18)

[Tesla DeLorean]

Buses at 240 and 120 MHz (readme talks of using LDO)

https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/NUCLEO-H745ZI-Q/Examples/PWR/PWR_VOS0_480MHZ

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/NUCLEO-H745ZI-Q/Examples/PWR/PWR_VOS0_480MHZ/CM7/Src/main.c#L211

Here the FMC must be accommodated also

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H745I-DISCO/Demonstrations/CM7/Src/main_menu.c#L512

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H745I-DISCO/Demonstrations/CM7/Src/main_menu.c#L574

[Pavel A.]

Please check in CubeMX/IDE: RCC settings-> System parameters -> Product revision. Is it "V"?

[AScha.3]

Sorry  Clive,

I forgot ... just a footnote:

So here they set a limit - other than the "480 MHz " ! 

+ from ds H745 : if only VOS2 or 3 allowed ->

[Pavel A.]

@AScha.3 When the MCU runs in the extended temperature condition, of course this text applies. But when it runs in "normal" conditions, nothing forbids you to set VOS0 and 480 MHz.

I've just created a new project in Cube for STM32H755BITx (x=3 or 6) and it allows to set VOS0. No problem.

The Cube itself does not limit anything. It's up to the factor that sits between the chair and the keyboard  to decide how to set up MCU power and clock in certain runtime conditions.