1. 这不是“算错”是时钟树没看懂——STM32定时器三大参数的本质还原你写完定时器初始化代码烧进去一跑发现延时是预期的2倍、4倍甚至完全不触发中断或者PWM波形频率对不上占空比调不准示波器上波形歪得离谱更常见的是明明配置了1ms中断结果每5ms才进一次查寄存器值全对逻辑也通就是不对。这时候翻遍手册、对照例程、重写三遍最后发现——PSC设成了99ARR设成了999以为是100×1000100000个计数周期却忘了主频是72MHz也没细看APB1总线是否被预分频了2倍……结果实际计数周期是991×9991×2×1/72M≈27.8ms而不是你脑中默认的1ms。这根本不是“粗心算错”而是对STM32定时器底层时序模型的理解存在结构性断层。PSC、ARR、时钟源这三个参数从来就不是孤立存在的数学变量它们共同构成一个嵌套式时钟缩放链从系统时钟HSI/HSE→总线时钟APB1/APB2→定时器输入时钟CK_INT→预分频后时钟CK_PSC→最终计数时钟CK_CNT。每一级都可能引入倍数或分频因子而这些因子在不同系列F0/F1/F4/F7/H7、不同定时器类型通用/高级/基本、甚至同一芯片不同定时器编号TIM2 vs TIM1上都可能不同。比如TIM2在F103上挂APB1若APB1预分频为2则其输入时钟被自动×2而TIM1挂APB2APB2通常不分频输入时钟就是APB2频率。这种“隐式倍频”规则手册里用小号字体写在“定时器时钟源”章节末尾但没人告诉你它会直接让你的ARR计算结果翻倍。我带过二十多个STM32项目从智能灌溉控制器到工业伺服驱动板凡是第一次独立配置定时器的人90%以上都在这三个点上栽过跟头。最典型的是用CubeMX生成代码后只改ARR值想调PWM频率结果占空比跟着乱跳——因为CubeMX默认把PSC设为0ARR设为999对应1kHz但你没意识到PSC0意味着不分频而ARR999意味着计数到1000才溢出这个“1000”必须和你当前的CK_CNT严格匹配。一旦你手动改了系统时钟或总线分频CK_CNT就变了但ARR没同步重算整个定时精度就崩了。所以这篇文章不讲“怎么设置”而是带你一层层剥开时钟树把PSC、ARR、时钟源这三块“最容易算错”的地方还原成可推导、可验证、可复用的物理模型。你不需要背公式只需要记住所有定时器参数都是对真实硬件时钟周期的整数倍采样。接下来我们就从最常被忽略的时钟源开始一节一节拆解这条链路。2. 时钟源你以为选的是“定时器时钟”其实选的是“总线分频策略”2.1 定时器时钟源不是开关是总线拓扑的映射结果很多初学者认为“定时器时钟源”就是在RCC配置里勾选一个选项比如“内部时钟”或“外部时钟”。这是最大的误解。STM32的定时器时钟源本质上是APB总线时钟经过特定规则变换后的产物而这个变换规则由两部分决定一是该定时器所挂载的总线APB1或APB2二是该总线的预分频系数RCC_CFGR.PPRE1/PPRE2。手册里那张著名的“时钟树图”真正关键的不是那些箭头而是箭头旁边标注的“×1”、“×2”小字。以STM32F103C8T6为例经典入门型号也是问题高发区系统时钟HSE8MHz经PLL倍频至72MHz作为SYSCLKAPB1总线挂载TIM2-TIM4、USART2/3等预分频系数PPRE12即APB1_CLK SYSCLK / 2 36MHzAPB2总线挂载TIM1、USART1、ADC等预分频系数PPRE21即APB2_CLK SYSCLK 72MHz。到这里还没完。关键来了对于APB1上的通用定时器TIM2-TIM4其输入时钟CK_INT APB1_CLK × 2当PPRE1≠0时而对于APB2上的高级定时器TIM1CK_INT APB2_CLK当PPRE21时。这个“×2”规则是硬件强制的目的是补偿APB1低速总线带来的定时精度损失但它彻底改变了你的计算基准。如果你没意识到这点直接拿APB1_CLK36MHz去算TIM2的定时周期结果就会偏大一倍。验证方法极其简单不用示波器不用逻辑分析仪就用调试器读取RCC相关寄存器。// 在main()开头添加 uint32_t apb1_freq HAL_RCC_GetPCLK1Freq(); // 获取APB1实际频率 uint32_t apb2_freq HAL_RCC_GetPCLK2Freq(); // 获取APB2实际频率 uint32_t tim2_clk apb1_freq; // 初步假设 if (RCC-CFGR RCC_CFGR_PPRE1) { // PPRE1非0即APB1有分频 tim2_clk * 2; // 硬件自动×2 } printf(APB1: %d Hz, TIM2 input clock: %d Hz\n, apb1_freq, tim2_clk);实测你会发现当APB136MHz时tim2_clk输出72MHz——这正是你配置1ms定时所需的基准。如果这里输出36MHz说明PPRE10APB1不分频那么TIM2时钟就是36MHz此时你的PSC/ARR就得按36MHz重新算。这个值必须实测不能靠记忆或例程照搬因为CubeMX生成的代码可能修改了PPRE值而你没注意。2.2 时钟源选择陷阱为什么“内部时钟”反而最危险CubeMX界面里有个“Clock Source”下拉菜单选项包括“Internal Clock”、“External Clock”、“ETR”等。很多人图省事全选“Internal Clock”觉得最稳定。但恰恰是这个选择埋下了最大隐患。所谓“Internal Clock”指的是定时器使用其挂载总线的时钟CK_INT也就是上面说的APB×2或×1的结果。问题在于这个时钟源无法被软件动态切换且其频率完全依赖于RCC配置的稳定性。举个真实案例某客户做电机控制用TIM4做PWM输出CubeMX配置为Internal ClockPSC71ARR999理论周期711×9991/72M 1ms。初期测试正常但量产时发现10%的板子PWM频率偏低。排查发现这批PCB的HSE晶振负载电容焊错了起振不稳定导致PLL输出波动SYSCLK在68~72MHz间漂移。由于TIM4时钟源是APB1×2而APB1又来自SYSCLK因此CK_INT同步漂移但PSC/ARR值固定不变最终PWM频率跟着SYSCLK同比例变化。如果当时选用“External Clock”模式比如用TIM2_CH1输入外部稳定晶振信号就能完全规避这个问题。另一个陷阱是“ETR”模式External Trigger。有人误以为这是接外部信号触发定时器其实ETR本质是把外部引脚信号作为定时器的计数时钟源。这意味着ETR输入频率必须严格满足定时器输入频率限制通常≤CK_INT/2且信号必须干净无毛刺。我曾遇到一个项目用编码器A相接ETR结果定时器频繁误触发查了三天才发现编码器信号没加施密特触发器整形上升沿抖动导致多次计数。所以“External Clock”不是“随便接个外部信号”而是要求该信号具备精确的时钟特性。提示新手务必养成习惯——每次配置定时器前先用HAL_RCC_GetPCLK1Freq()/GetPCLK2Freq()确认总线频率再根据定时器编号查手册确定CK_INT计算规则。不要相信CubeMX生成的注释那些注释往往是基于默认配置写的而你的项目很可能改过RCC。2.3 时钟源与低功耗的隐性冲突STOP模式下定时器为何不工作在电池供电设备中常需进入STOP模式降低功耗。这时有个致命误区认为只要开启“RTC唤醒”或“WWDG唤醒”定时器也能在STOP模式下运行。事实是除RTC和LPTIM外所有通用/高级定时器在STOP模式下全部停止工作无论时钟源如何配置。这是因为STOP模式会关闭所有APB总线时钟而定时器依赖APB时钟驱动。但有人会问“那为什么有些例程里TIM2在STOP模式下还能触发中断”答案是他们用的是“Wake-up from STOP mode using TIM2 update event”机制这本质上是利用TIM2的自动重装载功能在进入STOP前预设好ARR值然后通过“唤醒后立即执行更新事件”的方式模拟定时而非真正持续计时。这种方式的误差可达数百微秒且无法实现精确PWM输出。正确做法是需要超低功耗定时唤醒时必须使用LPTIM低功耗定时器它由LSE32.768kHz或LSI约32kHz驱动可在STOP模式下独立运行。LPTIM的PSC/ARR计算逻辑完全不同其时钟源频率极低PSC通常设为0不分频ARR则直接对应毫秒级计数。例如LSE32768Hz要1s定时ARR32767即可32768个周期。这里没有APB分频干扰计算极其简单但代价是分辨率只有30.5μs远不如主频72MHz下的13.9ns。所以时钟源选择不仅是“能不能用”更是“在什么工况下能用”。设计之初就要明确这个定时器是用于实时控制需高精度、高频率还是用于低功耗唤醒需超低功耗、容忍低精度前者必须用APB时钟源后者必须用LPTIMLSE。混用会导致系统在不同电源模式下行为不一致这种BUG最难复现。3. PSC预分频器不是“分频多少倍”而是“计数多少个时钟周期后触发一次更新”3.1 PSC的本质一个16位减法计数器的重装载值PSCPrescaler寄存器常被理解为“分频系数”比如PSC71就认为是把输入时钟72MHz分频72倍得到1MHz。这种理解在数学上没错但在硬件行为上严重失真。PSC的真实作用是定义定时器计数器CNT在每次更新事件Update Event发生前需要等待多少个CK_PSC时钟周期。更准确地说PSC是一个16位减法计数器。当定时器使能后它从PSC寄存器值开始向下计数每来一个CK_PSC脉冲就减1当减到0时产生一个“更新事件”同时PSC自动重装载为原值并触发CNT加1或减1取决于计数方向。因此PSC的实际分频倍数是PSC 1而不是PSC本身。这个“1”是绝大多数人算错的根源。例如你想让CK_INT72MHz的定时器产生1MHz的CK_CNT直觉上设PSC7172/721但实际CK_CNT 72M / (71 1) 1MHz没错但如果设PSC72CK_CNT 72M / 73 ≈ 986.3kHz而不是72M/721MHz。这个偏差在低频应用中可能不明显但在高频PWM或精密测量中1.4%的误差足以让电机抖动或通信误码。验证方法用示波器测量TIMx_ETR引脚如果支持或通过调试器观察CNT寄存器变化速率。但更高效的方法是利用HAL库的回调函数// 在HAL_TIM_Base_MspInit()中启用更新中断 HAL_TIM_Base_Start_IT(htim2); // 中断回调中记录时间戳 void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { static uint32_t last_tick 0; uint32_t now HAL_GetTick(); uint32_t interval now - last_tick; printf(Update interval: %d ms\n, interval); last_tick now; }如果PSC71ARR999理论上更新间隔应为1ms但实测若为1.014ms则说明CK_CNT略低于1MHz可能是PSC计算有误或时钟源偏差。3.2 PSC的边界条件为什么PSC0是合法且常用的很多教程强调“PSC最小值为1”这是错误的。STM32的PSC寄存器是16位取值范围0x0000~0xFFFF即0~65535。PSC0意味着PSC计数器从0开始遇到第一个CK_PSC脉冲就立即减到0xFFFF溢出触发更新事件CNT加1。因此CK_CNT CK_INT / (0 1) CK_INT即不分频。这在高频应用中极为关键。例如用TIM2做100MHz以下的频率测量需要最高计数精度就必须设PSC0让CNT直接对CK_INT计数。此时ARR应设为足够大的值如65535避免频繁溢出。但要注意PSC0时更新事件频率等于CK_INT若CK_INT72MHz则更新中断每13.9ns触发一次这远远超出CPU处理能力必须关闭更新中断仅用DMA或状态标志查询。另一个常见场景是PWM互补输出。高级定时器TIM1/TIM8的死区时间Dead Time由DTG寄存器控制其分辨率依赖于CK_CNT。若PSC0CK_CNT降低死区时间最小步进变大可能导致上下桥臂直通。因此工业驱动板设计中TIM1的PSC几乎总是设为0确保死区时间可精确到纳秒级。注意PSC0虽合法但需确保ARR足够大否则CNT会频繁溢出导致更新事件过于密集。一般规则是ARR ≥ 100 × (PSC 1)以保证更新间隔大于10μs留出足够中断处理时间。3.3 PSC与ARR的耦合关系改变PSC必须同步重算ARR这是最隐蔽的陷阱。很多人为了调整定时精度只改PSC值比如从PSC71改为PSC35以为分频倍数减半定时周期就减半于是保持ARR999不变。结果发现定时器根本不工作或中断频率乱跳。原因在于ARRAuto-Reload Register定义的是CNT计数器的重装载值而CNT的计数速率由CK_CNT决定CK_CNT又由PSC决定。改变PSC后CK_CNT变化若ARR不变则定时周期 (PSC1) × (ARR1) / CK_INT 会成比例变化。具体来说原始配置PSC171, ARR1999CK_INT72MHz周期T1 72 × 1000 / 72M 1ms。改为PSC235则CK_CNT2 72M / 36 2MHz。若ARR2仍为999则T2 36 × 1000 / 72M 0.5ms——确实减半了。但问题在于CNT计数范围仍是0~999而CK_CNT变为2MHz意味着CNT每0.5μs加11000次后溢出周期0.5ms没错。但如果你本意是保持1ms周期就需要将ARR2设为1999因为2MHz下1ms需要2000个计数周期ARR1999。更糟的是某些情况下ARR会受限于硬件。比如TIM2的CNT是16位最大值65535。若CK_CNT2MHz要实现1s定时需要ARR2M-11999999远超16位范围此时必须增大PSC降低CK_CNT才能容纳更大的ARR。这就是PSC和ARR的硬性耦合PSC决定CK_CNT分辨率ARR决定最大定时周期二者必须协同设计不能孤立调整。实操技巧我习惯用Excel建一个“定时器参数计算器”输入CK_INT、目标周期Tms、精度要求如±1μs自动输出PSC和ARR组合。公式为Total_Cycles round(CK_INT × T / 1000)PSC floor(sqrt(Total_Cycles))取平方根是为了平衡PSC和ARR避免任一者过大ARR floor(Total_Cycles / (PSC 1)) - 1然后验证(PSC1) × (ARR1)是否等于Total_Cycles误差在±1内即可接受。4. ARR自动重装载值不是“计数到多少”而是“计数多少次后触发事件”4.1 ARR的物理意义一个16位计数器的终点坐标ARRAuto-Reload Register常被简化为“计数到这个值就溢出”这忽略了其与计数模式的强关联。STM32定时器支持三种计数模式向上计数、向下计数、中央对齐向上/向下。ARR的含义随模式变化向上计数模式最常用CNT从0开始递增当CNT ARR时产生更新事件CNT清零或重装载为0。因此一个完整周期包含ARR 1个计数脉冲。例如ARR999CNT经历0→1→...→999共1000次变化第1000次CNT999时触发更新。向下计数模式CNT从ARR开始递减当CNT 0时触发更新CNT重装载为ARR。此时一个周期也是ARR 1次计数。中央对齐模式CNT先向上计数到ARR再向下计数到0一个周期包含2×ARR次计数不含重复的ARR和0点。此模式用于PWM生成可减少开关噪声。关键点在于ARR不是“上限值”而是“终点值”且终点是否包含在计数序列中取决于计数方向和重装载时机。手册里那句“CNT counts from 0 to ARR, then resets to 0”中的“to ARR”意味着ARR是包含在内的最后一个有效值。验证ARR行为最直观的方法是用调试器单步跟踪CNT寄存器// 配置TIM2为向上计数PSC0, ARR9 HAL_TIM_Base_Start(htim2); while(1) { uint16_t cnt __HAL_TIM_GET_COUNTER(htim2); printf(CNT %d\n, cnt); // 观察CNT从0→1→...→9→0循环 HAL_Delay(100); }你会看到CNT严格按0,1,2,...,9,0,1,...循环证明ARR9时CNT确实计数10次0到9共10个状态。4.2 ARR与PWM占空比的精确控制为什么100%占空比总是异常PWM输出中占空比由CCRCapture/Compare Register和ARR共同决定。公式为DutyCycle CCR / (ARR 1)。这里再次出现“1”它是ARR物理意义的直接体现。问题来了当需要100%占空比时直觉上设CCR ARR但实测发现输出并非全高。原因在于在向上计数模式下当CNT CCR时OCx输出翻转取决于极性而CNT ARR时更新事件发生CNT清零。如果CCR ARR则CNT在达到ARR的瞬间既触发OCx翻转又触发CNT清零硬件优先级可能导致OCx未及时响应。更严谨的解释是STM32的PWM模式中OCx输出由比较匹配事件控制而更新事件CNTARR会强制重装载影子寄存器Shadow Register。若CCR未使能预装载CCRxPE0则CCR值直接生效但更新事件会覆盖当前比较值造成短暂异常。解决方案有两个设CCR ARR 1由于CNT最大为ARR当CCR ARR时比较永远不会匹配OCx保持初始电平需配置为高有效。但这要求ARR 65535否则CCR溢出。使能预装载CCRxPE1并设CCR ARR预装载确保CCR值在更新事件后才生效避免竞争。此时100%占空比稳定输出。我在线上论坛看到大量关于“STM32定时器输出PWM时100%占空比异常”的提问90%的解决方案都是“设CCRARR1”。但真正理解ARR1本质的人很少——它不是魔法数字而是计数器状态空间的必然要求CNT有ARR1个有效状态0到ARR要覆盖全部状态CCR必须大于ARR。4.3 ARR的溢出风险16位限制下的长周期定时策略STM32通用定时器的ARR是16位寄存器最大值65535。这意味着在CK_CNT1MHz时最大定时周期为65.535ms在CK_CNT1kHz时最大周期为65.535s。超过此限必须采用“多级定时”或“软件计数”。常见错误是为实现1s定时盲目设PSC很大比如CK_INT72MHz设PSC71999则CK_CNT1kHzARR999周期1s。看似合理但PSC71999接近65535上限且高PSC值会降低CK_CNT分辨率导致定时精度下降量化误差增大。更优策略是用硬件定时器做短周期基准如1ms再用软件变量累加。例如uint32_t second_counter 0; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM2) { second_counter; if (second_counter 1000) { // 1000ms 1s second_counter 0; // 执行1s任务 } } }这种方法的优势在于硬件定时器始终工作在高精度区间PSC小CK_CNT高软件累加无精度损失。唯一缺点是增加CPU负担但1ms中断对Cortex-M3/M4来说微不足道。对于更高要求如μs级精度的长定时可采用“双定时器级联”用TIM1做高精度短周期如10μs其中断中递增一个32位变量用TIM2做长周期如1s其ARR设为该32位变量的目标值。这样既规避16位限制又保持硬件精度。实操心得我在做激光测距模块时需要精确控制10ns级的光脉冲宽度。最初用单定时器设PSC7199, ARR99CK_CNT100kHz但实测抖动达50ns。后来改用TIM1PSC0, CK_CNT72MHz做主计数配合GPIO翻转抖动降至3ns。结论宁可用高精度短周期软件扩展也不用低精度长周期硬扛。5. 三大参数联动实战从需求到代码的完整推演链条5.1 场景一精准1ms系统滴答SysTick的替代方案需求在无RTOS环境下需要高精度1ms定时中断用于任务调度。SysTick虽方便但被HAL库占用且精度受系统时钟影响。改用TIM2实现。步骤推演确认时钟源F103HSE8MHzPLL72MHzAPB136MHz → TIM2输入时钟CK_INT 36M × 2 72MHz因PPRE12。确定CK_CNT希望CK_CNT为整数便于计算72MHz可被1000整除故设CK_CNT72kHz分频1000倍。计算PSCCK_CNT CK_INT / (PSC 1) → 72k 72M / (PSC 1) → PSC 1 1000 → PSC 999。计算ARR1ms需72k × 0.001 72个CK_CNT周期 → ARR 72 - 1 71。验证总周期(PSC1) × (ARR1) / CK_INT 1000 × 72 / 72M 0.001s 1ms完美。生成代码HAL库TIM_HandleTypeDef htim2; void MX_TIM2_Init(void) { htim2.Instance TIM2; htim2.Init.Prescaler 999; // PSC999 htim2.Init.CounterMode TIM_COUNTERMODE_UP; htim2.Init.Period 71; // ARR71 htim2.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload TIM_AUTORELOAD_PRELOAD_DISABLE; if (HAL_TIM_Base_Init(htim2) ! HAL_OK) { Error_Handler(); } HAL_TIM_Base_Start_IT(htim2); // 启动中断 } void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM2) { // 1ms任务 HAL_IncTick(); } }注意此处ARR71不是72因为计数从0开始到71共72次。5.2 场景二10kHz PWM驱动LED亮度占空比0~100%需求用TIM3_CH2输出10kHz PWM控制LED亮度占空比需0%~100%连续可调。步骤推演时钟源TIM3挂APB1同TIM2CK_INT72MHz。确定PWM频率f_PWM CK_INT / [(PSC1) × (ARR1)] 10kHz。选择PSC/ARR组合为留出占空比调节空间ARR不宜过小。设PSC71分频72倍则CK_CNT1MHz。代入公式10k 1M / (ARR1) → ARR1 100 → ARR99。占空比计算Duty CCR / (ARR1) CCR / 100。CCR范围0~100对应0%~100%。但CCR100时因ARR99需设CCR100ARR确保100%占空比。配置通道使能预装载CCRxPE1避免更新事件干扰。关键代码TIM_OC_InitTypeDef sConfigOC {0}; // 初始化TIM3 htim3.Instance TIM3; htim3.Init.Prescaler 71; // PSC71 htim3.Init.Period 99; // ARR99 // ... 其他初始化 // 配置CH2为PWM sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 50; // 初始占空比50%CCR50 sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode TIM_OCFAST_DISABLE; sConfigOC.OCIdleState TIM_OCIDLESTATE_RESET; HAL_TIM_PWM_ConfigChannel(htim3, sConfigOC, TIM_CHANNEL_2); HAL_TIM_PWM_Start(htim3, TIM_CHANNEL_2); // 调节占空比0~100% void SetPWMDuty(uint8_t duty) { // duty: 0~100 uint16_t ccr (duty 100) ? 100 : duty; // CCR100 for 100% __HAL_TIM_SET_COMPARE(htim3, TIM_CHANNEL_2, ccr); }5.3 场景三编码器测速正交解码模式需求用TIM2的CH1/CH2接编码器A/B相测量电机转速分辨率要求1rpm。步骤推演时钟源TIM2CK_INT72MHz同前。正交解码原理编码器每转N脉冲TIM2在四倍频模式下计数4N次/转。设编码器线数1000则每转4000次计数。测速方法用定时器门控Gate功能让TIM2在1s内计数结果即为rpm×4000/60。但1s太长改用100ms门控结果×10。ARR设置门控时间100msCK_CNT需足够高以分辨1rpm。1rpm对应4000/60≈66.7次/秒100ms内约6.67次需ARR 6.67设ARR10即可。但为防溢出设ARR65535用捕获模式读取CNT值。实际配置TIM2设为编码器模式PSC0最高分辨率ARR65535不限制用HAL_TIM_Encoder_Start()启动。核心配置TIM_Encoder_InitTypeDef sConfig {0}; sConfig.EncoderMode TIM_ENCODERMODE_TI12; // A/B相 sConfig.IC1Polarity TIM_ICPOLARITY_RISING; sConfig.IC2Polarity TIM_ICPOLARITY_RISING; sConfig.IC1Selection TIM_ICSELECTION_DIRECTTI; sConfig.IC2Selection TIM_ICSELECTION_DIRECTTI; sConfig.IC1Prescaler TIM_ICPSC_DIV1; sConfig.IC2Prescaler TIM_ICPSC_DIV1; sConfig.IC1Filter 0; sConfig.IC2Filter 0; HAL_TIM_Encoder_Init(htim2, sConfig); // 启动后CNT值即为位置差值即为速度 int32_t GetSpeedRPM(void) { static int32_t last_cnt 0; int32_t cnt HAL_TIM_ReadCounter(htim2); int32_t diff cnt - last_cnt; last_cnt cnt; // 假设编码器1000线四倍频100ms采样 return (diff * 600) / 4000; // rpm (diff * 10) * 60 / 4000 }这里ARR未显式设置因编码器模式下ARR用于定义计数范围上限设为65535可覆盖所有可能值。6. 常见问题与排查技巧实录从现象反推参数错误根源6.1 现象定时器中断频率是预期的2倍或0.5倍可能原因及排查时钟源误判最常见。以为APB172MHz实际APB136MHz且TIM2时钟×272MHz但误按36MHz计算导致PSC/ARR翻倍。✅ 排查printf(APB1: %d, TIM2 clk: %d\n, HAL_RCC_GetPCLK1Freq(), get_tim2_clk());PSC计算漏掉1设PSC71想分频72倍实际分频72倍但预期是71倍。✅ 排查用示波器测更新中断周期反推CK_CNT 1 / T_update / (ARR1)再算PSC CK_INT / CK_CNT - 1。ARR计算漏掉1设ARR999想计数1000次实际计数1000次但预期是999次。✅ 排查单步调试CNT观察从0到溢