I am writing an STM32F303 application to digitize pulse signal amplitudes. There will be a peak detector, that can be reset by the uC pin, so I'm not expecting the uC to instantly digitize as soon as the pulse arrives, but I am still a bit confused by the interrupt latency which seems to be a bit too large.

Currently, I have set up a comparator with DAC input (PA4) on the negative side and the pulse input from a function generator (with a large fall time of 3uS) on the positive one (PA1). The comparator is also set up to output it's analog output on PA0.

On the Comparator ISR (EXTI Line 21), I am simply briefly turning on the PB0 pin. Here is the oscilogram I'm getting with this setup. Yellow line is the input pulse, blue is the comparator's output and purple is the PB0 state. The DAC output is 2048, pulse amplitude is 3.3 volts.

The oscilogramm

The blue line is more than fine, but there is clearly some delay between the comparator triggering and the PB0 switching. I am not using LL or HAL and directly working with CMSIS, so overhead should be minimal. Still, the delay is around 500nS, which translates to around 36 instructions at 72 MHz. Code optimizer does not do anything at all. I haven't got any other interrupts, including the systick interrupt.

Shouldn't the reaction be pretty much instant? Pin toggling shouldn't take that long - you can clearly see the much shorter impulse from turning the pin on and off. Is it some inherent interrupt latency, some time to save the registers and so to stack, both or what? Can it be minimized further and if so, how? Where can this EXTI interrupt latency be found in datasheet or reference manual? Also, on a side note - why am I getting two impulses, is it just due to some noise in the comparator output?

Here is my very short ISR code:

void COMP1_2_3_IRQHandler(void)
    EXTI->PR |= EXTI_PR_PIF21;

And here is the comparator/exti setup code (without DAC, GPIO, RCC setup and such - I've double-checked with a timer that I am indeed running at 72 MHz)

// SW1 off, PA4 as inverting input, no direct output, output not inverted, no blanking
COMP1->CSR |= (0b100 << COMP_CSR_COMPxINSEL_Pos) | (0b00 << COMP_CSR_COMPxOUTSEL_Pos);

// Enable the comparator

// Enable the comparator ISR
NVIC_SetPriority(COMP1_2_3_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),0, 0));

// Configure EXTI Line 21 (COMP1 Output)
  • 3
    \$\begingroup\$ Does this answer your question? Interrupt latency on a STM32F303 MCU \$\endgroup\$ Commented Aug 6, 2022 at 17:35
  • \$\begingroup\$ @JacobKrall not exactly. It is obvious there that latency for that user is due to HAL overhead, and the interrupt latency itself is discussed only very briefly without getting into details on it's minimization and where it stems from. \$\endgroup\$
    – sx107
    Commented Aug 7, 2022 at 7:42

2 Answers 2


500ns is in line with what can be achieved on that CPU without delving into implementation details.

Code optimizer does not do anything at all

To claim this, we'd need to see the assembly (.S) output with the optimizer turned off (-O0) and turned on (-O3). I doubt that the optimizer does "nothing at all", but I may be wrong of course. It may be that it does all it can do given what you expect the code to do.

  • \$\begingroup\$ That is what I meant, it does nothing for the time delay. \$\endgroup\$
    – sx107
    Commented Aug 7, 2022 at 7:39

You drop a couple clock cycles by remove the OR from the BSSR assignment. It is read only.

  • \$\begingroup\$ This answer may be useful if additional detail was added. \$\endgroup\$
    – Russell McMahon
    Commented Feb 11, 2023 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.