STM32F411: is clearing an external interrupt flag really necessary?

Question

I've bought an STM32F411 nucleo board and now I'm trying to understand various bits and pieces of the HAL. Starting with external interrupts seemed to be a good idea, because the board has a push button which is connected to PC13. So I've set up a simple toggle-the-frequency blinky. The code below is a bit simplified:

#define LED_PIN GPIO_PIN_5
#define BTN_PIN GPIO_PIN_13

static uint32_t blink_period = 250;

int main(void)
{
  HAL_Init();
  SystemClock_Config();

  __GPIOA_CLK_ENABLE();
  GPIO_InitTypeDef pinConfig;
  pinConfig.Pin = (LED_PIN);
  pinConfig.Pull = GPIO_NOPULL;
  pinConfig.Mode = GPIO_MODE_OUTPUT_PP;
  pinConfig.Speed = GPIO_SPEED_FAST;
  HAL_GPIO_Init(GPIOA, &pinConfig);

  __GPIOC_CLK_ENABLE();
  pinConfig.Pin = (BTN_PIN);
  pinConfig.Pull = GPIO_NOPULL;
  pinConfig.Mode = GPIO_MODE_IT_FALLING;
  pinConfig.Speed = GPIO_SPEED_LOW;
  HAL_GPIO_Init(GPIOC, &pinConfig);
  HAL_NVIC_SetPriority(EXTI15_10_IRQn, 0x0F, 0x00);
  HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

  while (1)
  {
    HAL_GPIO_TogglePin(GPIOA, LED_PIN);
    HAL_Delay(blink_period);
  }
}

void EXTI15_10_IRQHandler(void)
{
  HAL_GPIO_EXTI_IRQHandler(BTN_PIN);
}

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if(GPIO_Pin == BTN_PIN)
  {
    if (blink_period == 500)
    {
      blink_period = 250;
    }
    else
    {
      blink_period = 500;
    }
  }
}

When I push the button, an interrupt is generated and the blinky frequency changes from 1 to 2 Hz (or vice-versa). This works as intended, but why? I forgot to clear the pending interrupt flag, so the ISR should be called over and over. The datasheet clearly states that

When the selected edge occurs on the external interrupt line, an interrupt request is generated. The pending bit corresponding to the interrupt line is also set. This request is reset by writing a ‘1’ in the pending register.

Reading a bit further reveals that this is a bit different for events:

When the selected edge occurs on the event line, an event pulse is generated. The pending bit corresponding to the event line is not set.

However, I'm not setting the button pin mode to any of the GPIO_MODE_EVT_... modes so I'm not using the event mechanism (to be honest I don't yet know what that even is - I just think that I'm not using it. Any hints are welcome).

So somewhere I should have to call void HAL_NVIC_ClearPendingIRQ (IRQn_Type IRQn), shouldn't I? It seems that clearing the flag by software is not necessary, because the ISR is not called more than once per falling edge. I've added a breakpoint in HAL_GPIO_EXTI_Callback to verify this.

Edit

As mentioned in the comments, the flag clearing code is in ST's implementation of the GPIO interrupt handler:

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);
  }
}

This handler needs to be called by the actual ISR (which is done in my code) and it clears the pending flag corresponding to the GPIO_Pin argument. So I have to write an ISR which sorts out which flags are set, and call HAL_GPIO_EXTI_IRQHandler for each, which in turn calls my HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin), again with the pin as an argument. For each external interrupt, the pin number would get checked some ~3 times (in the ISR, in the handler and in the callback)!

If that is the solution, I want my problem back.

I'm pretty certain that this flag is cleared in HAL_GPIO_EXTI_IRQHandler() - you didn't show us the source of this particular function... And - as usually - problems like this are avoided by NOT using this pseudo-library from ST - it solves nothing, giving you just more problems to think of. And it is so extremely crappy, that I just cannot look at this code... — Freddie Chopin
Oh - your variable blink_period should really be declared volatile. — Freddie Chopin
@FreddieChopin indeed the handling of external interrupts is quite convoluted and I think I don't even want to try the drivers for more complex peripherals. HAL_GPIO_EXTI_IRQHandler() is supplied by ST - I had a look at it, and it indeed clears the flag in question. So are there any alternatives to the Cube? — Christoph
Nothing that I know of (; There's libopenCM3 - I didn't use that, so I don't know what it's worth. The peripherals are pretty simple, so personally I just use my own code, using SPL (Cube's predecessor) as an example when I don't understand something or when something doesn't work when it should. If you want, you can check out STM32F4 example project from my website - you have GPIO configuration and clock (RCC) configuration done using registers, so you'll see how does that look. The example is not for nucleo, but it will work when you change settings in config.h file. — Freddie Chopin
@KarthikNishanth: you probably aren't still looking, but for others' benefit, the STM32Cube package has a bunch of examples that use the HAL driver. See st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897 or st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897/… — Aaron Campbell

LennyB LennyB · Accepted Answer · 2015-03-15T10:54:15

You don't have to call HAL_NVIC_ClearPendingIRQ (IRQn_Type IRQn) because the pending bit in the NVIC will be cleared automatically upon entering HAL_GPIO_EXTI_IRQHandler.

The HAL_GPIO_EXTI_IRQHandler() implementation clears the pending bit in the peripheral, not in the NVIC. If it didn't clear the pending bit by calling __HAL_GPIO_EXTI_CLEAR_IT(GPIO_Pin), then the handler would be called again and again. The point is that you must distinguish between the interrupt pending bit in the peripheral and the pending bit in the NVIC.

STM32F411: is clearing an external interrupt flag really necessary?

Edit

1 Answers