EXTI - High Latency on STM32F407

[tech_boards_email]

Posted on June 27, 2013 at 20:47

Hi.

I used one of the examples shipped with Discovery as a template for my code.  Basically, a GPIO input (PA0) is coupled to a function generator and every time an interrupt is detected, a different pin goes HI/LO to indicate that whatever is inside the interrupt handler gets processed. The problem is that the test GPIO goes high and low (indicating a registered interrupt) approximately 600 ns after the detection of the rising edge of the input signal.  Now, without some stuff in the main while loop (a serial port polling routine), the latency is reduced to about 440 ns. Shouldn't the interrupt handler process the interrupt much faster than this? Thank you, Razvan #insufficient-information

[Tesla DeLorean]

Posted on June 27, 2013 at 20:53

Honestly it's going to depend on how fast you're clocking the device, and what the routine is doing. The interrupt is likely to eat some 12 cycles at least stacking context, more if dealing with the FPU.

[tech_boards_email]

Posted on June 27, 2013 at 21:27

Clive,

thanks for the quick reply. Here's the version of the handler that toggles the GPIO high after ca. 440 ns. <code> void EXTI0_IRQHandler(void){ if(EXTI_GetITStatus(EXTI_Line0) != RESET)   {     {                      GPIOC->BSRRH = GPIO_Pin_6;             GPIOC->BSRRL = GPIO_Pin_6;             Delay(10);             GPIOC->BSRRH = GPIO_Pin_6;              }     /* Clear the EXTI line 0 pending bit */     EXTI_ClearITPendingBit(EXTI_Line0);   } } </code> My code also uses the FPU and I couldn't notice a difference. Thanks.

[dthedens23]

Posted on June 28, 2013 at 18:31

Check the signal with a scope.  Some large R/C component might effect rise time.

interesting section 10.3.6   EXTI_PR

This bit iscleared by writing a 1 to the bit or by changing the sensitivity of the edge detector.

Now, how does one become more sensitive?

[tech_boards_email]

Posted on June 28, 2013 at 20:41

Hi.

I do use a scope for watching the input and the monitoring GPO. I managed to decrease the interrupt latency down to 500 ns by getting rid of some loops in the main function. The FPU didn't introduce any noticeable latency. Also, I've generated a brand new system file (via clock setup excel utility) just to make sure that the clocks were set correctly. I'll just call it at this point and consider the matter closed. 400 - 600 ns latency is still good for our application. Thank you all.