Most commonly the +1 on the dividers: the counter ticks at f_clk/(PSC+1) and wraps every (ARR+1) ticks, so using PSC and ARR directly (without the +1) makes the period off by one tick, negligible at large counts, significant at small ones. Second, the assumed timer clock is wrong: a timer is fed from its APB bus clock, and on STM32 there's a specific quirk where, if the APB prescaler is greater than 1, the timer clock is doubled relative to the APB peripheral clock, so plugging in the bus frequency instead of the actual (doubled) timer frequency gives a 2× error. Third, the source clock itself may not be what you think (the PLL/clock-tree configuration, or running on the internal RC oscillator whose frequency has tolerance and temperature drift rather than a precise crystal). Fourth, rounding: PSC/ARR are integers, so not every target frequency is exactly achievable and you get the nearest representable period. Debug by reading back the effective clock and recomputing with the exact timer clock and the +1 terms.
Embedded Systems Fundamentals · Interview question
Your timer period is slightly off from what you calculated. What are the likely causes?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Timers & Counters
Count clock ticks to make precise time: prescaler and auto-reload set the period, and output-compare/input-capture modes generate and measure waveforms, with no CPU delay loops.