STM32 Timer event in foreground vs hardware Timer

[Chris Pad]

I've a colleague who is using the 32-bit timer of an STM32 to trigger and interrupt handled pin toggle rather than using the 16-bit hardware Timer on the pin that needs toggling. The frequency on that pin varies a lot in use. When I wrote bringup code I used the 16bit Timer and a prescaler and that is a very small sacrifice compared to using 32bit resolution, particularly as the more interesting frequencies are high enough to have ARR below 2^6 for a PSC value of 0.

Presuming the interrupt is of the highest priority, I can't think of a good argument other than the intelligence of the interrupt approach. Is it correct to assume that the propagation delay of the pin toggle will be constant and therefore not a source of jitter? The frequency in use doesn't get high enough for the propagation delay to limit the operating frequency.

The colleague is a software developer rather than an embedded one and I often find I know that something isn't the way I would do it, but I can't put my finger on why.

[Chris Pad]

I never actually implemented it, but I know it's supposed to be possible to have the timer clocked at 144MHz whilst the core is running at 72MHz.

[waclawek.jan]

> Setup up a 16bit Timer on a pin to be triggered by the 32bit Timer

The inter-timer (TRGO-TRGI) mechanism is poorly described by ST. It is known to include an undefined delay, and it is unknown whether running timers on different clocks (e.g. different APB buses clocked differently) does or does not introduce a variable portion of this delay (i.e. jitter).

Another method is the timer-driven-DMA-to-GPIO, again with its own sources of delays and jitter.

What do you use depends on what do you want to achieve. Flipping pins in timer interrupts is a very intuitive and very flexible method, with relatively poor timing; but for many purposes this is OK or even the optimal solution.

Contrary to what the bean counters would want, there's no one-size-fits-all in mcu.

JW

[Chris Pad]

> Contrary to what the bean counters would want, there's no one-size-fits-all in mcu.

Definitely agree with that.

I have used interrupt based pin toggles for loads of things and definitely believe it has its place. This is critical timing stepper motor control though so I'm not keen on any jitter induced by firmware written with a poor understanding of ISR based delays and any other CPU based shenanigans.

I don't have a great understanding of all the ins and outs of the ISR/bus/HAL timings, hence the question and my intuitive desire to make use of the direct Timer approach.

[Chris Pad]

I think in summary my instinct was correct and some of the reasons are:

1. If you were foolish enough to have any other interrupts with the same or higher priority you'd be subject to their full operation plus the ISR switching delay
2. If you have this as the only highest priority interrupt you would still be subject to the ISR switching delay which, particularly if the stack is involved in the ISR, could be significant (i.e. a few ticks)
3. Using the HAL to do the pin toggle would be very unwise due to the SysTick induced delays (e.g. link)
4. Sounds like triggering the 16bit Timer pins off the 32-bit timer is subject to inconsistent delays as well

Even variability in the delay giving jitter of 1 or 2 clock cycles (14 - 28ns) would completely negate any benefit of using the 32bit Timer.

[Chris Pad]

You got me interested in the link for PS2 🙂

I found this: https://metebalci.com/blog/stm32h7-gpio-toggling/

Did you have another link?

[waclawek.jan]

As Chris said, many 'F3 do have this feature, for TIM1/TIM8 and in F303xDxE also TIM15/16/17/20. This is a quite unique property of the 'F3 family, a feature not very well sold by ST.

PLL's VCO probably runs at 2x the "official" output frequency, and the system output is unconditionally scaled /2, while the TIM1/8 output can be optionally divided or not. This also explains the USB clock, which is also said to be divisible by 1.5 (i.e. the non-scaled PLL output which is "oficially" x2 is divided by 3).

JW

[waclawek.jan]

In motor control (or anything with a potential to radiate), you may actually *want* a deliberate jitter being introduced... this is then called spread spectrum... 🙂

JW

[waclawek.jan]

> Using the HAL to do the pin toggle would be very unwise due to the SysTick induced delays (e.g. link)

This is moot for purpose of our discussion, as here the following was the goal:

> The question in this post is as same as before, what is the maximum frequency of a pulse train (square wave) generated just by GPIO toggling, setting an output pin to high and low and repeating this forever ?

So there simply the presence of ISR threw out the regular train of toggling in a loop.

JW

[TDK]

Neat, I had not come across that before.

[Chris Pad]

Yes that link is investigating the maximum frequency achievable that way, but importantly they show jitter caused by SysTick and discuss turning it off.