STM32 Interrupt large latency

Question

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 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)
{
    GPIOB->BSRR |= GPIO_BSRR_BS_0;
    GPIOB->BSRR |= GPIO_BSRR_BR_0;
    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
COMP1->CSR |= COMP_CSR_COMPxEN;

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

// Configure EXTI Line 21 (COMP1 Output)
EXTI->IMR |= EXTI_IMR_IM21;
EXTI->RTSR |= EXTI_RTSR_RT21;

Answer 1

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.

Answer 2

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