PWM center aligned to half-period of TIM

[Thoufiel]

I am using the STM32H562ZGT to generate center-aligned PWM with TIM1.

Since I also want to use TIM1 for 20kHz periodic interrupts, I set the Period so that overflow/underflow occurs every 40kHz and set the Repetition Count to 1. This ensures that UEV occurs at the underflow timing every 20kHz, which I confirmed to be working as expected by combining an oscilloscope and GPIO Output.

Here, I want to set the center alignment of the PWM to High based on the overflow timing (which is offset by 40kHz from the above interrupt) rather than the underflow timing. However, when I used PWM mode 2 and observed the PWM output on the oscilloscope, the High period was 0.6-0.7 microseconds earlier than expected.

For example, with TIM1 generating 40kHz using 6249 counts at 250MHz, if I specify CH1 to be active at 3124 counts or more, the time from the underflow interrupt to PWM active was 11.8 microseconds. Ideally, this should be around 12.5 microseconds, which is almost 50% Duty.

If you have any insights into potential oversights or causes of this issue, or any other ideas for achieving center alignment, please let me know.

[waclawek.jan]

> time from the underflow interrupt to PWM active was 11.8 microseconds

Did you take into account the interrupt latency?

JW

[Thoufiel]

Thank you for suggestion.

I overlooked the consideration of interrupt latency.

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

According to this guide, the Cortex-M3 has an interrupt latency of 12 cycles.

Assuming similar values for other M-series processors, and considering the M33, the latency would be approximately the same.

I am concerned that when driven at 250 MHz, the latency is 0.048 μsec, an order of magnitude different from the 0.6-0.7 μsec range I had expected.

(Since I/O is switched at the beginning of the interrupt handler function TIM1_UP_IRQHandler, I do not expect any significant impact on clock cycle consumption..)

[waclawek.jan]

> Assuming similar values for other M-series processors, and considering the M33, the latency would be approximately the same.

I am not interested in M33 but wouldn't be surprised if that number would be higher (it *is* different for different Cortex-Mx) . Not orders of magnitude, though, but given M33 is more complex than M3/M4 (among other things due to "safety" features which are unnecessary for the vast majority of applications, but such is life, they are pushed as an universally good thing), the fixed-cycle latency is replaced by handwaving.

However, that's not the whole picture.

Interrupt latency in the classical meaning of word depends also on uninterruptible multi-cycle instructions and also on interrupts of the same or higher priority. Most of the time these introduce jitter (and thus increase in the worst-case) rather than hard increase of latency.

If you run the processor at 250MHz from FLASH, after all other latencies resolved up to the stacking point, there's quite significant slowdown associated with the FLASH access time, as FLASH is good up to some 25MHz or so. Interrupt means a jump, so prefetch won't help that much, and how well jumpcache or general caching helps, depends on the details.

And then, as you probably use a higher-level language such as C, the ISR's prologue begins, with software stacking registers, creating stack frame, etc.

And then, if you use some "library" such as Cube/HAL, the inefficiencies of those appear.

And then, if you use e.g. pin toggle to determine the interrupt point, hardware paths from the "set port" instruction to GPIO actually changing output level are to be considered.

All in all, latencies in interrupts in the order of say half hundred up to thousand cycles are normal (and jitters around this order of magnitude too). This is why in "modern" mcus you want to delegate any precision-timing job to hardware and avoid software including interrupts.

JW