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

[Billy OWEN]

Hi @waclawek.jan 

My piece of the pie was the small legwork to get the right people involved, the topic is no longer in my hands. Since there was an amount of back and forth here (and time) before the moderators chose to take it internally, let me make notes in the case to the MCU apps team that closing the loop back here is requested.

Thanks,

Billy

[waclawek.jan]

Hi @Billy OWEN ,

> let me make notes in the case to the MCU apps team that closing the loop back here is requested

Thanks.

We all can learn from cases which get resolved eventually - and sometimes also from those which don't.

JW

[Dave94]

Yes

[Jan KRUPICKA]

Hello All,
testing conditions for initial question are not representative to obtain latency of ISR.
Running at 32MHz Sysclock add extra flash wait state and different AHB and APBx clocks add synchronization delay between buses which caused variation in ISR latency.
IO toggling managed by accessing to port register delays up to 6 cycles – depends on optimization setting.

I was testing on my side and able to reduce ISR latency to 21 clocks and 20 cycles with fast optimization. Measured by logic analyzer from raising edge on input captured channel to raising edge of output pin controlled by __SEV() instruction in TIM21_IRQHandler. Test application running @4MHZ = 0 flash wait state and AHB = APBx. By moving ISR in SRAM does not reach better results.

Currently I’m asking internally where these extra 4/5 cycles are burned because ISR latency on M0+ is 15 cycles. But expecting latency in TIMER and propagation to NVIC.

BR. Jan

[waclawek.jan]

Hi @Jan KRUPICKA ,

Thanks for the comment.

Can you please post the ISR disasm (possibly together with source) for further discussion?

I can see several ways how to expand this to a knowledgebase article - e.g. gradually adding FLASH latency (in order to increase clock, although clock does not necessarily has to be increased), APB prescalers, TIM input channel filter, various levels of optimization, larger ISR code (which results in more extensive prologue), Cube/HAL ISR, other ISRs, execution of multi-byte instructions or other instructions which may delay interrupt execution (possibly introducing jitter rather than hard latency)  - and demonstrate the effect of all these on the resulting latency. @KB-IDEA 

Also, in the initial post, GPIO has been used rather than SEV. In Cortex-M0+, as specialty of this particular core, GPIOs are on the private IO bus of the processor. While one would expect, that that would have minimum latency (i.e. the output would change in then next cycle after the respective st instruction has been executed), is it really so (i.e. how does using GPIO compare to using SEV?)

Thanks,

JW