Event Update Interrupt Call delayed

[Amir1]

Folks

I have set TIM2 in center-aligned PWM mode as well as a timebase ISR in which I just toggle the LED (for inspection and better understanding of the operation, otherwise to be replaced by an ADC activation, etc.). Thus, each edge of the LED (pin) voltage waveform represents one ISR call or one overflow/underflow event update. The scheme works fine except that the edges of the LED voltage (i.e., interrupt calls) are a bit delayed with respect to the centers of the PWM output pulses (about 2 us delayed), on a 20kHz PWM output train. This delay would be problematic at PWM duty cycles close to zero or close to unity since it would result in two ISR calls during the interval when the PWM pulse is high or low. Any ideas what is causing this large delay? I expected the ISR calls to exactly (within nanoseconds) coincide the centers of the PWM pulses (as the event updates take place at those instants). TIM2 is clocked at 72MHz.

Amir

[waclawek.jan]

Well, it takes some time to execute the ISR...

JW

[Amir1]

Sure, but 2us? It is roughly 140 clock cycles.

[S.Ma]

What part number and what SYSCLK frequency? Figures needed to quantify.

[Amir1]

Of course.

SYSCLK = 72 MHz; F303RE. TIM2 is also clocked at 72 MHz.

[waclawek.jan]

Are you using Cube/HAL and/or some other "library"? Do you have switched compiler optimization on? Is the ISR running from FLASH? What exactly does the ISR do? Have you looked at the disassembly of the ISR?

JW

[Amir1]

I am using Cube and HAL for the skeleton of the code, but then modify various registers as needed. The ISR contains nothing but a single toggle-pin functions. That is why I am puzzled by the delay. Later on, the ISR shall include an ADC call, a difference equation for a digital PI controller to update the pulsewidth according to the ADC reading, and an DAC call for probing, for a simple motor control function.

Fig. 211 of RM0316 shows something that might explain what I am seeing: It shows that UIF is delayed with respect to UEV, but it does not mention the delay amount nor does it give much explanations in the text.

I do not know from where is ISR running. How do I find that out?

[waclawek.jan]

> Fig. 211 of RM0316 shows something that might explain what I am seeing: It shows that UIF is delayed

> with respect to UEV, but it does not mention the delay amount nor does it give much explanations in the text.

That's the only fig which shows such delay, so I wouldn't pay too much attention to that. Even if there is such delay, it's surely not more than one or two timer clocks.

> I do not know from where is ISR running. How do I find that out?

When interrupt is fired, the processor fetches the ISR address from the vector table. This is toolchain dependent but usually is contained in the file which contains the startup code, often assembler. The ISR itself is usually C, with a name given in that table, for TIM2 it's TIM2_IRQHandler() - probably in something like stm32f3xx_it.c, I don't use Cube/CubeMX so don't know.

JW