cancel
Showing results for 
Search instead for 
Did you mean: 

EXTI not work as expected

uveuvenouve
Associate III

 i am using NUCLEO-F410RB board

i followed the simple exti tutorial try to print "button pressed" to uart when the corresponding button is pressed

like most of the tutorial setting : interrupt rising edge . no pull up and pull down , one side of button  is the certain pin and the other side is connect to the board 3.3V pin 

and insert code like this

 

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
	if(GPIO_Pin == GPIO_PIN_14){

		printf("button pressed");

	}

}

 

i have tried several exti gate. they have the same problem

even i just plug a wire to the certain pin , the other end of wire has not connected anything yet

the uart would display a tons of 'button pressed' which means the exti was triggered multiple time

it is kind of weird

 

do you guys have encountered this problem before?

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hello

add new line to the end of string:

 

printf("button pressed\n");

 

 or add:

 

fflush(stdout);

 

after printf.

Now your printf's wait for buffer to fill. Your interrupt is probably working just fine.

BR J.T

View solution in original post

6 REPLIES 6
JTP1
Lead

Hello

Now your input pin is floating when button is not pressed and that is causing interrupts. You must either activate the internal pull-down or install external pull-down resistor to your board. Then the pull-down keeps your pin nicely low when button is not pressed.

Br J.T

Hi Br J.T
thanks for the advise
i tried to activate the internal pull-down to the pin

it doesn't trigger itself now.
but there is another issue. the exti not response immediately and not trigger correctly

after 5-6 presses to the button ,the uart print out like 20-30 'button pressed' on the screen

why a simple function can be so hard:loudly_crying_face:

 

Hello

add new line to the end of string:

 

printf("button pressed\n");

 

 or add:

 

fflush(stdout);

 

after printf.

Now your printf's wait for buffer to fill. Your interrupt is probably working just fine.

BR J.T

Thank you
it works now. never thought it is related

Good. Please note also that calling printf from interrupt routine is not recommended,  so never use it in 'production' version. It can cause serious problems since its non-reentrant. 

Generally speaking interrupt handlers should be short and also non-blocking. Good practice is set some flag and handle it for example in main loop, if handling needs complicated fuctions etc

Danish1
Lead II

One thing that hasn't been mentioned, but you should be aware of, is that the EXTI being called multiple times is genuine. Most mechanical switches do "bounce" i.e. at the moment they are changing state they make and break several times. And each time the pin will change from low-to-high or back. And when the appropriate edge happens, you get an interrupt.

The duration of bouncing can depend on the type of switch, but you can expect it to last a few tens of milliseconds.

To reduce confusion, people have written "switch debouncing" routines, so that only one change event gets passed up to higher levels of software. One way is for the system to ignore changes-in-state for a longer-than-debounce-period after each recognised change-in-state. @JTP1 did this by waiting in the interrupt-service-routine for the entire duration of the printf (which I assume was sending the message down a UART or similar). But you shouldn't spend excess time in an interrupt-service-routine unless absolutely necessary because the cpu can't be doing any other work (except service a higher-priority interrupt).

So maybe your EXTI interrupt could start a timer and disable that EXTI, as well as triggering whatever you want to happen. When the timer expires (by interrupt) you re-enable the EXTI.