2025-12-15 2:29 PM
I am experiencing an issue when trying to use STOP3 mode on an STM32U575VIT6Q device mounted on a custom PCB. In fact, the MCU never seems to actually enter STOP3, even though I explicitly call:
HAL_SuspendTick();
HAL_PWREx_EnterSTOP3Mode(PWR_STOPENTRY_WFI);
HAL_ResumeTick();The observed behavior is as follows:
With Low-Power debugging enabled, STM32CubeIDE halts execution on the internal low-level _WFI() instruction.
Without the debugger attached (free-running mode after BOR and JTAG detached), the MCU does not appear to enter STOP3 at all and continues normal execution after the call.
From code inspection and debugging, it looks like the core is effectively ignoring the WFI instruction or is prevented from transitioning into STOP3 by some system or external condition.
At the moment, it is unclear what might be blocking STOP3 entry. Possible areas I am investigating include:
Pending or enabled interrupts/events that could immediately wake the core after WFI
Debug-related side effects, even when low-power debug is supposedly disabled (even with HAL function)
If anyone has encountered a similar issue on STM32U575 devices, I would appreciate any guidance or suggestions.
Thank you in advance for your support.
2025-12-15 11:52 PM
hello @PGior.2
As a first impression, ensure that no EXTI prevents the (MCU) from entering stop 3 mode. This issue is very common in these cases.
Also, ensure that you reconfigure the system clock after exiting stop mode.
I will attach a firmware example that you can use to test stop 3 mode and other low-power modes.
You can use this example as a reference and compare it with your project. You might find the cause of your issue.
You can refer to this WIKI to understand more about low power modes if you want.
Hope that helps you to solve your problem
Gyessine
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-16 12:54 AM
Hello @Gyessine . I am already familiar with STOP3 mode, as I have previously debugged and used it on STM32U545 and STM32U585, applying several modifications required for its proper operation.
In particular, I:
HAL_PWREx_EnablePullUpPullDownConfig();
HAL_PWREx_EnableGPIOPullUp(PWR_GPIO_A, PWR_GPIO_BIT_2);
HAL_PWREx_EnableGPIOPullUp(PWR_GPIO_A, PWR_GPIO_BIT_4);
HAL_PWREx_EnableGPIOPullUp(PWR_GPIO_E, PWR_GPIO_BIT_12); HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_D, PWR_GPIO_BIT_15);
HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_A, PWR_GPIO_BIT_8);
HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_D, PWR_GPIO_BIT_2);
HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_D, PWR_GPIO_BIT_13);
HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_E, PWR_GPIO_BIT_5);
HAL_PWREx_EnableGPIOPullDown(PWR_GPIO_E, PWR_GPIO_BIT_7);
HAL_DBGMCU_DisableDBGStopMode();
/* Clear Stop and Standby flags */
__HAL_PWR_CLEAR_FLAG(PWR_FLAG_STOPF);
__HAL_PWR_CLEAR_FLAG(PWR_FLAG_SBF);
/* Clear all Wakeup flags */
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG1);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG2);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG3);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG4);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG5);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG6);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG7);
__HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_FLAG8);
HAL_NVIC_ClearPendingIRQ(EXTI5_IRQn);
HAL_NVIC_ClearPendingIRQ(EXTI4_IRQn);
HAL_NVIC_ClearPendingIRQ(EXTI2_IRQn);
HAL_NVIC_ClearPendingIRQ(EXTI7_IRQn);
HAL_NVIC_ClearPendingIRQ(PWR_S3WU_IRQn);
HAL_NVIC_ClearPendingIRQ(RTC_IRQn);
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1_HIGH_2); /*! @see GPI_EXTI4_TAMPER_Pin */
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN4_LOW_0); /*! @see GPI_EXTI2_NFC_Pin */
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN2_HIGH_2); /*! @see GPI_EXTI5_RADIO_WAKEUP_Pin */
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN6_HIGH_2); /*! @see GPI_EXTI7_RF_DIO1_Pin */
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN7_HIGH_3); /*! RTC Wake Up (Alarm B / Alarm A) */
HAL_NVIC_EnableIRQ(PWR_S3WU_IRQn);
HAL_NVIC_SetPriority(PWR_S3WU_IRQn, 7, 7);
HAL_SuspendTick();
HAL_PWREx_EnterSTOP3Mode(PWR_STOPENTRY_WFI);
HAL_ResumeTick();
SystemClock_Config();
However, on STM32U575 this approach does not work at all. The device never enters STOP3, and I cannot identify any functional or configuration difference that would justify this behavior compared to U545 and U585.
At this point, I am trying to understand whether there is a device-specific constraint (.ioc?) or additional prerequisite on STM32U575 that prevents STOP3 from being entered under the same conditions.
2025-12-16 2:40 AM
hello @PGior.2
I recommend first to make some tests to ensure that it is not a hardware implementation related problem.
are you using the same PCB design that you used in other MCU's that you mentioned?
you can test stop3 mode alongside other low power modes like in the example provided and measure the power consumption to verify your product behavior
waiting for your feedback
Gyessine
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.