How Do You Configure STM32 Timers for PWM, Input Capture, and Output Compare?

Detailed Explanation

STM32 general-purpose timers (TIM2–TIM5, TIM9–TIM14, and similar, depending on the specific family — see the STM32 family selection guide for which timers each series includes) are built around a single free-running counter shared by up to four independent channels. What makes the peripheral flexible is that each channel can be configured into one of three fundamentally different roles, all built on the same counter-and-compare-register hardware:

• PWM mode generates an output signal — the channel's pin goes high or low based on comparing the running counter against the channel's Capture/Compare Register (CCR), producing a fixed-frequency signal whose duty cycle is set by where CCR sits relative to the Auto-Reload Register (ARR). See PWM frequency and duty cycle explained for the underlying ARR/CCR/prescaler relationship, which this page assumes as background.
• Output compare mode is PWM's more general sibling: instead of always producing a repeating waveform, the pin (or nothing, if no pin is used) toggles, sets, clears, or generates an interrupt at the exact instant the counter reaches the CCR value — useful for one-shot timed events, not just periodic waveforms.
• Input capture mode runs the same hardware in reverse: instead of the timer driving a pin, an external signal drives the timer. The instant a configured edge (rising, falling, or both) arrives on the channel's input, the current counter value is automatically latched into the channel's CCR register — which is how a timer measures an incoming signal's frequency or pulse width without the CPU having to poll a GPIO pin in a tight loop.

All three modes share the same clock-tree dependency: the timer's counting rate depends on its input clock and prescaler exactly as covered in how the STM32 clock tree works — including the timer-clock-doubling behaviour on some bus configurations that page describes, which affects the tick-to-time conversion for every mode on this page equally.

PWM Mode

PWM mode is the most commonly used of the three and is covered at the conceptual level in PWM frequency and duty cycle explained. On STM32 specifically, CubeMX configures a channel for PWM by setting its mode to "PWM Generation CHx" in the timer's peripheral view, after which firmware starts it with:

HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);
__HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, new_duty_ticks);

Two PWM sub-modes exist (PWM1 and PWM2), differing only in whether the output is active while the counter is below or above the CCR value — PWM1 is the conventional choice for "higher CCR value means higher duty cycle" behaviour; PWM2 inverts that relationship. Most designs use PWM1 and invert the duty-cycle calculation in software if the opposite polarity is needed, rather than relying on PWM2's inverted semantics being obvious to a future maintainer.

Output Compare Mode

Output compare is configured similarly but with a mode selection of Toggle, Active, Inactive, or Frozen (no pin action, interrupt/DMA only) for each channel. The distinguishing behaviours:

• Toggle flips the pin state on every compare match — useful for generating a square wave via software-managed CCR updates, but note that a full output cycle requires two toggles, so the output frequency is half the compare-match rate (see the FAQ above for the common mistake this causes).
• Active/Inactive forces the pin to a fixed high or low state on match — typically used for one-shot timed pin events rather than repeating waveforms.
• Frozen (no output pin) generates the compare-match interrupt or DMA request with no pin action at all — the common configuration when a timer channel is being used purely as a precise, hardware-timed interrupt source (a periodic task trigger, for example) rather than to drive a physical signal.

One-pulse mode is a specific output-compare configuration where the timer counts once from a trigger event to its ARR value and then stops automatically, producing exactly one pulse of a precisely controlled width and delay — useful for a single timed trigger pulse (camera shutter, ultrasonic sensor trigger) without firmware needing to manually start and stop the timer around the pulse.

Input Capture Mode

Input capture configures a channel's pin as a timer input rather than an output. CubeMX setup selects the channel's polarity (rising edge, falling edge, or both edges) and an input filter (a digital debounce/noise-rejection setting that requires a configurable number of consecutive samples to agree before an edge is accepted — useful for a noisy or slow-edged input signal).

HAL_TIM_IC_Start_IT(&htim3, TIM_CHANNEL_1);

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) {
  if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) {
    uint32_t captured = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1);
    // compute delta against the previous captured value
  }
}

Frequency measurement: capture on a single edge polarity (typically rising) and compute the tick delta between consecutive captures — see the FAQ above for the full conversion to a frequency in Hz, including the overflow-handling subtlety for signals slow enough that the timer counter wraps around between edges.

Pulse-width / duty-cycle measurement: capture both edges, either by configuring one channel for both-edge capture (where available) or, more commonly, pairing two channels internally connected to the same input pin — one triggered on the rising edge and one on the falling edge, a configuration STM32 timers support directly via the channel's input selection (IC1 and IC2 both mapped to TI1, for example) specifically to make duty-cycle measurement a single-timer operation rather than needing two independent timers.

Timer Encoder Mode

STM32 general-purpose timers also support a dedicated encoder mode, a specialised configuration that automatically decodes a quadrature signal's direction and position into the counter register in hardware, without firmware needing to interpret the A/B channel phase relationship itself. This is a distinct, purpose-built mode from general input capture — see rotary and quadrature encoder interfacing for the full treatment of encoder mode specifically, including how it compares to a software ISR-based decoding approach.

CubeMX and HAL Setup Workflow

1. In CubeMX's Pinout view, assign the desired timer channel pins — each TIMx channel maps to a specific set of alternate-function pins per the datasheet's pinout tables, and only those specific pins support that channel.
2. In the timer's Configuration view, set the overall timer parameters (prescaler, counter period/ARR) that apply to all its channels, then set each channel's individual mode (PWM Generation, Output Compare, Input Capture, or Encoder Mode) under its own settings.
3. CubeMX generates a TIM_HandleTypeDef and the associated MX_TIMx_Init() function; firmware starts the desired channel(s) with the matching HAL start function (HAL_TIM_PWM_Start, HAL_TIM_OC_Start, HAL_TIM_IC_Start_IT, etc.) and, for input capture or output compare, implements the relevant HAL callback (HAL_TIM_IC_CaptureCallback, HAL_TIM_OC_DelayElapsedCallback) to act on each event. See how to configure STM32 peripherals in CubeMX for the general CubeMX-to-HAL workflow this follows.
4. For interrupt-driven capture or compare, confirm the timer's interrupt is enabled and correctly prioritised in NVIC — see STM32 NVIC interrupt priority configuration for how timer interrupt priority interacts with other peripheral interrupts on the same system.

Design Considerations

• Confirm the actual timer input clock before calculating capture math or PWM frequency. The timer clock is not always the same as the APB bus clock it's attached to — see how the STM32 clock tree works for the doubling behaviour that catches many designs.
• Choose PWM mode over output-compare toggle mode for straightforward duty-cycle-controlled waveforms — toggle mode's half-frequency behaviour and manual CCR-update requirement make it a less direct tool for this than PWM mode's built-in duty-cycle semantics.
• Use interrupt- or DMA-driven capture for anything with real timing requirements, not polling — see the FAQ above for why a busy CPU can silently miss a polled capture event.
• Account for counter overflow in any capture-based measurement of a slow or intermittent signal. A timer with a 16-bit counter (most general-purpose STM32 timers) wraps around relatively quickly at a fast tick rate; track the update (overflow) interrupt alongside capture events for any signal whose period could plausibly exceed one counter period.
• Zeus Design's embedded firmware team implements timer-based PWM, capture, and precision-timing firmware as part of STM32 embedded firmware development for production hardware.

Common Mistakes

• Assuming output-compare toggle mode produces a signal at the compare-match interrupt rate — it actually produces one at half that rate, since a full cycle needs two toggles (see the FAQ above).
• Mapping a timer channel to a GPIO pin that isn't actually one of that channel's valid alternate-function options — each TIMx channel has a fixed, family-specific set of pins it can be routed to; CubeMX's pinout conflict warnings catch this, but only if the channel and pin are actually cross-checked against the datasheet's alternate-function table rather than assumed.
• Forgetting the timer-clock-doubling behaviour when calculating expected PWM frequency or capture timing — the same clock-tree subtlety covered on the STM32 clock tree page applies directly to every timer-based calculation on this page.
• Polling for a captured value on a signal fast enough that events can be missed between poll checks — use interrupt- or DMA-driven capture instead for any input whose rate isn't guaranteed slow relative to the rest of the firmware's loop timing.
• Not handling counter overflow in a frequency or pulse-width calculation for a slow input signal, producing a silently wrong result whenever the timer wraps around between two capture events rather than an obviously broken one.