STM32H723: 550 MHz Is a Mode, Not a Property
May 28th, 2015 | 
Author: A datasheet headline of 550 MHz reads like a property of the part, in the same way that 1 MB of flash is a property of the part. It is not. The top frequency on this device is reachable only in a particular voltage scaling setting, that setting is bounded by the supply configuration and the temperature range, and the firmware has to ask for it explicitly during start-up. An image pulled from one board and restored onto another can therefore be complete, correct, and unable to run at the speed it was written for.
Two clock figures for one device
The same part is specified at two maximum frequencies depending on which voltage scaling mode the application selects. The lower figure is the one that holds across the whole operating envelope; the higher figure applies in the overdrive mode, which carries conditions.
| figure | mode | conditions |
|---|---|---|
| 400 MHz | standard voltage scaling | full temperature range, full supply range |
| 550 MHz | overdrive (highest voltage scaling) | restricted temperature range, particular supply configuration |
Neither number is wrong. They answer different questions. A recovery report that states only “550 MHz” has answered the marketing question and left the engineering one open, which is whether the image will run at that speed on the board it is going back onto.
What the firmware has to do to get there
Reaching the top frequency is a sequence, not a register write. The core cannot be clocked faster than the voltage scaling setting allows, and the setting cannot be raised until the regulator is ready, so the start-up code walks up through the modes in order, waiting on a status flag between steps.
| step | what changes | how the code waits |
|---|---|---|
| run at the safe frequency | core clock from the internal oscillator | nothing to wait for |
| raise voltage scaling | regulator target moves up one step | poll the ready flag |
| reconfigure the PLL | multiplier and divider for the target frequency | poll the lock flag |
| switch the system clock | core moves from oscillator to PLL output | poll the switch status |
| set flash wait states | latency matching the new frequency | none, but order matters |
That sequence is unusually legible in a disassembly. The register writes are to fixed peripheral addresses, the polling loops are short and repeated, and the PLL parameters are constants. Which is why the sequence is one of the most reliable identity signals in the whole image: it tells you the frequency the build was designed for, and it tells you the voltage mode the design assumed.
Flash latency as a cross-check
The wait-state setting is the cheapest independent confirmation. It has to match the clock frequency, and it is derived from it by a formula in the reference manual rather than chosen freely.
| observed latency | consistent with | inconsistent with |
|---|---|---|
| set for the safe frequency, never raised | a build that never uses overdrive | a design that claims 550 MHz |
| set for the top frequency | a build targeting overdrive | operation below the standard maximum |
| changed more than once at start-up | a design that ramps | a fixed-frequency design |
Where the latency value and the PLL settings disagree, one of two things has happened: the image was built for a different silicon revision with a different formula, or the image has been assembled from parts of more than one build. Both are worth stating in a report, because both change what the customer should expect on first power-up.
Why this matters more here than on a slower part
On a part with a single maximum frequency, “the clock is wrong” shows up as an obviously wrong clock. Here it shows up as something subtler, because the part will run at the reduced speed and mostly work.
| symptom on the destination board | the actual cause |
|---|---|
| application runs but misses deadlines it used to meet | built for overdrive, running in standard mode |
| intermittent faults only when warm | overdrive requested outside its temperature range |
| start-up hangs before any application code | PLL parameters assume a supply configuration the board does not have |
| runs correctly but the debug port is dead | start-up options programmed for the overdrive configuration |
The first row is the one that reaches a bench as a mystery. Nothing is broken, no bit is wrong, and the device is simply slower than the firmware assumes. On a motor control loop or an audio path that is a functional failure; on a logging application it may go unnoticed for months.
The supply configuration is part of the answer
This line of the family is fed through a linear regulator only, with the regulator output brought out for decoupling. Sibling parts in the same family add a switched-mode regulator alongside it, which changes the external component count and the start-up timing. A board built for one is not a board built for the other, and the firmware’s voltage-scaling sequence encodes which one it expects.
That is why the question “will this image run on my board” cannot be answered from the image alone. It can be answered jointly from the image and the board: the image states the mode it wants, the board states the mode it can supply.
What the delivered image contains
The return set is the full flash contents, the option bytes decoded, a disassembly with the clock initialisation identified and annotated, and a statement of the voltage mode and frequency the build targets.
The annotation is the part that earns its place. A customer receiving a hex file with no commentary has to rediscover the clock tree themselves; a customer receiving the same file with the PLL constants, the latency value and the voltage mode named has been told what the image expects of its host.
A related reading of the same silicon generation, from the angle of the external memory interface rather than the clock tree, is at STM32H725 heximal recovery. The dual-bank flash arrangement that determines where in the array this image actually sits is covered in STM32H743 flash recovery. For the same class of protection failure on a smaller member of the STM32 family, STM32F358VC flash breaking covers the read-out restrictions.
FAQ
Is the higher frequency available at every temperature? No. The overdrive mode carries a narrower temperature range than the standard mode, and the datasheet states it.
Can the part be run at the top frequency without the voltage step? No. The core clock is bounded by the voltage scaling setting, so the sequence has to be followed.
Does the image say which mode it uses? Yes, through the PLL parameters, the flash latency value and the order of the voltage-scaling writes.
Conclusion
The headline frequency belongs to a mode, and the mode belongs to a supply and a temperature range. Reading the clock initialisation out of an image recovers which mode the build assumed; comparing that against the destination board answers the question the customer actually has, which is not how fast the part can go but whether this image can go that fast where it is going.
Posted in Break IC