stm32 nucleo_u575zi_q wkup pin with irq only works once after rtc wakeup

[whati001]

Describe the bug

Hi all,

I am currently evaluating the stop 3 mode in combination with IRQ handlers on the nucleo_u575zi_q board and facing some weird behavior. My goal is to register a gpio irq handler to a wakup pin. Once the pin is pressed, the CPU should wake (because it's a wakeup pin) + execute the configured irq handler.
For testing, I have used the zephyr/samples/boards/st/power_mgmt/wkup_pins sample, added the irq handler, and changed from standby to stop3. Please find my code here: https://github.com/whati001/zephyr/tree/test/wkup_gpio_irq/samples/boards/st/power_mgmt/wkup_pins

The crazy thing is that the irq is only executed once per rtc timeout. Argo, when I wait for 10 seconds until the RTC wakes up the CPU, I can press the nucleo button, and the IRQ is executed nicely. However, the IRQ is not executed if I press the button again (before the 10 seconds of the rtc timeout). After the RTC times out and wakes up the CPU, the button works again once. Here is the main code to understand what I mean:

void button_isr(const struct device *dev, struct gpio_callback *cb, uint32_t pins)
{
	// Add work to the workqueue
	printk("Button pressed, system waking up\n");
}

int main(void)
{
	printk("\nWake-up button is connected to %s pin %d\n", button.port->name, button.pin);

	__ASSERT_NO_MSG(gpio_is_ready_dt(&led));
	gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
	gpio_pin_set(led.port, led.pin, 1);

	/* Setup button GPIO pin as a source for exiting Poweroff */
	gpio_pin_configure_dt(&button, STM32_GPIO_WKUP);

	printk("Press the user button to power the system from stop3\n\n");

	// Configure the interrupt
	int ret = gpio_pin_interrupt_configure_dt(&button, GPIO_INT_EDGE_TO_ACTIVE);
	if (ret < 0) {
		printk("ERROR: could not configure button as interrupt source\r\n");
		return 0;
	}

	// Connect callback function (ISR) to interrupt source
	gpio_init_callback(&btn_cb_data, button_isr, BIT(button.pin));
	gpio_add_callback(button.port, &btn_cb_data);

	// Do nothing
	while (1) {
		k_sleep(K_SECONDS(10));
		printk("System woke up from stop3 mode via RTC irq\n\n\n\n\n\n\n");
	}

	return 0;
}

To see if the CPU does something, I have added a print into the cortex_m irs_wrapper function:

The output shows that I received the following interrupts:

<<<<< RTC TIMEOUT >>>>>
ISR wrapper called for IRQ 2        <- RTC timeout 
ISR wrapper called for IRQ 77     <- PWR WAKUP STOP3
ISR wrapper called for IRQ 67     <- LPTIM1 ?????
ISR wrapper called for IRQ 67     <- LPTIM1 ??????
ISR wrapper called for IRQ 67    <- LPTIM1 ??????
System woke up from stop3 mode via RTC irq <- log from main thread




<<<<< NEW BUTTON PRESS -> first after RTC works >>>>>
ISR wrapper called for IRQ 67      <- LPTIM1 ????
ISR wrapper called for IRQ 24      <- EXTI 13 GPIO IRQ 
Button pressed, system waking up  <- log from GPIO IRQ
ISR wrapper called for IRQ 77       <- PWR WAKUP STOP3
ISR wrapper called for IRQ 67       <- LPTIM1 ????
ISR wrapper called for IRQ 67      <- LPTIM1 ????
<<<<< NEW BUTTON PRESS -> only first press after RTC works >>>>>
ISR wrapper called for IRQ 77      <- PWR WAKUP STOP3
ISR wrapper called for IRQ 67      <- LPTIM1 ????
ISR wrapper called for IRQ 67     <- LPTIM1 ????

The RTC somehow resets the EXTI13 interrupt line, but I do not know where and how.
Because all button presses (after the first one, which works) only trigger a solely PWE WAKUP STOP3 interrupt without the EXTI one. I assume this is also the reason why the irq handler is not executed.

In addition, all the LPTIM1 interrupts confuse me. Shouldn't the LPTIM1 be disabled, and should RTC be used in stop 3? Why do I receive so many LPTIM1 interrupts here?

Regression

• This is a regression.

Steps to reproduce

Reproduce:

• Pull my branch: https://github.com/whati001/zephyr/tree/test/wkup_gpio_irq
• Build the sample
• Flash the sample
• Repower the board (see ST Blinky power_mgmt sample crashes b_u585i_iot02a discovery board #91112)
• Connect to serial log

Relevant log output

See above

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

OS: Linux
Toolchain: zephyr-sdk-0.17.0
Zephyr: Zephyr 4.2.0-rc3

Additional Context

I have also added a printk to each exti controller function, but it seems that they are not called after an RTC wake up. I really do not understand why an RTC wake up "fixes" the button irq.

The board uses as wakup pin the PC13 on WKUP2:

And some notes that the RTC uses the PC13 for something:

What comes into my head are the following problems:

• do we need to "reset" the GPIO interrupt somehow?
• can it be that the RTC and the user button use the same GPIO pin (have found something that the rtc can use a gpio for wkup) and then an RTC wakup clears the GPIO interrupt somehow?

[JarmouniA]

Before looking into the problems you are having, note that this cannot be considered a bug when the documentation clearly says the current wake-up pins API is only meant to be used for Poweroff (standby) exit.

zephyr/include/zephyr/dt-bindings/gpio/stm32-gpio.h

Line 24 in 322da1d

* Configures a GPIO pin to power on the system after Poweroff.

zephyr/samples/boards/st/power_mgmt/wkup_pins/README.rst

Line 11 in 322da1d

a source to power on an STM32 SoC after Poweroff.

[JarmouniA]

Converting to a discussion.

[whati001]

After some research, I can already answer my question about the LPTIM:

As we can see in the screenshot, the stm32 lptim code only uses the RTC if it goes into STOP 3. So if it suspends to STOP 1 or STOP 2, it will use the LPTIM for wakup (timeout_stdby is not true). (Hope this is fine :) )

[whati001]

After some more research, I hope that I have found the problem for the missing IRQ execution.
It seems like that the EXTI interrupt flag is not cleared in the NVIC. Due to this, the interrupt is not triggered and therefore the IRQ is not executed.

For testing purpose, I clear the EXTI interrupt flag within the WKUP IRQ (yes I know this is the complete wrong place to do this):

But the sample works. What still puzzles me is that the RTC wakeup seems to clear somehow the EXTI flag, because it works afterwards.

[JarmouniA]

But the sample works. What still puzzles me is that the RTC wakeup seems to clear somehow the EXTI flag, because it works afterwards.

Just a wild guess, maybe it's this

zephyr/drivers/rtc/rtc_ll_stm32.c

Line 308 in 1f69b91

ll_func_exti_clear_rtc_alarm_flag(RTC_STM32_EXTI_LINE);

[JarmouniA]

No it's not

zephyr/drivers/rtc/rtc_ll_stm32.h

Line 56 in 1f69b91

/* in STM32U5 & STM32WBAX series, RTC Alarm event is not routed to EXTI */

[whati001]

The logic works with stop 2 (no changes needed).

So maybe there is a special logic needed for stop3 ?
But I have to check this first.