Skip to main content
Visitor II
December 15, 2025
Question

STM32U575 – Unable to Enter STOP3 Mode: WFI Ignored after BOR

  • December 15, 2025
  • 2 replies
  • 75 views

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.

    This topic has been closed for replies.

    2 replies

    Technical Moderator
    December 16, 2025

    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

    PGior.2Author
    Visitor II
    December 16, 2025

    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:

    1. Modified HAL_PWREx_S3WU_IRQHandler in stm32u5xx_hal_pwr_ex.cadapting HAL_PWREx_S3WUCallback(WakeUpPin) to explicitly handle each bitmask as
      HAL_PWREx_S3WUCallback(PWR_WAKEUP_PINx)
    2. Configured EXTI for each wakeup source via CubeMX
    3. Implemented STOP3 entry using a dedicated and controlled sequence as it follows:
    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.

    Technical Moderator
    December 16, 2025

    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