cancel
Showing results for 
Search instead for 
Did you mean: 

EXTI_IRQ with USerButton problem

kecskesgery
Associate II
Posted on October 31, 2015 at 15:42

Hello there!

I have designed a custom board, and what I'd like to do is that when I press the UserButton, a LED lights up.Now, my button is connected to PC0 pin on my STM32F429 controller, and the LED is connected to PB7 pin. What my problem is, that every time I press the button, I get unexpected interrupt, and I'll end up in startup_stms 'Infinite_Loop'. I have no idea what I'm doing wrong, my code is based on cubef4 GPIO example. main.c

void Button_init()
{
GPIO_InitTypeDef GPIO_init;
__HAL_RCC_GPIOC_CLK_ENABLE();
GPIO_init.Mode = GPIO_MODE_IT_FALLING;
GPIO_init.Pin = GPIO_PIN_0;
GPIO_init.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOC, &GPIO_init);
HAL_NVIC_SetPriority(EXTI0_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(EXTI0_IRQn);
}
void LED_init()
{
GPIO_InitTypeDef GPIO_init;
__HAL_RCC_GPIOB_CLK_ENABLE();
GPIO_init.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_init.Pin = GPIO_PIN_7;
GPIO_init.Pull = GPIO_NOPULL;
GPIO_init.Speed = GPIO_SPEED_FAST;
HAL_GPIO_Init(GPIOB, &GPIO_init);
}
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
if(GPIO_Pin == GPIO_PIN_0)
{
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_SET);
}
}

stm32f4xx_it.c

void EXTI0_IRQHandler(void)
{
HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
}

Do you guys know what causes my external interrupt failure? There must something wrong with the NVIC settings, or so... Thanks for the help in advanced! #exti #stm32 #stm32 #exti #interrupt #interrupt #interrupts #interrupts #button
8 REPLIES 8
AvaTar
Lead
Posted on October 31, 2015 at 17:10

The code of your

HAL_GPIO_EXTI_IRQHandler()

function would be of interest, too. Does it clear the interrupt flag ?

I don't use Cube and stay with the SPL, which uses

EXTI_ClearITPendingBit()

for this purpose.

kecskesgery
Associate II
Posted on October 31, 2015 at 17:27 Hey! Here's what it does (default HAL code in stm32f4xx_hal_gpio.c):

void HAL_GPIO_EXTI_IRQHandler(uint16_t GPIO_Pin)
{
/* EXTI line interrupt detected */
if(__HAL_GPIO_EXTI_GET_IT(GPIO_Pin) != RESET)
{
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_Pin);
HAL_GPIO_EXTI_Callback(GPIO_Pin);
}
}

kecskesgery
Associate II
Posted on October 31, 2015 at 18:39

Since I have a STM32Discovery board, I tried out the same code on it, except I connected the EXTI to PA0, since the UserButton is on that pin. On the Discovery board the code works perfectly, the LED ligths up. No unexpected IT.

Right know I'm very confused...What could possibly do wrong? 

AvaTar
Lead
Posted on October 31, 2015 at 20:31

I can't comment on Cube stuff - still refusing to use it.

But compare your schematics with that of the discovery. The latter uses a pull-down resistor on PA0. Either a pull-up or pull-down is highly suggested for interfacing switches, and if you want identical behavior, use a pull-down as well (220k on the user button input of the F4 discovery).

Otherwise it will float when the button is not pressed, and be highly susceptible to EMI, for instance from your fingers.

kecskesgery
Associate II
Posted on November 02, 2015 at 13:49

Well, here's my schematics:

0690X00000605JlQAI.bmp

It is basically the same to the one on the Discovery, except I have a 100k pull-down, instead of a 220k one. Well, this is not the source of the problem I guess...

But still, what causes the unexpected interrupt issue? This has to do with software. Any other ideas? 

AvaTar
Lead
Posted on November 03, 2015 at 10:01

But still, what causes the unexpected interrupt issue? This has to do with software. Any other ideas?

 

Don't know ...

If I remember correctly, the cap (equivalent to your C10) is not populated on the discovery board - at least the schematics say so.

Have you debugged the interrupt code, to make sure the proper interrupt flag is reset ?

You could try attaching a scope to the input, but the RC of the probe might interfere with the problem, if it's EMI related.

kecskesgery
Associate II
Posted on November 04, 2015 at 10:56 Well-well, after spending enormous time debugging, reading ref manual, datasheet, and so on, I've found the error. Lets's be honest: the solution is pretty easy, I was only missingthe developing experience, you see, I'm quite a newbie. Alright, so whenever you want to create a new EXTI, the given external interrupt is pointing to its default handler in the interrupt vector table. Now, that table was very much empty in my project. This can be found in startup_stms. This has to be filled with the IRQ Handles, you're gonna use, as follows:

.word _estack
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
.word MemManage_Handler
.word BusFault_Handler
.word UsageFault_Handler
.word 0
.word 0
.word 0
.word 0
.word SVC_Handler
.word DebugMon_Handler
.word 0
.word PendSV_Handler
.word SysTick_Handler
...
.word EXTI0_IRQHandler /* EXTI Line0 */
.word EXTI1_IRQHandler /* EXTI Line1 */
.word EXTI2_IRQHandler /* EXTI Line2 */
.word EXTI3_IRQHandler /* EXTI Line3 */
...

Plus, at the end of the file, you have to provide theweak aliases for each Exception handler to the Default_Handler, like this:

.weak NMI_Handler
.thumb_set NMI_Handler,Default_Handler
.weak HardFault_Handler
.thumb_set HardFault_Handler,Default_Handler
.weak MemManage_Handler
.thumb_set MemManage_Handler,Default_Handler
...
.weak EXTI0_IRQHandler
.thumb_set EXTI0_IRQHandler,Default_Handler
.weak EXTI1_IRQHandler
.thumb_set EXTI1_IRQHandler,Default_Handler
.weak EXTI2_IRQHandler
.thumb_set EXTI2_IRQHandler,Default_Handler
...

And yepp, works like a charm. Too bad, I did not know this earlier.... Anyways, thanks for the help!
Posted on May 31, 2016 at 10:42

Hello,

cubeMx generated the code in startup .s code for me you provided. But even though each time an external interrupt eccurs the mcu is being reset. Could there be any other reason?