cancel
Showing results for 
Search instead for 
Did you mean: 

Problem on EXTI interrupt

asecen89
Associate II
Posted on July 01, 2014 at 14:28

Hi,

In my application, I have a PPS (pulse per second) signal with a period of 1 second and pulse duration of 200 ms. This external signal is connected to an EXTI line which generates an interrupt at each rising edge of this signal. The interrupt is generated at rising edges, but sometimes it is generated 200 ms after the rising edge interrupt although there is no rising edge, but a falling edge at this point. Moreover, when interrupt is generated at this point, the flag corresponding to the EXTI line in the pending register is also not set. What do you think causes the interrupt here?

 
3 REPLIES 3
Posted on July 01, 2014 at 14:50

I don't know, but wouldn't it make more sense to use a timer in input capture mode, to both generate an interrupt for the edge, and stamp it against an internal time base?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
juozas
Associate III
Posted on April 07, 2015 at 16:15

Hi,

I recently solved similar problem. Processor (STM32F405 @168MHz) pin configured to interrupt only on falling edges, sometimes senses also rising edges of signal.

I've found, that oscilloscope probe do not allow to detect what signal is on that pin - effect disappears after probe connect - no any bounces on signal.

By adding code lines to separate action by level on pin after interrupt happens, I have decided that signal bouncing is not a case - this is behavior of processor.

If bouncing may be in place, after separation I have to see action already on both program case outputs, but this not happens - separation is working good.

My final code:

Part of initialization code:

GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_13;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;

GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;

GPIO_Init(GPIOD, &GPIO_InitStructure);

SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOD, EXTI_PinSource13);

EXTI_InitStructure.EXTI_Line = EXTI_Line13;

EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;

EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising_Falling; // I need only Falling, but I have selected both to have more logical result.

EXTI_InitStructure.EXTI_LineCmd = ENABLE;

EXTI_Init(&EXTI_InitStructure);

void EXTI15_10_IRQHandler(void)

{

 if ((EXTI->PR & EXTI_Line13) != (uint32_t)RESET)

 { // select required edge (equivalent to Falling):

  if ((GPIO_ReadInputDataBit(GPIOD, GPIO_Pin_13)) == RESET)

    {

   // make actions after check other conditions.

  // just for testing:

         // SET_TEST1_OUTPUT_SET

         // SET_TEST1_OUTPUT_CLEAR

  }

        EXTI->PR = EXTI_Line13; //EXTI_ClearITPendingBit(EXTI_Line13);   

   }

// other lines from group ''15...10'' action code...

}

Additional information: 1) the same EXTI15_10_IRQHandler subroutine in my this project contain also code for other interrupt lines.

These other lines configured for various edges detection: for Falling and for Rising.

I have no problem with other lines, maybe because different influence of possible wrong detection on final result.

2) The problem with wrong detection was already when my pin was on PA0.

Best regards,

Juozas Kimtys

 

jpeacock
Associate II
Posted on April 07, 2015 at 17:25

The obvious cause would be some problem with the signal at the rising edge, likely a drop fast enough to trigger another EXTI but too fast to see in software by sampling the pin.  A good scope can catch those kinds of transients.  The easy fix is to debounce the input with a timer, disable the EXTI on falling edge, enable again 500ms later. 

Check the rise time; a very slow rise, say from a capacitor charging, doesn't produce a clean square wave.  You can get unexpected EXTI triggers in no man's land between deasserted and asserted.  And don't rely on checking pin status in software, the processor isn't fast enough to catch it.

  Jack Peacock