Skip to main content
C
Carl_G
Graduate II
March 5, 2025
Solved

TIM still running in STOP

  • March 5, 2025
  • 2 replies
  • 886 views

I am using TIM2 to create PWMs for LEDs. When I enter STOP mode I expect the PWM to stop. Yet it does not. From the manual TIM do not have wakeup capability from stop mode. So they should not be requesting the HSI to operate.

What could possibly cause the HSI to continue to operate in STOP mode. I am waking in 5s from RTC. during this whole time and continuously uninterrupted as far as I can tell the PWM keep going. Shouldn't they stop?

HSIKERON is 0.

    This topic has been closed for replies.
    Best answer by Hai

    Hello Carl_G,

    Thank you for your observation regarding the behavior of TIM2 and the HSI in STOP mode. Based on the information provided from our G0 reference manual, there are some points to be considered when using low-power modes:

    • Enabling debugging in STOP mode allows the internal RC oscillator (likely the HSI) to continue feeding the system clocks (FCLK and HCLK). This is necessary to maintain the debugger connection and functionality
    • Argument: According to section 40.9.1 (already mentioned in Debug section), the core does not allow FCLK or HCLK to be turned off during a debug session is enabled. This is because these clocks are required for the debugger connection, and during a debug session, they must remain active. The MCU integrates debug allowing the user to debug software in low-power modes (But it is just an emulation).
    • Best practice to enter STOP mode: To ensure that the HSI and TIM2 stop as expected in STOP mode, you should disable the debug feature in STOP mode. This can be done by clearing the DBG_STOP bit.

     

    Haifa_BEN_HSOUNA_0-1741647728675.png

    I hope this answer meets your needs. If you have any further questions or need additional assistance, please feel free to reach out.

    2 replies

    C
    Carl_GAuthor
    Graduate II
    March 5, 2025

    Seems setting the debug in STOP mode can cause this. It allows the "internal RC oscillator" clock to feed FCLK and HCLK. While it is unclear exactly which internal RC oscillator they mean, it would seem this is the culprit. Turning this feature off allows the HSI or at least TIM2 to stop. This should probably be listed in the RCC and/or PWR section as a caveat.

    H
    HaiAnswer
    ST Employee
    March 10, 2025

    Hello Carl_G,

    Thank you for your observation regarding the behavior of TIM2 and the HSI in STOP mode. Based on the information provided from our G0 reference manual, there are some points to be considered when using low-power modes:

    • Enabling debugging in STOP mode allows the internal RC oscillator (likely the HSI) to continue feeding the system clocks (FCLK and HCLK). This is necessary to maintain the debugger connection and functionality
    • Argument: According to section 40.9.1 (already mentioned in Debug section), the core does not allow FCLK or HCLK to be turned off during a debug session is enabled. This is because these clocks are required for the debugger connection, and during a debug session, they must remain active. The MCU integrates debug allowing the user to debug software in low-power modes (But it is just an emulation).
    • Best practice to enter STOP mode: To ensure that the HSI and TIM2 stop as expected in STOP mode, you should disable the debug feature in STOP mode. This can be done by clearing the DBG_STOP bit.

     

    Haifa_BEN_HSOUNA_0-1741647728675.png

    I hope this answer meets your needs. If you have any further questions or need additional assistance, please feel free to reach out.

    C
    Carl_GAuthor
    Graduate II
    March 13, 2025

    I get that the info is available and a programmer will eventually find it. Also I somewhat misstated TIM2. Tim2 didn't stop because I didn't stop it. It's still enabled and waiting on any clock pulses that happen to feed it.

    Terms & ConditionsAccessibility statement