Optimal 64 MHz clock for STM32F103 ...

[RoboDurden]

@WestlingPi , @hoverboardhavoc let's continue here with this clock issue.

Indeed: >When the HSI (=high-speed internal clock signal) is used as a PLL clock input, the maximum system clock frequency that can be achieved is 64 MHz.

Please no modifications to system files like system_gd32f10x.c. I think these get easily replace while making changes to the RTE runtime enviroment ?

Better add a new Keil target and add the define there:

#ifdef __SYSTEM_CLOCK_48M_PLL_IRC8M
uint32_t SystemCoreClock = __SYSTEM_CLOCK_48M_PLL_IRC8M;

comes first, so the default 72M are ignored.

With this i get

on my Gen1 board and msTicks again verified with stop watch.
But 48MHz is not optimal anyway ? How would you achieve 64MHz ?

So i asked ChatGpt5 again:

please give me the Keil init code for STM32F103C8 to run without external oscillator at the max clock of 64 MHz In the datasheet i read: When the HSI is used as a PLL clock input, the maximum system clock frequency that can be achieved is 64 MHz.

I do not want to touch system_stm32f10x.c . And the code is also used for GD32f103, so my system file is system_gd32f10x.c Is it possible to detect at the beginning of main() that the mcu is a stm32f103 and then set the clock from the default 72 Mhz to 64 Mhz ?

This is the final code that might work for stm32f103:

#if TARGET==2		
		
	void clock_init_stm32(void)
	{
		/* 1. Enable internal 8 MHz oscillator (IRC8M = HSI) */
		RCU_CTL |= RCU_CTL_IRC8MEN;
		while((RCU_CTL & RCU_CTL_IRC8MSTB) == 0);

		/* 2. Configure Flash wait states for 64 MHz 
			 (2 wait states needed for 48–72 MHz range) */
		FMC_WS &= ~0x7;   // clear WSCNT[2:0]
		FMC_WS |= 0x2;    // 2 wait states

		/* 3. Configure PLL: IRC8M / 2 * 16 = 64 MHz */
		RCU_CFG0 &= ~(RCU_CFG0_PLLMF | RCU_CFG0_PLLSEL);
		RCU_CFG0 |= (RCU_PLLSRC_IRC8M_DIV2 | RCU_PLL_MUL16);

		/* 4. Set prescalers: 
					AHB = /1 (64 MHz), 
					APB1 = /2 (32 MHz, must be =36 MHz), 
					APB2 = /1 (64 MHz) */
		RCU_CFG0 &= ~(RCU_CFG0_AHBPSC | RCU_CFG0_APB1PSC | RCU_CFG0_APB2PSC);
		RCU_CFG0 |= (RCU_AHB_CKSYS_DIV1 | RCU_APB1_CKAHB_DIV2 | RCU_APB2_CKAHB_DIV1);

		/* 5. Enable PLL */
		RCU_CTL |= RCU_CTL_PLLEN;
		while((RCU_CTL & RCU_CTL_PLLSTB) == 0);

		/* 6. Switch system clock to PLL */
		RCU_CFG0 &= ~RCU_CFG0_SCS;
		RCU_CFG0 |= RCU_CKSYSSRC_PLL;
		while((RCU_CFG0 & RCU_SCSS_PLL) == 0);

		/* 7. Update SystemCoreClock variable */
		SystemCoreClock = 64000000UL;
	}
	uint32_t dev_id = 0;	
	uint32_t pll_mul = 0;
#endif
		
int main (void)
{
	iBug = 1;
	ConfigRead();		// reads oConfig defined in defines.h from flash
	
	#if TARGET==2
		#define DBGMCU_IDCODE   (*(volatile uint32_t*)0xE0042000)
		#define DEV_ID_MASK     0x00000FFF
		#define STM32F103_DEV   0x410   // STM32F103
		// GD32F103 will read as something else (typically 0x419)
		dev_id = DBGMCU_IDCODE & DEV_ID_MASK;		// will be 1044 for GD32F103RC
		if (dev_id == STM32F103_DEV) 
			clock_init_stm32();   // 64 MHz
		else
			SystemCoreClockUpdate();  // ensure GD32 sets 72 MHz correctly

		pll_mul = (RCU_CFG0 & RCU_CFG0_PLLMF) >> 18;  // bits differ per header, check what value you actually get		
			// will be 1 on GD32F103, should be 14 on true stm32f103.
	#else
		SystemCoreClockUpdate();
	#endif
  SysTick_Config(SystemCoreClock / 1000);	//  Configure SysTick to generate an interrupt every millisecond

	#ifdef MASTER_OR_SINGLE
		FlagStatus chargeStateLowActive = SET;
		int16_t pwmMaster = 0;
		int16_t scaledSpeed = 0;
		int16_t scaledSteer  = 0;
		float expo = 0;
		float steerAngle = 0;
		float xScale = 0;
	#endif

I get this for my 2.2.7 with gd32f103RC when i force clock_init_stm32() function:

But for 10000ms msTicks, my stop watch only gives 9 seconds.
ChatGpt then made me check pll_mul and this confirmed that for gd32f103, you still get 72M.
But for stm32f103, it should work.

Please test :-)

[WestlingPi]

Yes, the code works on my stm32f103:

I would rather use a compile time #define. I dont trust chinese clones to set or dont set dev_id = DBGMCU_IDCODE & DEV_ID_MASK; correctly...

However if I run SystemCoreClockUpdate(); after clock_init_stm32(); it thinks SystemCoreClock is 48MHz. So I am not sure if it runs on 48MHz or 64MHz...

...But from stopwatch and msTicks, I would say that it actually runs on 48MHz.

Great progress anyway this weekend! I will test more in the evening... Thanks for your effort!

[RoboDurden]

If 10000 msTicks take 10 seconds, your cpu is running on 64M.
If your mcu is running on 48MHz, then your stop watch should show 13.3 seconds for 10000 msTicks (i guess)

I did measure 9 seconds for the 10000 msTicks and chatGpt said that this was due to the gd32f103 still running at 72M.

Yes, we can add a #define STM32F103 in the defines2-2-x.h files. And if not defined, the runtime detection would step in.

The code from ChatGpt does not call SystemCoreClockUpdate for stm32f103 ! Instead it sets SystemCoreClock in that init function. I think, the SystemCoreClockUpdate is in gd32f103 library and will not work for stm32f103, i think.

[WestlingPi]

I think SystemCoreClockUpdate works for stm32f103 since stm32f103 supports a subset of gd32f103 (or maybe should be phrased as gd32f103 is compatible with stm32f103 and adds some backward compatible extensions).
SystemCoreClock is part of SysTick_Config(SystemCoreClock / 1000);...
When SystemCoreClock was hardcoded to 64M, then 30k msTicks took about 40 sec on stopwatch.
When SystemCoreClock was set by SystemCoreClockUpdate(); to 48M, then 30k msTicks took about 30 sec on stopwatch.
So I think clock is actually on 48MHz.
Also the code generated by AI looks very much like system_clock_48m_irc8m() in system_gd32f103.c with RCU_PLL_MUL12 changed to RCU_PLL_MUL16 (I have not compared super carefully though). My failed 64MHz attempt where it hung somewhere before main() was with system_clock_48m_irc8m() modified with RCU_PLL_MUL12 changed to RCU_PLL_MUL16...
I am suspecting that the current AI code actually does not succeed to modify PLLMUL due to some condition, so it probably still is set to RCU_PLL_MUL12 from system_gd32f103.c. I will debug some more...

[WestlingPi]

With AI code modified to:

		if (dev_id == STM32F103_DEV) {
			DEBUG_RCU_CFG0_Value1 = RCU_CFG0;
			clock_init_stm32();   // 64 MHz
			DEBUG_RCU_CFG0_Value2 = RCU_CFG0;
			SystemCoreClockUpdate();
		}

[RoboDurden]

**So how long do 10000 msTicks take with a stop watch for the code i posted ?

What pll_mul do you get ?**

From my chat:

At the moment i can only test your clock_init_stm32() on a gd32f103. With StmStudio i read that SystemCoreClock is indeed 64M. But when i check msTicks with a stop watch, then 10000 msTicks take 9 seconds and not 10 seconds. Can the gd32f103 not be configured to 64MHz, or is your code not working ?

Great observation 🚀 — let’s unpack what’s going on.

1. What you expected

You call clock_init_stm32() on GD32F103.

That configures IRC8M/2 × 16 = 64 MHz.

You update SystemCoreClock = 64000000UL.

Your SysTick handler (msTicks) should give 10 000 ticks ≈ 10 s.

2. What you saw

SystemCoreClock reads 64 MHz in STMStudio.

But 10 000 msTicks = 9 s → that means the tick is running too fast.

That’s about ~11% faster → the real clock is closer to 72 MHz, not 64 MHz.

3. Why this happens

On GD32F103, GigaDevice extended the PLL multipliers beyond ST’s limits:

STM32F103 PLL max multiplier = ×16

GD32F103 PLL max multiplier = ×18 (so 72 MHz even from IRC8M/2).

So when you write: RCU_CFG0 |= RCU_PLL_MUL16;

on GD32F103 with IRC8M, it does not map 1:1 to the same PLL factor as STM32. GigaDevice “shifted” the encoding of PLLMF bits to cover ×17 and ×18.

👉 In short: GD32F103 ignores your attempt to force 64 MHz and actually runs at 72 MHz.

4. How to confirm

You can read back the actual PLL multiplier from RCU_CFG0 after enabling PLL.
That will tell you if GD32 selected ×16 (→ 64 MHz) or ×18 (→ 72 MHz).

uint32_t pll_mul = (RCU_CFG0 & RCU_CFG0_PLLMF) >> 18; // bits differ per header
// check what value you actually get

5. The key difference

STM32F103: max HSI PLL = 64 MHz.

GD32F103: the hardware can push HSI PLL up to 72 MHz, so your code ends up with 72 MHz even though you think you selected 64 MHz.

That’s why your SysTick shows 9 s instead of 10 s.

✅ Conclusion

On GD32F103, you cannot reliably force 64 MHz with the same PLL settings as STM32F103.

GD32 “pretends” but actually configures a different multiplier, giving 72 MHz.

So: your clock_init_stm32() works fine on STM32F103, but on GD32 it will always run 72 MHz (unless you choose a lower PLL multiplier explicitly).

👉 Would you like me to adjust clock_init_stm32() so that on GD32F103 you really get 64 MHz (by choosing another valid multiplier, e.g. PLL×8 from 8 MHz external or PLL×16 from IRC8M/2 but capped)?

No, 72MHz is fine for GD32F103. I just wanted to check your code. With StmStudio i read pll_mul to be 1. Does this confirm your saying that GD32f103 still sets to 72MHz ?

Yes 👍 — that observation with pll_mul = 1 on GD32F103 is exactly the “gotcha” I was hinting at.

📖 On STM32F103 (reference RM0008):

RCU_CFG0[21:18] (aka PLLMF bits) encode multipliers 2…16.

Example: 0b1110 → ×16 (max).

There is no encoding for ×17 or ×18.

So when you set PLL_MUL16, you really get ×16 → HSI/2 (4 MHz) ×16 = 64 MHz.

📖 On GD32F103 (datasheet & library):

GigaDevice extended the encoding:

0b1110 = ×16

0b1111 = ×16 again (alias for STM32 compatibility)

0b0000 = ×16 (instead of ×2 like STM32!)

0b0001 = ×18 ← this is the one you saw in STMStudio.

So:

When you thought you configured ×16, the GD32 library actually wrote an encoding that maps to ×18 on GD32.

That makes your PLL output = 4 MHz × 18 = 72 MHz, not 64 MHz.

✅ Your measurement (10 000 msTicks = 9 seconds) matches exactly 72/64 = 1.125 ratio → 11% fast, confirming GD32 is at 72 MHz.
✅ Your debug readback (pll_mul = 1) means GD32 selected ×18 multiplier.

🔑 So yes:

STM32F103 → your clock_init_stm32() produces 64 MHz.

GD32F103 → same code selects ×18 → 72 MHz.

Do you want me to give you a safe runtime check inside clock_init_stm32() so it can detect whether it’s on STM32 or GD32 (based on DBGMCU_IDCODE) and set SystemCoreClock accordingly, without you needing to measure manually with SysTick?

What pll_mul will i get on a true stm32f103 ?

Great question 👌 — let’s compare carefully.

🔹 On a true STM32F103 (RM0008 reference manual)

PLL multiplier is controlled by RCC_CFGR[21:18] = PLLMUL[3:0]:

Encoding 0000 = ×2

Encoding 0001 = ×3

…

Encoding 1101 = ×15

Encoding 1110 = ×16

Encoding 1111 = ×16 (alias for compatibility)

So:

If you configure RCC_CFGR_PLLMULL16 in ST’s headers, the field actually gets written with 0b1110.

When you read it back on a real STM32F103, you’ll see pll_mul = 14 (0xE).

That really corresponds to ×16, so PLL output = 4 MHz × 16 = 64 MHz.

🔹 On a GD32F103

GigaDevice changed the encoding to allow ×17 and ×18.
So when you write the same bits, the silicon interprets them differently:

Encoding 0000 = ×16 (instead of ×2 on STM32)

Encoding 0001 = ×18

… and so on

That’s why you saw pll_mul = 1 in STMStudio on GD32 → meaning “×18” in GD32’s encoding.

✅ Answer:

On a real STM32F103, you will read back pll_mul = 14 (0xE) for ×16.

On a GD32F103, you read back pll_mul = 1 → which actually maps to ×18 = 72 MHz.

⚡ That’s the core difference: the same firmware leads to different PLL encoding values when read back, because GD32 extended the encoding.

Do you want me to give you a small function that reads pll_mul at runtime and converts it into the actual numeric multiplier (×2…×18), so you can print/log the real PLL frequency without guessing?

[WestlingPi]

I think the real problem is that the clock can not be changed when it is active or some similar condition. I.e. something like you need to change to another clock source or maybe disable PLL before changing it. I was chatting with deepseek all afternoon yesterday, and it was not able to give working code...

[RoboDurden]

• So how long do 10000 msTicks take with a stop watch for the code i posted ?
• What pll_mul do you get ?

i have come up with this code that i am testing right now for 72M and 48M on a gd32f103

  SysTick_Config(SystemCoreClock / 1000);	//  Configure SysTick to generate an interrupt every millisecond

	iTestClock = 72000000/4;	// iTestClop NOP operations would take 250 ms
	uint32_t iTimeStart = millis();
	while (iTestClock--);		// DEC + JZ = 2 operations, so 500 ms without msTicks interrupt
	iTestClock = millis()-iTimeStart;

[WestlingPi]

• So how long do 10000 msTicks take with a stop watch for the code i posted ?
• What pll_mul do you get ?

I tried your code with __SYSTEM_CLOCK_48M_PLL_IRC8M in compiler arguments so before your code starts to execute it is configured to run at 48MHz.

30000 msTicks took ~40 sec on stopwatch so 10000 msTicks should have been 13,33sec

RCC_CFGR / RCU_CFG0:

so pll_mul is: 1010

1010: PLL input clock x 12

I.e. same as set due to __SYSTEM_CLOCK_48M_PLL_IRC8M

[WestlingPi]

This code from Deepseek from yesterday I think accually managed to change PLLMUL. I will try if I can modify it:

void stm32_clock_config_to_72mhz(void)
{
    /* Define register addresses */
    #define RCC_CR        (*(volatile uint32_t *)(0x40021000U))
    #define RCC_CFGR      (*(volatile uint32_t *)(0x40021004U))
    #define FLASH_ACR     (*(volatile uint32_t *)(0x40022000U))

    /* Define bit masks for RCC_CR */
    #define RCC_CR_HSION    (1 << 0)
    #define RCC_CR_HSIRDY  (1 << 1)
    #define RCC_CR_PLLON   (1 << 24)
    #define RCC_CR_PLLRDY  (1 << 25)

    /* Define bit masks for RCC_CFGR */
    #define RCC_CFGR_PLLSRC_HSI_DIV2 (0 << 16)
    #define RCC_CFGR_PLLMUL_18       (0x10 << 18) // 16 << 18 = 0x04000000

    #define RCC_CFGR_HPRE_DIV1   (0 << 4)
    #define RCC_CFGR_PPRE1_DIV2  (0x4 << 8)  // 0x400
    #define RCC_CFGR_PPRE2_DIV1  (0 << 11)

    #define RCC_CFGR_SW_HSI      (0 << 0)
    #define RCC_CFGR_SW_HSE      (1 << 0)
    #define RCC_CFGR_SW_PLL      (2 << 0)
    #define RCC_CFGR_SWS_PLL     (2 << 2)

    #define FLASH_ACR_LATENCY_2WS (2 << 0)

    /* 0. SAFETY FIRST: Switch system clock back to HSI if it's using the PLL */
    /* Read the current clock source */
    uint32_t reg = RCC_CFGR;
    uint32_t sw = reg & 0x3;

    /* If the system clock is currently sourced from the PLL... */
    if (sw == RCC_CFGR_SW_PLL) {
        /* Switch it back to HSI */
        RCC_CFGR = (reg & ~0x3) | RCC_CFGR_SW_HSI; // Clear SW bits, set to HSI
        /* Wait until the switch is complete */
        while (((RCC_CFGR >> 2) & 0x3) != 0); // Wait for SWS to become 0 (HSI)
    }

    /* 1. Now it's safe to disable the PLL */
    RCC_CR &= ~RCC_CR_PLLON;       // Disable PLL
    /* Wait for PLL to unlock/disable. 
       NOTE: This while loop might be unnecessary or hang if the PLL was in a bad state.
       If it still hangs here, you might need to remove this wait. */
    // while(RCC_CR & RCC_CR_PLLRDY); // Use with caution

    /* 2. Enable HSI (ensure it's on) */
    RCC_CR |= RCC_CR_HSION;
    while((RCC_CR & RCC_CR_HSIRDY) == 0) { /* Wait */ }

    /* 3. Configure Flash for 72 MHz (2 wait states) */
    FLASH_ACR = FLASH_ACR_LATENCY_2WS;

    /* 4. Configure AHB, APB1, APB2 prescalers */
    RCC_CFGR &= ~(0xF << 4);   // Clear HPRE
    RCC_CFGR &= ~(0x7 << 8);   // Clear PPRE1
    RCC_CFGR &= ~(0x7 << 11);  // Clear PPRE2
    RCC_CFGR |= (RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE1_DIV2 | RCC_CFGR_PPRE2_DIV1);

    /* 5. Configure the PLL: Source = HSI/2, Multiplier = 18 */
    RCC_CFGR &= ~( (1 << 16) | (0xF << 18) ); // Clear PLLSRC and PLLMUL
    RCC_CFGR |= (RCC_CFGR_PLLSRC_HSI_DIV2 | RCC_CFGR_PLLMUL_18);

    /* 6. Enable the PLL and wait for it to lock */
    RCC_CR |= RCC_CR_PLLON;
    while((RCC_CR & RCC_CR_PLLRDY) == 0) { /* Wait */ }

    /* 7. Switch the system clock source to the PLL */
    RCC_CFGR &= ~0x3;        // Clear SW bits
    RCC_CFGR |= RCC_CFGR_SW_PLL; // Select PLL
    while((RCC_CFGR & 0xC) != RCC_CFGR_SWS_PLL) { /* Wait for SWS to become 2 */ }

    // Clean up local defines
    #undef RCC_CR
    #undef RCC_CFGR
    #undef FLASH_ACR
    // ... undef all others ...
}

[RoboDurden]

I tried your code with __SYSTEM_CLOCK_48M_PLL_IRC8M ...

Well that is not what i had in mind. And why don't you simply read pll_mul with StmStudio ?

I read iTestClock = 3376 for 72 Mhz:

uint32_t iTestClock;

	uint32_t iTimeStart = millis();
	for (volatile uint32_t i = 72000000/4; i > 0; i--);	// 72000000/4 NOP operations would take 250 ms at 72 MHz ?
	iTestClock = millis()-iTimeStart;

Next will be for 48Mhz..

[RoboDurden]

And yes. i get 0x410 as identifier for my 2.2.1 gd32f103c8 board too. So we definitely need a #define in your stm32f103 defines2_2-y.h

[WestlingPi]

Sorry, I didnt realize pll_mul was a variable in the code:

[RoboDurden]

uint32_t iTestClock = 42;

	SysTick_Config(SystemCoreClock / 1000);	//  Configure SysTick to generate an interrupt every millisecond

	uint32_t iTimeStart = millis();
	for (volatile uint32_t i = 72000000; i > 0; i--);	// 72000000 NOP operations would take 1000 ms at 72 MHz ?
	iTestClock = millis()-iTimeStart;

for 48 Mhz (__SYSTEM_CLOCK_48M_PLL_IRC8M in the Keil Target preprocessor Define) i get iTestClock = 18010 (msTicks) = 10 seconds. And indeed it took approx 18 seconds from power on to the startup melody.
So if you do not trust msTicks, then simply use stop watch.

for 72 Mhz i get iTestClock = 12004 and indeed it took 12.6 seconds on my stop watch.

12 seconds / 48 * 72 = 18 seconds 👍

I think this is the way to truly test at what clock speed the mcu is running :-)

[WestlingPi]

Now it is working:

But my modified code from deepseek is very ugly:

	void stm32_clock_config_to_72mhz(void)
{
    /* Define register addresses */
    #define RCC_CR        (*(volatile uint32_t *)(0x40021000U))
    #define RCC_CFGR      (*(volatile uint32_t *)(0x40021004U))
    #define FLASH_ACR     (*(volatile uint32_t *)(0x40022000U))

    /* Define bit masks for RCC_CR */
    #define RCC_CR_HSION    (1 << 0)
    #define RCC_CR_HSIRDY  (1 << 1)
    #define RCC_CR_PLLON   (1 << 24)
    #define RCC_CR_PLLRDY  (1 << 25)

    /* Define bit masks for RCC_CFGR */
    #define RCC_CFGR_PLLSRC_HSI_DIV2 (0 << 16)
    #define RCC_CFGR_PLLMUL_18       (0x10 << 18) // 16 << 18 = 0x04000000
		#define RCC_CFGR_PLLMUL_16 0x0380000

    #define RCC_CFGR_HPRE_DIV1   (0 << 4)
    #define RCC_CFGR_PPRE1_DIV2  (0x4 << 8)  // 0x400
    #define RCC_CFGR_PPRE2_DIV1  (0 << 11)

    #define RCC_CFGR_SW_HSI      (0 << 0)
    #define RCC_CFGR_SW_HSE      (1 << 0)
    #define RCC_CFGR_SW_PLL      (2 << 0)
    #define RCC_CFGR_SWS_PLL     (2 << 2)

    #define FLASH_ACR_LATENCY_2WS (2 << 0)

    /* 0. SAFETY FIRST: Switch system clock back to HSI if it's using the PLL */
    /* Read the current clock source */
    uint32_t reg = RCC_CFGR;
    uint32_t sw = reg & 0x3;

    /* If the system clock is currently sourced from the PLL... */
    if (sw == RCC_CFGR_SW_PLL) {
        /* Switch it back to HSI */
        RCC_CFGR = (reg & ~0x3) | RCC_CFGR_SW_HSI; // Clear SW bits, set to HSI
        /* Wait until the switch is complete */
        while (((RCC_CFGR >> 2) & 0x3) != 0); // Wait for SWS to become 0 (HSI)
    }

    /* 1. Now it's safe to disable the PLL */
    RCC_CR &= ~RCC_CR_PLLON;       // Disable PLL
    /* Wait for PLL to unlock/disable. 
       NOTE: This while loop might be unnecessary or hang if the PLL was in a bad state.
       If it still hangs here, you might need to remove this wait. */
    // while(RCC_CR & RCC_CR_PLLRDY); // Use with caution

    /* 2. Enable HSI (ensure it's on) */
    RCC_CR |= RCC_CR_HSION;
    while((RCC_CR & RCC_CR_HSIRDY) == 0) { /* Wait */ }

    /* 3. Configure Flash for 72 MHz (2 wait states) */
    FLASH_ACR = FLASH_ACR_LATENCY_2WS;

    /* 4. Configure AHB, APB1, APB2 prescalers */
    RCC_CFGR &= ~(0xF << 4);   // Clear HPRE
    RCC_CFGR &= ~(0x7 << 8);   // Clear PPRE1
    RCC_CFGR &= ~(0x7 << 11);  // Clear PPRE2
    RCC_CFGR |= (RCC_CFGR_HPRE_DIV1 | RCC_CFGR_PPRE1_DIV2 | RCC_CFGR_PPRE2_DIV1);

    /* 5. Configure the PLL: Source = HSI/2, Multiplier = 18 */
    RCC_CFGR &= ~( (1 << 16) | (0xF << 18) ); // Clear PLLSRC and PLLMUL
    RCC_CFGR |= (RCC_CFGR_PLLSRC_HSI_DIV2 | RCC_CFGR_PLLMUL_16);

    /* 6. Enable the PLL and wait for it to lock */
    RCC_CR |= RCC_CR_PLLON;
    while((RCC_CR & RCC_CR_PLLRDY) == 0) { /* Wait */ }

    /* 7. Switch the system clock source to the PLL */
    RCC_CFGR &= ~0x3;        // Clear SW bits
    RCC_CFGR |= RCC_CFGR_SW_PLL; // Select PLL
    while((RCC_CFGR & 0xC) != RCC_CFGR_SWS_PLL) { /* Wait for SWS to become 2 */ }

    // Clean up local defines
    #undef RCC_CR
    #undef RCC_CFGR
    #undef FLASH_ACR
    // ... undef all others ...
}

I think the key part is /* If the system clock is currently sourced from the PLL... */ and /* 1. Now it's safe to disable the PLL */,
I.e. first disable PLL before changing it...

I will try to modify your AI code. It looks more nice than my from Deepseek...