Skip to main content
Sebastian Gniazdowski
Sebastian Gniazdowski
Associate III
January 19, 2017
Solved

GPIO_EXTI example – HAL_NVIC_EnableIRQ() not ending

  • January 19, 2017
  • 4 replies
  • 2873 views
Posted on January 19, 2017 at 21:19

I'm compiling and running GPIO_EXTI example code for Nucleo-F767ZI board (on SW4STM32). The handler that blinks LED1 isn't connected and this matches what readme.txt says:

In this example:

    - EXTI_Line15_10 is connected to PC.13 pin

      - when falling edge is detected on EXTI_Line15_10 by pressing User push-button, LED1 toggles once

On STM32F767ZI-Nucleo:

    - EXTI_Line15_10 is connected to User push-button

So, handler isn't set for the Nucleo board. When I push user button and pause (debugging) the program, it is then in default handler / infinite loop. All correct.

However, the program never goes beyond those lines of EXTI15_10_IRQHandler_Config(void):

  /* Enable and set EXTI line 15_10 Interrupt to the lowest priority */

  HAL_NVIC_SetPriority(EXTI15_10_IRQn, 2, 0);

  HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

When I pause, I'm still in HAL_NVIC_EnableIRQ(), the program never returns to main() to do its infinite while() loop. As already said above, it however does react to user button, so the IRQ is correctly enabled.

I attach state after step-into the function, and step over its content. As it can be seen, the program forever runs that line (thread state says: 'Running: Step').

UPDATE: Here is the source code (main.c) of the GPIO_EXTI example, copied from official CubeMX package for F767 (V1.5.1):

http://pastebin.com/kBRT2ApU

 

Best regards,

Sebastian

#irq #examples #hang #exti_irqhandler #stm32cubemx-examples* #nucleo-f767zi
This topic has been closed for replies.
Best answer by Sebastian Gniazdowski
Posted on January 22, 2017 at 20:00

Solution: empty while loop in main() has been optimized away to such extent that the debugger was showing last executed instruction in HAL_NVIC_EnableIRQ(). So it looked like if program was stuck in that call. Adding a volatile variable to the loop revealed that everything is fine.

4 replies

Tesla DeLorean
Tesla DeLorean
Guru
January 19, 2017
Posted on January 19, 2017 at 22:22

The Cortex-Mx processors need you to clear the source of the interrupt, otherwise they will continually tail-chain and no foreground execution will occur. You need to review what your IRQHandler code is doing.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Sebastian Gniazdowski
Sebastian GniazdowskiAuthor
Associate III
January 20, 2017
Posted on January 20, 2017 at 14:19

It's not my IRQHandler – this is an official example. There is no IRQHandler, but HAL_GPIO_EXTI_Callback(). I tried to add __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_13) here:

static void EXTI15_10_IRQHandler_Config(void)

{

  GPIO_InitTypeDef   GPIO_InitStructure;

  /* Enable GPIOC clock */

  __HAL_RCC_GPIOC_CLK_ENABLE();

  /* Configure PC.13 pin as input floating */

  GPIO_InitStructure.Mode = GPIO_MODE_IT_RISING;

  GPIO_InitStructure.Pull = GPIO_NOPULL;

  GPIO_InitStructure.Pin = GPIO_PIN_13;

  HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);

  // The added line

  __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_13);

  /* Enable and set EXTI line 15_10 Interrupt to the lowest priority */

  HAL_NVIC_SetPriority(EXTI15_10_IRQn, 2, 1);

  HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

}

But still no change – program loops inside HAL_NVIC_EnableIRQ() as the screenshot shows.

Best regards,

Sebastian

Tesla DeLorean
Tesla DeLorean
Guru
January 20, 2017
Posted on January 20, 2017 at 17:09

Ok, but the screen shot really shows me nothing useful..

Right now I suspect it is off an an interrupt state, so you'd have to check the vector table and make sure it is binding with 

EXTI15_10_IRQHandler properly. Could you show the code in 

EXTI15_10_IRQHandler?

Put a break point in the Default Handler, EXTI15_10_IRQHandler and have the Hard Fault handler output diagnostic information if it gets there.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Sebastian Gniazdowski
Sebastian GniazdowskiAuthor
Associate III
January 22, 2017
Posted on January 22, 2017 at 17:39

Here is complete source code of the example. It's CubeMX project with files overwritten with those from GPIO_EXTI. Diff on the two projects reveals that everything possible is the same.

https://github.com/psprint/CubeEmpty

S.Ma
S.Ma
Principal
January 22, 2017
Posted on January 22, 2017 at 19:53

If possible, here would be my checklist: Has the port be selected for the EXTI properly? Exti 10..15 can be pa11, pb12, pc12, etc... Just make sure toggling the led does not trigger an exti by mistake...

Usually regardless of the code, it is very handy to put a breakpoint in the interrupt..

Then when the code stops, look at gpio and exti peripheral registers.

Remember the pending flag is cleared by clearing the right PR bit. Search for the code that does this and breakpoint onto it.

Sebastian Gniazdowski
Sebastian GniazdowskiAuthorAnswer
Associate III
January 22, 2017
Posted on January 22, 2017 at 20:00

Solution: empty while loop in main() has been optimized away to such extent that the debugger was showing last executed instruction in HAL_NVIC_EnableIRQ(). So it looked like if program was stuck in that call. Adding a volatile variable to the loop revealed that everything is fine.

Terms & ConditionsAccessibility statement