ST-LINK provides 8.08 MHz instead of 8.000 on new nucleo-H743ZI2.

[MasterT]

Seems there is an error in the STLink firmware (upgraded to the latest version just now), clock is off about 1%.

[MasterT]

I already says, that I'm launching StLink upgrade from Stm32CubeIDE (StLinkUpgade 3.3.1) . It comes as a "bundle". Do you mean, that I should install StLink V2.35.26 as a separate tool, standalone, and try to upgrade? I'd re-address a question to "How to correctly upgrade StLink from StmCube IDE?"

[Mike_ST]

Yes it is a separate tool.

No installation required, just download and execute the binary, and click upgrade.

I don't think it will solve your problem. As stated below, please try to modify the HSI calibration value in CubeIDE. that might be the culprit.

[Tesla DeLorean]

The STM32 Cube Programmer was bundled with older firmware, this was pointed out at the time. For the most recent firmware you should use the stand-alone tool.

If the ST-LINK/V3 is running at 25 MHz, the 8 MHz is probably from the VCO/PLL and divided down. It might review the frequency I see on my boards when I find time.

[Tesla DeLorean]

Could perhaps trim it better? Can you pull a PLL based clock off HSE?

[Tesla DeLorean]

To answer my own question, perhaps use PLL1_Q at 48 MHz, or some value you can divide to 8 MHz, like 25 -> 5 -> 40

Or 480 / 4 -> 120 / 15 -> 8

Bits 24:22 MCO1[2:0]: Micro-controller clock output 1

Set and cleared by software. Clock source selection may generate glitches on MCO1.

It is highly recommended to configure these bits only after reset, before enabling the external

oscillators and the PLLs.

000: HSI clock selected (hsi_ck) (default after reset)

001: LSE oscillator clock selected (lse_ck)

010: HSE clock selected (hse_ck)

011: PLL1 clock selected (pll1_q_ck)

100: HSI48 clock selected (hsi48_ck)

Or perhaps HSI48 is less sloppy?

[MasterT]

I download separate stlink-007, run upgrade ( StLinkUpgade 3.3.2) and was able to re-flash V3J5M2. I didn't solve an issue. I 'm pretty confident that firmware inside Stlink is set to run on internal RC clock. Crystal located close to F723 is good, 25.000+-2MHz.

HSI calibration value has nothing to do with the issue, HSI should be in shout down mode, since crystal clock is much better and installed on a board.

[Tesla DeLorean]

There is a downstream conversation about the source.

The HSI calibration is a potential issue because there are problems with the HAL library writing over factory trim settings, and also you have a clock to trim it against here.

The real problem for ST is picking a combination of multipliers/dividers to get the desired frequencies from an HSE of 25 MHz, and a core of perhaps 400 or 480 MHz, and getting those down to a usable 8 MHz. The most effective way would be to use PLL1_Q at say 120, 96 or 48 MHz

Generally speaking people have looked to avoid getting 25 MHz for Ethernet via the VCO/PLL path because the thing is too jittery. So they would pass HSE out MCO, that worked for the ST-LINK/V2 context as HSE was 8 MHz.

I wouldn't mind the ST-LINK/V3 passed out 25 or 5 MHz derived from the HSE directly, but there's probably a lot of dependencies/headaches for code that is expecting 8 MHz. Personally think it should be configurable.

[Tesla DeLorean]

The general argument in the past about using the PLL source is that while it has good long term frequency, in the short term there can be a lot of jitter (phase noise, put the scope in infinite persistence mode), and probably not something you'd want for ethernet, telco, or radio applications.

[MasterT]

"Mike_ST

an hour ago

Actions for this Feed Item Comment

Yes that might be the problem. More than the ST-LINK version.

For now, MCO on V3 is HSI/2 to keep 8MHz as for V2, but not for the best accuracy,"

Good to know. Hoped to read this in the first reply, instead of "I'm reading 8.00XYZ MHz on Agilent 53181 right now."

Since clock is out of HSI, it could be any value depends on weather condition.

[MasterT]

"I wouldn't mind the ST-LINK/V3 passed out 25 or 5 MHz derived from the HSE directly, but there's probably a lot of dependencies/headaches for code that is expecting 8 MHz. Personally think it should be configurable."

Agree, the end user has to configure HSE input anyway, so doesn't matter what frequency is exact 5 or 25 or whatsever. What is important here, is crystal based clock source . Since main stm32H743zi chip doesn't have a crystal on nucleo-H743zi2 board, the idea to supply HSE input by regenerated out of HSI (StLink-F723) DOES NOT make any sence, as H743 has its own HSI.