芯耀
169
STM32G474 的高精度定时器（HRTIM）凭借精准的计时与波形生成能力，在工业控制、电机驱动、电源管理等场景中应用广泛，retriggerable single-shot（可重触发单脉冲）计数模式是其常用的工作模式之一。但不少开发者通过 CubeMX 配置该模式时，会遇到子定时器无 PWM 输出、计数器恒为 0 的问题，本文结合 ST 官方 LAT1183 应用笔记，从实际开发场景出发，深度拆解该问题的成因，并给出可直接落地的解决办法。
资料获取：【应用笔记】LAT1183 高精度定时器中single-shot计数模式不工作
1. 问题核心现象
开发者基于 CubeMX 对 STM32G474 的 HRTIM 进行外设配置与代码生成，搭建了Master Timer+Timer B的组合配置：使能 Master Timer 与 Timer B，通过 Master Timer 的比较器事件 2 触发 Timer B 的复位与运行，同时配置 Timer B 实现 PWM 输出，并将 Timer B 的计数方式设为 retriggerable single-shot 模式。
实际调试时发现，Timer B 无任何 PWM 输出，调试模式下观察到其计数器数值始终为 0，未发生任何计数动作；而将 Timer B 的计数方式修改为 continuous（连续）模式后，其他配置保持不变，Timer B 能正常计数且 PWM 输出恢复正常，且全程 Master Timer 的计数工作无任何异常。
2. 问题根源深度分析
针对上述现象，首先排除了 retriggerable single-shot 模式本身的程序 BUG—— 对比 Timer B 在两种模式下的相关寄存器值，仅计数模式配置存在差异，其余状态均完全一致。通过将正常工作的 retriggerable single-shot 模式例程与问题工程逐一比对，最终定位问题核心为寄存器更新配置方式与 CubeMX 生成代码的执行逻辑不匹配，具体拆解为以下三点：
2.1 关键寄存器位 RSYNCU 的配置差异
HRTIM 的寄存器更新逻辑由RSYNCU 位（Re-synchronized update） 控制，该位决定了外部或软件触发的更新事件何时生效：
- 置 0：相邻定时器的更新事件或软件更新事件立即生效；
- 置 1：相邻定时器的更新事件或软件更新事件，需等待本定时器下一次 Reset/Roll-over 事件出现后才生效。
问题工程中，开发者将 Timer B 的寄存器更新配置设为 “Update taken into account on the following Reset/Roll-over event”（即 RSYNCU 置 1），而正常工作的工程配置为 “Update taken into account immediately”（即 RSYNCU 置 0），这是核心配置差异。
2.2 CubeMX 生成代码的固定执行逻辑
CubeMX 基于 HAL 库自动生成的 HRTIM 初始化代码，采用 “预加载寄存器写入 + 软件更新触发” 的固定逻辑：Timer B 的所有参数配置，会通过HAL_HRTIM_WaveformTimerConfig()函数写入预加载寄存器，随后调用HRTIM_ForceRegistersUpdate()软件更新函数，将预加载寄存器的配置同步至活动寄存器，只有同步至活动寄存器后，配置才会实际生效。
该逻辑本身无问题，但未考虑 RSYNCU 位的不同配置，单一采用软件更新触发配置生效，为后续的死循环埋下隐患。
2.3 retriggerable single-shot 模式的特性形成死循环
retriggerable single-shot 模式的核心特性是定时器无法自动启动计数，必须依靠外部触发信号（本文中为 Master Timer 的比较器事件 2）实现复位与启动。
在问题工程中，RSYNCU 置 1 导致软件更新触发的配置同步，需等待 Timer B 的 Reset/Roll-over 事件；而 Timer B 的 Reset 事件又依赖 Master Timer 的比较器事件 2，且该事件触发计数的前提是 Timer B 的复位源配置已生效（活动寄存器完成配置同步）。最终形成死循环：配置生效需 Reset 事件，Reset 事件触发计数需配置生效，导致 Timer B 的配置始终停留在预加载寄存器，活动寄存器无有效配置，计数器自然始终为 0。
而 continuous 模式下，定时器可自动启动并产生 Roll-over 事件，能触发配置同步，因此配置可正常生效，定时器工作无异常。
3. 可落地的解决方法
该问题的本质是 CubeMX 生成的初始化代码，未适配 RSYNCU 置 1 时的寄存器更新逻辑，因此解决思路为调整初始化时序：在将寄存器更新方式设为 “需等待 Reset/Roll-over 事件生效” 前，先让 Timer B 的基础配置通过 “立即生效” 的方式同步至活动寄存器，再修改更新方式，具体实操步骤如下，该逻辑既适用于 CubeMX 生成代码的修改，也适用于开发者自行编写初始化代码的场景：
- 临时修改更新配置：将 Timer B 的寄存器更新方式临时设为 “Update taken into account immediately”（RSYNCU 置 0），确保后续软件更新能让配置立即生效；
- 执行初始化并触发软件更新：调用
HAL_HRTIM_WaveformTimerConfig()完成 Timer B 所有参数的初始化写入，随后调用HRTIM_ForceRegistersUpdate()触发软件更新，此时因 RSYNCU 置 0，配置会立即从预加载寄存器同步至活动寄存器，基础配置正式生效； - 恢复原更新配置：将 Timer B 的寄存器更新方式改回业务需要的 “Update taken into account on the following Reset/Roll-over event”（RSYNCU 置 1），完成最终配置。
通过上述时序调整，既保证了 Timer B 的基础配置（如复位源、PWM 参数）正常生效，又能满足业务对寄存器更新方式的要求，从根本上打破了原有的死循环，让 retriggerable single-shot 模式下的 Timer B 能正常响应 Master Timer 的触发信号并完成计数。
4. 开发总结与建议
本次 STM32G474 HRTIM 的 retriggerable single-shot 模式不工作问题，并非定时器硬件或模式本身存在 BUG，而是工具配置与自动生成代码的适配性问题——CubeMX 在生成 HRTIM 初始化代码时，未考虑 RSYNCU 寄存器位的不同配置对更新逻辑的影响，单一采用软件更新触发配置生效，导致在特殊计数模式下出现配置无法同步的问题。ST 官方也明确表示，会在后续的 CubeMX 版本中对该部分逻辑进行针对性完善。
结合该问题，给开发者带来两点实际开发建议：
- 配置 HRTIM 特殊模式时，关注寄存器更新方式：在使用 retriggerable single-shot、one-shot 等非自动启动的计数模式时，需避免将寄存器更新方式设为 “需等待 Reset/Roll-over 事件生效” 后再执行初始化，优先保证基础配置先同步至活动寄存器；
- 调试配置类问题，优先对比寄存器状态：当遇到定时器、外设无输出的问题时，可通过调试工具对比正常工程与问题工程的寄存器值，快速定位配置差异，尤其是与更新、触发相关的寄存器位，这是最高效的问题定位方式。
此外，在自行编写 HRTIM 初始化代码时，需严格遵循 “先保证配置生效，再修改特殊寄存器配置” 的时序原则，避免因寄存器逻辑不匹配导致的功能异常。
