Maximum external clock frequency on STM32G431CBU

[Fuchsia]

Hi all,

I am working on a project where I have a clock generated from a 25MHz crystal oscillator and multiplied by a PLL to 100MHz. I want to feed this clock directly to the HSE input of my STM32G431CBU in order to achieve a 100MHz HCLK clock, which should be ok given that the maximum acceptable frequency is 170MHz.

STM32CubeMX throws in an error saying that the clock input frequency is too high ("maximum should be 48MHz"). However according to table 55 in the datasheet (link below), the IO used for HSE input (PF0, IO structure FT_fa) should be able to function at 100MHz at speed 10 and even faster at speed 11, which are specified to be hardware limitations.

https://www.st.com/resource/en/datasheet/stm32g431c6.pdf

Can I force STM32CubeMX to just roll with it / trick it into accepting it? Is my STM32G431 just going to vaporize in a puff of smoke if I try it anyway?

Thanks!

[mƎALLEm]

Hello @Fuchsia and welcome to the ST community,

---

@Fuchsia wrote:

STM32CubeMX throws in an error saying that the clock input frequency is too high ("maximum should be 48MHz").

---

Show the error and share your ioc file.

[AScha.3]

Hi,

see ds: 5.3.7. external clock

Put in the 25M clk , HSE bypass setting, then use internal PLL to get 100M core speed.

[Andrew Neil]

---

@Fuchsia wrote:

according to table 55 in the datasheet (link below), the IO used for HSE input (PF0, IO structure FT_fa) should be able to function at 100MHz at speed 10 and even faster at speed 11

---

Those are output drive speeds - not HSE input.

As @AScha.3 showed, Table 38 is the one you need.

[Fuchsia]

Hi @mƎALLEm 

Here's the .ioc file.

@AScha.3 thanks for the feedback! I know the datasheet specifies that the maximum external clock frequency is 48MHz, however it looks like the IOs themselves can handle higher frequencies (table 55), and section 5.3.7 specifies that table 38 and figure 19 are the recommended limits, not necessarily the maximum the hardware can handle.

[AScha.3]

So you should accept the limits, if you want a reliable design.

Just for fun you can do it any way: i tried high speed by changing the core PLL mult , core running at > 200M also.

Same here: you could set in Cube the clock tree with 25M input, all settings then for 25M core speed.

Now if you input 100M instead of 25M (as you told Cube), it will run with the 100M .

(If the PLL input to the clock tree can handle it...just try, if you like experimenting. Anyway its 170M stated,

so up to 300M should be possible for the core, just have enough wait states for flash and all peripherals at lower speed.)

Just lied  a little to Cube; should work - but just for fun.

No reliable way of design.

And again: why not using the 25M clock you have anyway, then use PLL setting to get core clock you want;

but all inside given limits and it will work at full temp.range, ect. 

[mƎALLEm · Accepted solution]

Ok

As said by @AScha.3 HSE input can't exceed 48MHz.

It was already indicated under the HSE frequency field and that was indicated in the datasheet.

No relation with the maximum IO allowed speed it's related to the RCC characteristic itself.

"I want to feed this clock directly to the HSE input of my STM32G431CBU in order to achieve a 100MHz HCLK clock, which should be ok given that the maximum acceptable frequency is 170MHz."

Use this configuration over PLL with a crystal in the allowed range of HSE input: