In my project based on stm32F107 i use four pins (PINE 12-15) to catch rising level on them.

My problem: two pins always produce external interrupts but there are no rising level on them and other two pins never respond to rising level.

My question: i'm looking for some debug ways and may be advices. May be reading some registers in the interrupt routine will help to solve my problem.

      RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOE, ENABLE);

      GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;
      GPIO_InitStruct.GPIO_Mode  = GPIO_Mode_IN_FLOATING;

      GPIO_InitStruct.GPIO_Pin = GPIO_Pin_12;
      GPIO_Init(GPIOE, &GPIO_InitStruct);

      GPIO_InitStruct.GPIO_Pin = GPIO_Pin_13;
      GPIO_Init(GPIOE, &GPIO_InitStruct);

      GPIO_InitStruct.GPIO_Pin = GPIO_Pin_14;
      GPIO_Init(GPIOE, &GPIO_InitStruct);

      GPIO_InitStruct.GPIO_Pin = GPIO_Pin_15;
      GPIO_Init(GPIOE, &GPIO_InitStruct);

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE);

      EXTI_InitStructure.EXTI_Mode    = EXTI_Mode_Interrupt; 
      EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising;
      EXTI_InitStructure.EXTI_LineCmd = ENABLE;

    // KeyI_0
        GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_Pin_12);
        EXTI_InitStructure.EXTI_Line    = EXTI_Line12;

    // KeyI_1
        GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_Pin_13);
        EXTI_InitStructure.EXTI_Line    = EXTI_Line13;

    // KeyI_2
        GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_Pin_14);
        EXTI_InitStructure.EXTI_Line    = EXTI_Line14;

    // KeyI_3
            GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_Pin_15);
            EXTI_InitStructure.EXTI_Line    = EXTI_Line15;

    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
      NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
      NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;           
      NVIC_InitStructure.NVIC_IRQChannel = EXTI15_10_IRQn;

 void EXTI15_10_IRQHandler(void)
  if (EXTI_GetFlagStatus(EXTI_Line12) != RESET) {
  } else if (EXTI_GetFlagStatus(EXTI_Line13) != RESET) {
  } else if (EXTI_GetFlagStatus(EXTI_Line14) != RESET) {
  } else if (EXTI_GetFlagStatus(EXTI_Line15) != RESET) {
  • \$\begingroup\$ What library are you using STD/HAL ? \$\endgroup\$ – Stefan Merfu Sep 30 '15 at 9:06
  • \$\begingroup\$ @StefanMerfu SPL \$\endgroup\$ – r_spb Sep 30 '15 at 9:12
  • \$\begingroup\$ Ok.Post your code to take a look.Whole code. \$\endgroup\$ – Stefan Merfu Sep 30 '15 at 9:13
  • \$\begingroup\$ @StefanMerfu updated \$\endgroup\$ – r_spb Sep 30 '15 at 9:25
  • \$\begingroup\$ FLOATING doesnt seem right. Is there a PUPD option? \$\endgroup\$ – Scott Seidman Sep 30 '15 at 10:53

Since you ask about debugging methods for problems like this, the absolute first thing I would do (after making sure the microcontroller is properly bypassed and the power is good) is to get this working flawlessly with ONE interrupt configured and enabled, and then and only then move on to more than one. Add them one at a time and see where things go wrong.

I don't know what your particular printf is doing. I assume it goes to some semihosting tty in your dev environment. In any case, I would lose it until I have this worked out. Use some GPIO output as indicators that the interrupt was received, probably toggling on each one. As a rule of thumb, long complicated stuff is to avoided in interrupts. You might try disabling the interrupt while you're in it, and reenable on the way back out. That printf takes up a lot of clock ticks, and bounce (see below) might be retriggering.

Another issue would be switch bounce. You may be triggering an interrupt every time you flip the switch. Even when you flip the switch OFF you probably have rising edges. You can hardware or software debounce, but again, until you have a grip on it, I recommend triggering your interrupts clean from a digital output on another port.

Also, using a multimeter here really isn't the right tool. If the problem lies with the signals going to PORTE pins, there's no way you will find it without a scope. If everything else doesn't work, you should try to handle these inputs better, but without knowing specifics of what they are now, we can't really advise you on this. If you had a scope, you could use the interrupt to set a bit high, trigger the scope on that, and look at the portE signal that caused it.

If stepping through your problem this way doesn't help you figure out the underlying problem (or someone with a better eye than me can see the error in your code), update to let us know the step where things go wrong and we can take another crack at it.

  • \$\begingroup\$ Thanks for answer. I've tried to simplify my projects and check single exti. All i can say: either there is some hardware mistake (em influence) on board or it is some stm32f107 internal bug. \$\endgroup\$ – r_spb Sep 30 '15 at 13:41

So it was mistake in code syntax.

That is wrong:

GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_Pin_12);

That is correct:

GPIO_EXTILineConfig(GPIO_PortSourceGPIOE, GPIO_PinSource12);

Sorry for wasting your time.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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