STM32L0x3 Interrupt Latency

[Dave94]

Good morning,

I am working with a board mounting a STM32L0x3 microcontroller. My SystemCoreClock is 32 MHz and TIM12 is clocked at 4 MHz. TIM12 has been configured in order to work in Capture Mode on Channel 1 (falling edge).
The ISR does what is listed below

void TIM21_IRQHandler(void)

{

/* USER CODE BEGIN TIM21_IRQn 0 */

/* USER CODE END TIM21_IRQn 0 */

GPIOB->BSRR = GPIO_PIN_11 ;

/* USER CODE BEGIN TIM21_IRQn 1 */

/* USER CODE END TIM21_IRQn 1 */

}

To my surprise, using an oscilloscope, I noted that time elapsed since the falling edge of the signal the other pin is set is about 1us.
Why do I have all this latency?
Thanks to all who will support me

[Uwe Bonnes]

For an interrupt at least some up to 16 registers need to be pushed on the stack , the IRQ code needs to be fetched from with flash wait state and finally the GPIO needs to be set. This will take some cycles and at 32 MHz 1 microsecond are only 32 cycles.

[Dave94]

How many clock cyles are needed to fetch the IRQ and set the output?

[waclawek.jan]

> How many clock cyles are needed to fetch the IRQ and set the output?

First, there may be some delay for the interrupt signal to propagate from TIM to NVIC.

Then all latencies stemming from multi-cycle instructions execution, other interrupts of higher or equal priority being executed, from global interrupt disables/enables in code, etc., have to be taken into account

Then the interrupt entry process starts. Unless there's some extreme FLASH latency (assuming the interrupt vector table is in FLASH), registers (not 16 but 8 ) are stacked together with fetching the interrupt vector, and that lasts 12 cycles.

Then the interrupt code has to be executed - see disasm for what instructions are involved (e.g. C function prologue), and if executing from FLASH, take into account the FLASH latency - up until the point when the GPIO register is written, and that write has to propagate through the bus matrix to GPIO itself.

32 cycles is just about right for a very simple ISR written in C, with no other sources of latency present.

JW

[Dave94]

I have found at this link that the interrupt latency for a CortexM0+ should be 15 clock cycles.

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

Even if I consider that this instruction

GPIOB->BSRR = GPIO_PIN_11 ;

could take 5 clock cycles, why should I get 32 cycles you mentioned?

[AScha.3]

Ok, and what did you set as optimizer level ? If you want it fast, need -O2 or -Ofast , otherwise code is not at the expected speed, but good only for debug.

-> project settings

[ONadr.1]

Do you count Flash latency?

The best way is to measure it with a pulse generator and an oscilloscope. You can also see how big the jitter is.

[waclawek.jan]

> I have found at this link that the interrupt latency for a CortexM0+ should be 15 clock cycles.

I stand corrected; wasn't aware of the difference in CM0/CM0+. Thanks.

> Even if I consider that this instruction

> GPIOB->BSRR = GPIO_PIN_11 ;

> could take 5 clock cycles,

Why would that be the case?

Post disasm of the ISR.

What's the FLASH latency?

JW

[Billy OWEN]

Hi @Dave94 

The forum moderator had marked your post as needing a little more investigation and direct support. An online support case has been created on your behalf, please stand by for just a moment and you will hear from us.

Regards,

Billy

[waclawek.jan]

Hi @Billy OWEN ,

will also we hear from you here?

JW