A peripheral's timing (UART baud, timer period) is wrong. How does the clock tree factor in?

Peripheral timing is derived from the clock tree, so the actual clock reaching the peripheral, not SYSCLK, sets its rates. A UART's baud rate is its bus clock (PCLK1 or PCLK2) divided by a baud divider; a timer's period is its timer clock divided by (PSC+1)(ARR+1); an SPI clock is PCLK divided by a prescaler. If your math assumed SYSCLK but the peripheral actually runs on an APB branch that's prescaled down, every derived rate is off by that prescaler. Two specific traps: the APB prescalers mean a peripheral often runs slower than the core, and STM32 doubles the timer clock relative to its APB bus when that bus's prescaler is greater than 1, so timer period math using the plain APB frequency is off by 2×. The debugging approach is to trace the exact path from source through PLL, the AHB prescaler, and the relevant APB prescaler to compute the true frequency at that peripheral, then redo the divider math. Wrong baud usually means wrong assumed PCLK; drifting timers can also mean running on the imprecise internal RC instead of a crystal.