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%.

[waclawek.jan]

How exactly did you measure it?

JW

[MasterT]

Across C5, document:

STLINK_V3E

Project: NUCLEO 144 H7 LEGACY

Variant: H743ZI

Revision: C - 01

Reference: MB1364

Size: A3

Date: 17-DEC-2018

Sheet: 9 of 9

Today it shows 8.04 MHz, that certainly is an indicator of clock misconfiguration in the STLINK, instead of clocking by 25 MHz stable crystal, frequency derived out of internal RC oscillator.

[Bob S]

I think @Community member​ means "what test equipment did you use to measure the frequency"? Like, how stable is the frequency reference inside your test equipment?

[MasterT]

I see what you mean, but the same measurement equipment (Hantek DSO4072C) shows correct value for nucleo-H743zi (old version, not upgraded for a year): 7.99998 MHz.

[Mike_ST]

I'm reading 8.00XYZ MHz on Agilent 53181 right now.

Latest ST-LINK firmware V3J5M2.

[MasterT]

This is probably the cause, I'm using StLink upgade utility running out of Stm32CubeIDE on Linux, and it displays V3J4M2 as a latest, right at that moment. How to get V3J5M2?

[Mike_ST]

https://www.st.com/en/development-tools/stsw-link007.html

Select V2.35.26

[TDK]

If you’re using the HSI, the calibration value CubeMX uses is wrong. 0x20 instead of 0x40. It should be fixed In the next revision.

[Mike_ST]

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,

[Tesla DeLorean]

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

[waclawek.jan]

The STLink3 is a 'F723, Clive Avogadro, There's no HSI48 in it.

The primary limitation is the USB HS PHY's PLL1:

Yes, they might've chosen 16MHz/24MHz as HSE.

But given status quo, there's nothing much which can be done. MCO1 can be selected between LSE, HSI, HSE, or PLL - and it's PLL/P, the same tap which feeds the SYSCLK itself - and as the primary selling point of STLink3 is the HS USB, there's no way it can run on HSI or HSE instead of PLL. That's it.

And HSI's guaranteed max tuning clock is 1%, so having 8.00MHz+-0.04MHz is the best one could hope for with any sophisticated fine-tuning algorithm. The inherent jitters of HSI included.

JW

[MasterT]

They already answered, that clock is selected HSI (16 MHz - F723), and 8 MHz is HSI/2. This makes me wonder, why someone would select 16-HSI if there is 25-HSE and according to picture it's supported by 101 bit settings.

I didn't get "the primary selling point of STLink3 is the HS USB" - subject line of the topic is nucleo-H743zi2, not stlink. Though, StLink here is accessory feature to make primary uCPU -> stm32H743 be fully supported. And HSE input of the H743 demands crystal stable clock be supplied from somewhere (in case local crystal is not installed for cost reduction). Not RC based, there is no point to present 8 MHz for HSE input, it's a non-sense.

[waclawek.jan]

> This makes me wonder, why someone would select 16-HSI if there is 25-HSE and according to picture it's supported by 101 bit settings.

One word, backward compatibility. Okay that's two words. There's probably too much example code out there depending on the 8MHz, even if nonprecise. And probably no-one knows, how much and where exactly this dependence exhibits itself.

ST obviously wants to use the STLink3 in all future devboards, even where it does not make sense, potentially replacing STLink2 on existing boards or making new boards for older families, potentially recycling example code.

Should compatibility be dropped, 25MHz is a bit too much to be put through a potentially relatively long track. Div 5 as said above resulting in 5MHz may be perhaps a viable option; I personally don't have problem with any other divider but I'm afraid again the ST tools and "libraries" might not cope with non-integer-MHz clocks well.

> I didn't get "the primary selling point of STLink3 is the HS USB" - subject line of the topic is nucleo-H743zi2, not stlink.

The HS USB makes sense with the 'H7 given huge FLASH and potentially even huger external FLASH required for the stripped-down Hxx0. And, as said above, there's a bigger picture to STLink itself. It would be a genuine PITA to support variants to STLink's firmware.

> And HSE input of the H743 demands crystal stable clock be supplied from somewhere (in case local crystal is not installed for cost reduction). Not RC based, there is no point to present 8 MHz for HSE input, it's a non-sense.

I do get your point and I'm not defending ST just trying to explain the reasons.

The devboards' state - and state of their documentation (eg. "we won't put schematics into RM as it's inconvenient for us" stance, "modern feel and look") clearly mark the start of ST's decline on the technical side - and unless The Bosses realize it, it will take the whole company down in no time.

JW

[waclawek.jan]

@MasterT​ 

What I wanted to say: I know you'r now disappointed (to use a nice word), but thank you for coming here and discussing the problem, at least now we are aware of it.

ST, this information is indeed an unpleasant surprise, so it should appear in all relevant places - the STLink3's manual and manuals of all devboards using it.

@Imen DAHMEN​ 

JW

[Imen.D]

Hello,

You raise interesting points and feedback.

I will raise this discussion to the appropriate team for analysis.

Best Regards,

Imen

[MasterT]

Thanks, Imen.

There may be compatibility issues across historic line of the boards. For nucleo-H743zi & H743zi2 IMHO, easy to split into two sub folders

~.arduino15/packages/STM32/hardware/stm32/1.7.0/variants/NUCLEO_H743ZI || ZI2, where clock configuration in variant.cpp would reflect actual HSE clock.

For now I brought 50 MHz from SB57 to SB45 (two pads in close proximity, jumper removed on SB45). Here is the difference:

SA is custom made, still good for "comparative analysis" as long as two pictures taken with exactly the same settings. Picture shows sine signal obtained out of DDS on H743zi2 (two DAC simultaneously 20-bits resolution).

[S C]

The 8MHz output provided on the MCO pin by the STLINK-V3 comes from the STM32F723 internal HSI, which sounds like a mistake in the product definition, I'm sorry for that. Unfortunately we can't generate this 8MHz clock from the PLLCLK without impacting the other resources behind this clock. A fine trimming of the STLINK-V3 HSI is not enough to reach the accuracy of the ST-Link/V2-1 (and won't be better than the target's internal HSI). We are evaluating instead the possibility to provide a clock derived from the 25MHz HSE (with available dividers: 1 to 5), but as long as the 8MHz value is also not possible to reach like that, most probably we will have to manage different use cases, and consequently to provide a way allowing end users to select by themselves the MCO source which better fits their needs (and the application will need to be adapted accordingly).

[waclawek.jan]

Hi @Amel NASRI​  ,

can you please check what's the progress on this issue? When can we expect an updated STLink-V3 firmware/drivers/whatever, promised by SC above?

I'd reach out directly to her/him but s/he's apparently "inactive".

Thanks,

Jan

https://community.st.com/s/question/0D53W000002gizFSAQ/stm32h7a3-unusable-for-vga

[DougGleichman]

It has been a while but I have a new NUCLEO-H723ZG board and discovered that my board has this 8.08 MHz HSE clock. I did the firmware upgrade from STM32CubeProgrammer, and that did not help.

Is there a fix?

[Pavel A.]

@DougGleichman​ As "S C" wrote above, this is because the Nucleo provides to the target STM32H7 clock based on imprecise HSI of the ST-LINK.

New ST-LINK firmware has one more option for the clock: HSE/3 which gives 25 MHz/3 = 8.333...

This one should be precise - but requires changes in all existing Nucleo examples that assume "8.0" MHz clock.