HSI, HSE, PLL ???

[ag123]

switching to HSE swtiches completely to the external crystal. If your crystal together with the pll multipliers (m,n,p,q,r) are appropriate, most probably works.
based on this

Code: Select all

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = RCC_PLLM_DIV1;
  RCC_OscInitStruct.PLL.PLLN = 8;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV4;

assume HSE crystal is 8 mhz
using r here is based on the g0b1 clock tree diagram it seem pll R feeds SYSCLK
so SYSCLK = 8 / m * n / r = 8 / 1 * 8 / 4 ~ 16 mhz

[GonzoG]

---
So I suppose, board is running now on HSE via PLL ...
Can someone more experienced like me confirm, that it is so simple to switch MCU from HSI to HSE directly from a sketch (without modifying headerfiles etc)?

It is that simple. Just add SystemClock_Config() and it will override default stm32duino settings - there is SystemClock_Config() for each board variant defined.

And you just figured out why many boards, even those cheap ones like blue/black pills have HSE oscillator - it's more precise then HSI.

[ag123]

you can try
m = 1
n = 8
r = 1
that'd give a 64 Mhz sysclk
if you set n = 10
then u'd be running at 8 / 1 * 10 / 1 ~ 80 mhz

[STM32ardui]

I add a HAL-function to setup():

Code: Select all

uint32_t  f = HAL_RCC_GetSysClockFreq();
Serial.printf("SYSCLK: %d  Hz \n",f);

When I switch source for SYSCLK to:

Code: Select all

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

I get 8.000.000 Hz (I add dots for better reading)

Back to

Code: Select all

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

it is 16 Mhz again.

With:

Code: Select all

RCC_OscInitStruct.PLL.PLLN = 16;

it is 32 MHz.

But with

Code: Select all

RCC_OscInitStruct.PLL.PLLN = 32;

I get no output, sketch seems not to work anymore.
fVCO = 8 MHz * 32 = 256 MHz - it is inside range of 64 - 344 MHz.

Also a combination of RCC_OscInitStruct.PLL.PLLN = 16 and RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2 doesn't work.
Maximum SYSCLK seems to be 48 MHz?
Or is it a problem with flash? Do I need more wait cycles?

[ag123]

the VCO in the PLL have some limits from some central frequency I think, try to use a lower VCO frequency
the PLL R multiplier can be reduced to like div 1, then SYSCLK would simply be
e.g.
HSE = 8 mhz
m = 1
n = 8
r = 1
HSE / m * n / r = 8 / 1 * 8 / 1 = 64 mhz

in fact it is quite common the other way round as well, e.g. to set m = 8
so that the input to VCO = HSE / m = 8 / 8 ~ 1 Mhz
then n would simply be the multiplier to get the VCO output frequency
then tune the divisor R to get SYSCLK

the python script is still there if you want to play with it
viewtopic.php?t=78
it generates some m, n, p, q values that can be tried, try to select those that would target a lower VCO frequency (HSE * N / M) say about 100 mhz or less

if you use HSE and you want usb to work, then that PLL Q has to output 48 Mhz, otherwise you would need to use HSI48 for USB.
so you would need to choose a PLL Q divisor that divides down from VCO output to give 48 Mhz.
the python script does something like that.

[STM32ardui]

the VCO in the PLL have some limits from some central frequency I think

That's right. From refeence manual it is a range from 64 MHz to 344 MHz and my settings are inside this.
With another combination it also fails.
It looks like PLL-R-output is limited on 48 MHz and can't reach 64 MHz.
So I asked, if it may be a problem with flash wait states/cycles?

BTW: I can use a combination, where fVCO = 32 Mhz - so less than lower limit is possible on my board.

[ag123]

I think flash wait states isn't directly related in that way
I ran my script
viewtopic.php?t=78
and got one entry like this
FHSE: 8 m: 1 n: 30 p: 4 (RCC_PLLP_DIV4) q: 5 fusb: 48.0 fcpu: 60.0
but for this
Fvco = 8 * 30 / 1 = 240 Mhz
That is still pretty high. I think sometimes PLL fails if Fvco is too high.

That PLLP from the script is PLLR in this case - it is intended to be SYSCLK.
That script is based on F4 where PLLP goes to SYSCLK.

for stm32g0b1, PLLR (SYSCLK) output is : HSE * n / m / r = 8 * 30 / 1 / 4 = 60 Mhz

maybe try

Code: Select all

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = RCC_PLLM_DIV1;
RCC_OscInitStruct.PLL.PLLN = 8;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV1; // this goes to ADC and I2S, 60 Mhz, I'm not sure if that is too high, if it is try DIV2
RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV5; // 48mhz this goes to USB
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV4; // Fvco 240 mhz / 4 ~ SYSCLK 60 Mhz

^ for this one above I think there is still one more multiplexer to configure to tell usb to use PLLQ instead of HSI48.
If you use HSI48 instead, then I'd guess you can 'ignore' the PLLQ divisor.
e.g. you can use lower Fvco rather than to try to push it up e.g. you may like to use Fvco = 64 Mhz instead
e.g.

Code: Select all

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = RCC_PLLM_DIV1;
RCC_OscInitStruct.PLL.PLLN = 8;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV1; // this goes to ADC and I2S, 60 Mhz, I'm not sure if that is too high, if it is try DIV2
// RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV1; // this goes to USB, ignored use HSI48
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV1; // Fvco 64 mhz / 1 ~ SYSCLK 64 Mhz

generally I prefer to run USB on the crystal, less drift, less issues. Usb is fussy about 12 MHz and typically requires it to be exact.

[STM32ardui]

With these:

Code: Select all

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = RCC_PLLM_DIV1;
  RCC_OscInitStruct.PLL.PLLN = 24;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4;
  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV4;
  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV3;

fVCO = 8 MHz * 24 = 192 MHz - that's inside range of 64 - 344 MHz
PLLQ = 192 / 4 = 48 MHz - so exact for USB
PLLR = 192 / 3 = 64 MHz - so the maximum for SYSCLK

Sketch doesn't work. If I set divider for PLLR also to DIV4, I get 48 MHz SYSCLK and sketch is running.
So it can't have anything to do with USB - PLLQ is 48 MHz.


To be clear about it:
- DIV1 = divsion by one
- DIV2 = division by two, output frequency is half of input
- DIV3 = dision by three, output is 1/3 of input
...
Is this correct or are these macros something different?


The problem is another part!
I can use fVCO = 192 MHz and divider of 3 and 4, SYSCLK is 64 MHz.

But:

Code: Select all

  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV2;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;

I find AHB prescaler and APB prescaler on page 182/183 inside RM0444. No information of max. frequency.
ADC can run up to 122 MHz.

So it is a bad joke!
I can set SYSCLK to 64 MHz, but HCLK for Core, DMA, memory and AHB-bus are running with 32 MHz.

[ag123]

well, the datasheet seem to say AHB, APB can goto 64 Mhz on g0b1, so probably some variations between chips etc?

[ag123]

this problem is 'worth investigating', probably good to make a post in ST forums
https://community.st.com/
it would be an embarrassment if the datasheet claims 64 Mhz for APB, AHB, but that realities doesn't deliver that.
https://www.st.com/resource/en/datashee ... g0b1vc.pdf
But that sometimes, speeds is a matter of 'binning', i.e. some pieces may not make the cut to run those speeds.
After all AMD, Intel etc do just that, those 'tested', 'binned' to run higher speeds (overclock) are pricier.
it is a bit interesting that AHB, APB speeds isn't indicated on the diagram
e.g.

Code: Select all

RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

should work at 64 mhz, in fact it may be 'safer' to try APB at DIV2 i.e. 32 Mhz first hand, but I think AHB should have no problem running at CPU speeds.
I think AHB connects the buses to sram and flash, so that one has direct impact on cpu / processor performance. APB sometimes has 'other' issues maybe, load / caps etc? not sure about that, but that APB goes to the peripherals

I remember that for various chips AHB, APB is 'promised' for the likes of 24mhz, 32 mhz, 40 mhz etc in particular APB. some AHB can work at double APB speeds. 64 Mhz is good if true ( a notion is that if AHB can't deliver 64 Mhz, it'd be a little suspicious if it is possible to produce those 64 Mips and above benchmarks)
e.g. stm32f103c8
https://www.st.com/resource/en/datashee ... f103c8.pdf
APB2 48/72 mhz
but APB1 24/36 mhz