STM32 interrupt latency

[OmarAyman]

hi there ! 
I have an RTOS project, there are many interrupts (UART1,UART2,UART3, CAN interrupts, ....etc) . 
I want to measure the interrupt latency of any interrupt in the system. 

as you know the latency is the time between the event of interrupt (T1)  and the first instruction in the ISR (T2) of the interrupt we want to measure its latency. (T2-T1)

I use STlink debugger.
I use the VScode as a code editor.

we know where is the  first instruction in the ISR (T2), i mean (the location in code), but for 
the event of interrupt (T1), we do NOT , for example the (T1), for (UART interrupt - in case it is receiving a character - is going to make (RXNE flag to be rise),
so the question is could we stop the code at this point when this flag is changing its value from LOW to HIGH ? 
if we couldnt, how could we measure the latency for those types of interrupts, when we dont have an external event acts as (T1)?

[Sarra.S]

Hello @OmarAyman, welcome to ST Community, 

One way to do this is by configuring a hardware timer to generate an interrupt, In the timer's ISR, toggle a GPIO pin and then trigger the UART interrupt (or the interrupt you want to measure), then measure the time between the GPIO toggle and the first instruction of the UART ISR using an oscilloscope.

 

[SStor]

Other solution is routing the UART RX line to a second pin with dedicated timer capture input functionality.

With first rising edge of RX line the exact timestamp can be captured. A further read of the current timer counter value at interrupt entry gives the exact latency from the difference of both values...

(CAN peripheral has also its own RX timestamp, implementation depends on the used MCU family)

[Danish1]

It might be useful if you could clarify why you are trying to measure interrupt latency, as that might affect how best to measure it.

You mention a RTOS as well as many interrupt sources. And that makes me think you are trying to detect “worst-case” latency in a heavily-loaded system rather than typical latency for a single source on an otherwise lightly-loaded system.

Too slow and you risk having “overrun” where you e.g. lose incoming characters or even messages.

The RTOS is likely to disable interrupts for very short time-periods to do things like context-switching. But I don’t see that as a critical issue.

More of a problem could be the fact that the processor cannot service one interrupt while it is busy with another of the same or higher priority. Which is why you might want to measure a “highly-loaded” system with lots of interrupts happening all at nearly the same time. But that might be difficult to measure as it’s hard to guess which of the interrupts will be hardest hit, as that’s the one to probe.

Ok, that’s enough unhelpful stuff. Can I offer anything constructive?

Perhaps a proxy for this worst-case latency is to measure gaps in execution time for a tight loop in a thread in your RTOS