How Do You Use the STM32 HRTIM (High-Resolution Timer) Peripheral?

Detailed Explanation

A general-purpose STM32 timer sets PWM duty cycle by comparing a free-running counter against a compare register, once per counter tick (covered in full in configuring STM32 timers for PWM, input capture, and output compare). The edge placement resolution that approach can achieve is fundamentally limited by the timer's own counting clock: to place an edge more finely in time, the only option is to run the counter faster, and that has a hard ceiling at the MCU's maximum timer clock frequency.

HRTIM solves the same problem a different way. Behind each timing unit's counter sits a delay-line-based interpolation stage that subdivides each counter tick into many finer steps, placing PWM edges at a resolution far below one full counter period, commonly specified in the low hundreds of picoseconds on parts that support it, without needing the counter itself to run at an impractically high frequency. This matters directly for two application classes: digital power converter control loops, where finer duty-cycle resolution reduces limit-cycle oscillation and output ripple at high switching frequencies, and high-resolution motor control, where finer PWM edge placement improves current-loop precision and reduces audible switching noise.

Timing Unit Architecture

HRTIM is organized around a master timer and up to six independent timing units (commonly labelled TIMA through TIMF, though the exact count varies by part, so check the specific device's datasheet). The master timer provides a shared time base that the individual timing units can synchronize against, so multiple timing units can be started, reset, or have their outputs updated in lockstep without firmware manually coordinating separate general-purpose timers to achieve the same effect.

Each individual timing unit has its own counter, its own set of compare registers, and drives its own pair of outputs, commonly configured as complementary high-side/low-side signals with hardware dead-time insertion between them. This is what lets a single HRTIM peripheral generate every phase of a multi-phase converter, or every half-bridge of a three-phase inverter, from one coordinated peripheral rather than several independently free-running general-purpose timers that firmware has to keep in phase.

Practical Examples

A multi-phase synchronous buck converter running several interleaved phases to reduce output ripple and spread thermal dissipation needs each phase's PWM precisely phase-shifted relative to the others, commonly 360° divided by the phase count. HRTIM's master-timer synchronization lets each timing unit start its phase-shifted cycle from a common reference, keeping the phase relationship fixed in hardware rather than depending on firmware re-triggering separate timers with matched, drift-free timing on every cycle.

A high-performance BLDC or PMSM motor drive running Field-Oriented Control at a high PWM switching frequency benefits from HRTIM's finer edge resolution in the same way a digital power converter does: a control loop computing a nearly continuous duty-cycle command from continuous current feedback loses some of that precision if the actual PWM hardware can only place edges at coarse tick boundaries relative to the switching period. See driving a BLDC motor with a three-phase driver for the broader three-phase commutation context HRTIM's six-output capability is well suited to.

Design Considerations

• Confirm HRTIM's exact resolution and timing-unit count against the specific part's datasheet, not a general figure. Resolution and unit count both vary between parts, and treating a headline number from one part's documentation as universal to "STM32 HRTIM" produces a design margin calculation based on the wrong device.
• Use hardware dead-time insertion rather than firmware-timed dead time for any half-bridge output. HRTIM's per-unit configurable dead time (independently settable for rising and falling edges on parts that support it) removes both the shoot-through risk and the firmware timing jitter of software-managed dead-time insertion covered for general-purpose-timer-based half-bridges in MOSFET gate driver IC and bootstrap design.
• Plan the fault and burst-mode inputs as part of the initial design, not as an afterthought. HRTIM includes dedicated hardware fault inputs that can force outputs to a safe state (typically all outputs off) independent of firmware, a control-loop safety mechanism worth designing in from the start for any power or motor application where a stuck or slow firmware fault response would be unacceptable.
• Budget real firmware development time for HRTIM's configuration model, which is meaningfully more involved than a general-purpose timer's. The added configuration surface (per-unit dead-time, fault routing, cross-unit synchronization, burst-mode control) is the direct cost of the resolution and coordination capability HRTIM provides, and is only worth taking on when the application genuinely needs it. See the FAQ above for when a general-purpose timer remains the simpler, sufficient choice.

Common Mistakes

• Reaching for HRTIM by default on a design that doesn't need sub-timer-tick resolution or multi-output hardware synchronization. A general-purpose timer, covered in configuring STM32 timers for PWM, input capture, and output compare, is simpler to configure and sufficient for most PWM applications; HRTIM's added complexity earns its place only when the application's switching frequency, ripple, or multi-phase coordination requirement genuinely demands it.
• Assuming HRTIM is available on every STM32 part because it appears in one family's documentation. HRTIM availability, timing-unit count, and resolution are all family- and part-specific; confirm against the exact target device before committing a design to it.
• Relying on firmware-managed dead time instead of HRTIM's hardware dead-time insertion for a half-bridge output, reintroducing the shoot-through risk and timing jitter the hardware feature exists specifically to remove.
• Treating fault-input configuration as optional in a power or motor design. Leaving HRTIM's hardware fault-response paths unconfigured forfeits the peripheral's fastest available protection mechanism, forcing any fault response through firmware's inherently slower detect-and-react loop instead.