How fast is EXTI in Stop-Mode and can I make it faster?

[OliM]

My expectation was that a pin-interrupt using EXTI will lead to wakeup times just slightly longer than the wakeup delays named in the datasheet (below 10µs), but what I see is this (falling edge on yellow finally reached the ISR on the magenta rising edge :(

This was measured using an STM32WB55 waking from STOP2.

How is this delay explained and can I shorten it while still using stop-mode?

EDIT:

I tested the reaction from standby mode via a wkup pin as well and it's even a bit faster! (different project so no reverse edges by design)

[KiptonM]

Do not use the HAL code for the interrupt. Write your own. You can then do exactly what you want as soon as the interrupt fires.

The HAL adds a lot of overhead to the interrupt, (which you see as a delay) but it is easier for the beginner. If you want to go faster you have to learn how the EXTI interrupt works and write your own.

Follow the HAL code and see what it is doing. It is a lot of "who called this routine?" (Search is your new friend) Working your way up the code chain. Seeing what all happens before it gets to the callback you are using.

Either put your code at the beginning of the interrupt or get rid of what you do not need. It will depend on how many other EXTI interrupts you are using. If this is the only one, just get rid of everything else.

[OliM]

I am not using HAL and this is my only EXTI.

If I use this code from simple cpu-slep instead of stop (using all the same interfaces I use otherwise as well) I get reaction times in the range of 5-6µs.

So your answer might help in some other cases but is completely off the problem here.

[OliM · Accepted solution]

So I invested some more time in it and here is the gist:

EXTI actually reacts very quick, so a return from STOP2 after <10µs is really happening on both my U5 and my WB setup. The problem is the state of the PWR and RCC registers at that time. A lot of clocks need to be configured (at least write back the old register state of CR, CFGR, etc.) and start again and, depending on the desired clock, also the power level needs to be raised again.

On the U5 the later is taking up most of the time (and I can not really circumvent this since I need at least 48Mhz afterwards) which results in time to ISR of around 20µs (could be made faster if I hard code the power level I want to use instead of choosing it dynamically).

On the WB I also waited for the HSE to start up (as long as you use the Bluetooth function you will also have HSE enabled, but that doesn't mean the M4 side actually wants to use it) which took most of the time with around 100µs. Once I leave that out I get a time to ISR of < 15µs.