STM32L0 - GPIO Interrupt blocking RTC Interrupt

[RSoen.1]

Hello,

I have the RTC set for a 1 Hz interrupt. I have buttons, that when pressed, trigger a rising edge interrupt. The interrupts work fine except that when I call my button handling routine the RTC interrupts are blocked. They remain block until the button is released. I wouldn't thinkit would behave this way for an edge triggered interrupt. Here is the gpio interrupt handler in stm32l0xx_it.c:

 * @brief This function handles EXTI line 4 to 15 interrupts.
 */
void EXTI4_15_IRQHandler(void)
{
 /* USER CODE BEGIN EXTI4_15_IRQn 0 */
 
 /* USER CODE END EXTI4_15_IRQn 0 */
 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_9);
 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_10);
 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_11);
 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_12);
 /* USER CODE BEGIN EXTI4_15_IRQn 1 */
 
 /* USER CODE END EXTI4_15_IRQn 1 */
}

These call this handler in stm32l0xxhal_gpio.c

 * @brief This function handles EXTI interrupt request.
 * @param GPIO_Pin Specifies the pins connected to the EXTI line.
 * @retval None
 */
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);
 }
}

You can see that EXTI interrupt is cleared. I would think that this would allow the RTC interrupt to occur. I have a HAL_GPIO_EXTI_Callback(GPIO_Pin); in my user code that calls my button handling code.

The gpio NVIC interrupt priority was set at 0, I set it to 2 and the RTC interrupt then premepted the GPIO interrupt.

Anyone have an idea why this would fix this issue when, one might think, the issue shouldn't need the fix as the GPIO interrupt was already cleared?

Thank you

Rich

[waclawek.jan]

> I have a HAL_GPIO_EXTI_Callback(GPIO_Pin); in my user code that calls my button handling code.

Show.

JW

[Tesla DeLorean]

The numbering is the other way around, lower is more important.

If you want the RTC preempt you're going to have give that a higher priority.

Ideally you won't block endlessly in the callback/interrupt context.

You have to actually leave the callback for the NVIC to unwind the processor state by exiting the IRQ Handler

[RSoen.1]

That makes total sense, we are really not out of the handler till we get back where we started and exit with a reti instruction (Or whatever).

Thanks for the help.

Rich