STM32F401 UART printing garbage after switching to 84 MHz PLL — same 115200 baud in CubeMX and PuTTY

Baud rate, parity, stop bits — I'd normally work through all of those, but you've already ruled them out by confirming the old binary still works on the same hardware. This one's a SystemCoreClockUpdate() omission, and I see it constantly whenever someone writes their own SystemClock_Config().

Your UART hardware is transmitting at roughly 604 kbaud right now, not 115200. That's why no baud rate you try works — the actual rate isn't any standard value.

What went wrong

The HAL calculates the baud rate divisor register (BRR) by calling HAL_RCC_GetPCLK2Freq(), which returns SystemCoreClock divided by the APB2 prescaler from the RCC registers. SystemCoreClock is a global variable that starts at 16,000,000 at device reset (HSI default) and is only updated to reflect a new clock configuration when SystemCoreClockUpdate() is explicitly called.

The CubeMX-generated SystemClock_Config() always ends with a SystemCoreClockUpdate() call. The forum snippet you pasted almost certainly left it out — it's a common omission in tutorial code. So your PLL hardware is correctly producing 84 MHz, APB2 is running at 84 MHz, but SystemCoreClock still reads 16,000,000. When MX_USART1_UART_Init() runs, it asks the HAL for the APB2 frequency, gets 16 MHz, and writes BRR = 139 to USART1->BRR. The real APB2 clock is 84 MHz, so the peripheral divides that by 139 and transmits at 84,000,000 ÷ 139 ≈ 604,000 baud.

The fix

At the end of your SystemClock_Config() — after the RCC configuration is complete and before the function returns — add:

SystemCoreClockUpdate();

That function reads the RCC configuration registers and recalculates SystemCoreClock to match what the hardware is actually doing. Every subsequent peripheral init that calls HAL_RCC_GetPCLK1Freq() or HAL_RCC_GetPCLK2Freq() will then get the right base frequency. After rebuilding, USART1->BRR should read 729 (0x2D9), which gives 84,000,000 ÷ 729 ≈ 115,226 baud — well within the ±2% framing tolerance. Your printf output will come straight back.

Quick verify

Before you rebuild, confirm the diagnosis in a debug session: add SystemCoreClock to your watch window and break right before MX_USART1_UART_Init() is called. If it reads 16,000,000 instead of 84,000,000, that's your problem. Add the missing call, rebuild, and check that SystemCoreClock is now correct before the UART init runs.

The UART explainer covers why even a small baud rate error compounds across a frame and produces garbled output — worth a read if you want to understand the ±2% tolerance. The STM32 clock tree explainer walks through the full prescaler chain from HSE to each peripheral bus if you want to make sure the rest of your clock config is solid.