The question is old but I was wondering the same and started digging into the topic.

In an STM32 micro, not all timers implement every function. My post is based on the STM32F030 Timer 1, which is I believe the most feature packed 4 channel implementation (or at least it was a few years ago).

The timer basically acts as a counter, with various options to where the counter clock comes from, what resets it, what the period is and the counter direction. This is the base for all extra features it implements, the HAL driver refers to it as Time Base. By itself, the counter function is not related to the timer channels.

There are 1-6 channels implemented in STM32 timers. These channels can be configured either independently, or in some case, in pairs (for functions like quadrature encoder mode). A channel can be configured as either input capture, or output compare. The input capture "listens to" some event and saves the counter of the time base in the CCRx registers. The output compare compares the counter register to a set value, given in the CCRx registers.

All the simple IC/OC modes and the extra functions, like PWM input, output, Hall effect sensor interfacing, are built on top of these two modes, their respective option bits act on the various input/output multiplexers and, regarding to OC mode basically tell the hardware what action to take based on the comparator outputs (CNT = CCRx, CNT > CCRx). In this case, PWM mode lets the output mode controller return to the CNT <= CCRx state when the counter register resets (more specifically, the update event), where as in the other OC modes the output mode controller ignores this signal and can be reset by hand, or by an external signal. The output signal is the OCxREF signal which then passes through some more hardware before it gets to the output pins. If it gets output at all, because you are allowed to not connect the timer to the output pins.

The STM32 timers are complicated. They have many logical blocks and a ton of configuration registers/bits so I may have missed something or completely misread something. Please feel free to correct me.

You don't need the complexity of chained timers to achieve this on STM32. You can either use TIM_RCR for certain timers to have a Nth UEV interrupt change polarity, or you can simply implement a software counter in an UEV interrupt handler to emulate RCR.

But the most important thing is to use preloaded OC register control for correct glitch-free operation. There are two modes of preloaded control that you can use (TIM1 as an example):

1. Output in PWM mode with preloaded OC control:

TIM1_CCMR1 = TIM_CCMR1_OC1PE | TIM_CCMR1_OC1M_PWM1;

In this mode, TIM_CCR1 is preloaded, i.e. any changes to it will be applied after UEV (update event). In other words, every write operation changes the next duty cycle, not the current.

This mode is mandatory for glitch-free PWM mode operation.

2. Preloaded commutation control:

TIM1_CR2 = TIM_CR2_CCPC;

In this mode, changes to certain bits in the TIM1_CCMRx and TIM1_CCER registers are preloaded. The values programmed are applied upon COM (commutation event) which can arrive either as a trigger or via TIM1_EGR = TIM1_EGR_COMG.

This mode is required for glitch-free commutation control.

---

In your code, you change polarity via TIM2_CCER without any preloaded control enabled, hence glitches are unavoidable. It's also worth noting that your code has excessive latency due to weird statements like while(TIM2->CNT);. In correctly written code, changing polarity even without preloaded control will still give good results albeit not ideal.

The initial requirement is: The original firmware generates PWM (duty cycle 50%) and every 8 cycles inverts the signal

It's hard to come with a good solution without further details. It's unknown, for example, whether duty cycle is always fixed at 50% or should change. If it's fixed, we can come up for instance with another approach - use timer PWM mode with preloaded OC control at twice the frequency and have duty cycle alternate between 0% and 100% in a preloaded fashion. At the 8th iteration, alternation changes.

A very simplified interrupt-based example:

void tim1_up_isr(void) {
    static int n;
    if (!(++n & 7)) return; // Change polarity every 8th iteration, i.e. do not alternate
    TIM1_CCR1 ~= TIM1_CCR1; // Alternate duty cycle between 0% and 100%
}

...
TIM1_BDTR = TIM_BDTR_MOE; // Enable main output
TIM1_CCMR1 = TIM_CCMR1_OC1PE | TIM_CCMR1_OC1M_PWM1; // PWM1 mode, buffered CCR1
TIM1_CCER = TIM_CCER_CC1E; // Enable output
TIM1_DIER = TIM_DIER_UIE; // Enable UEV interrupt

The above is just an example of the preloaded PWM control concept and in no way is the most efficient code.

In the ultimate case, when duty cycle can change and on-the-fly polarity/mode change is required, the only correct way is to use both preloaded commutation control and PWM mode with preloaded OC control.

Hello @MasterLu, welcome to ST Community, Just to make things more clear for you regarding the ARR and pulse values...This is how the output compare function works; ARR sets the top value of the timer (When the timer's counter reaches this value, it resets to 0), whereas, the pulse value you set for the OC channel is compared with the counter value (when the counter reaches the pulse value, the output pin is toggled) For example, in toggle on match, if counter=pulse, the output is toggled but the counter doesn't reset until it reaches the ARR value.