Timer behaviour after wakeup from STOP

[avidroneg]

I've searched and not found anything describing this behaviour (on the internet or this forum, which I've found to be an incredible resource so far - thank you).

I have a configuration where I go into STOP, exit out of STOP via EXTI, start TIM1, allow the stack to unwind to leave HAL_PWR_EnterSTOPMode(), and then SLEEP. With this sequence, I expect a TIM1 interrupt but never hear one.

Conversely, if I enter SLEEP instead of STOP for the very first step but perform all of the other steps identically, I get the behaviour I'm looking for - an EXTI, then a period asleep, then a TIM1 callback. This tells me that the STOP is interfering with the configuration of the timer somehow, in a way that I haven't been able to figure out how to recover from.

I've tried, after exiting STOP, to re-issue a call to HAL_TIM_Base_MspInit and MX_TIM1_Init but this has not helped. Removing the final SLEEP and spin-waiting has also not helped.

Why might this be happening? Where should I start the debug effort?

[waclawek.jan]

I don't quite understand what is your problem but perhaps start with reading about the low-power modes in PWR chapter of RM, to find out which clocks are stopped in which mode. If the timer has stopped its clock (which is the APB clock derived from AHB clock), then it can't run thus interrupt.

If in run mode the timer does not work as you expect, then read out and check its registers' content.

JW

[avidroneg]

I'll do what you say and diff the timer registers between the functioning and non functioning case, but for my understanding: when exiting STOP, I would have assumed that the relevant clocks (APB2 in my case) auto-resume. Is that not the case?

[waclawek.jan]

IMO clocks work as expected, and you can check that by setting TIM1 to output PWM and observe.

JW

[Gyessine]

hello @avidroneg 
Can you specify which STM32F3 product you are using?
according to application note AN4865, a general-purpose timer (TIM) is active in Run and Sleep modes but is frozen in Stop mode. Also you can refer to this WIKI for better understanding of low power modes 
BR
Gyessine

[avidroneg]

STM32F303K8. I fully expect that the timer doesn't count in stop; the question is why it doesn't want to resume when releasing out of stop.

The wiki is informative, but doesn't speak much on resuming from stop other than calling HAL_ResumeTick(). I haven't tried that yet, so I will.

[avidroneg]

I have more information. The timer actually does resume, and can produce an interrupt, but the delay is wrong - so something about the prescaler or clock tree has been disturbed by entering and leaving STOP.

[Gyessine]

Hello @avidroneg 
What type of clock source is being used? Is it HSI or HSE? What frequency is being used?
Can you also verify the prescaler register to ensure if it is loaded with the desired value.

BR

Gyessine

[avidroneg]

Thank you for asking. TIM1 is set with this MX configuration:

TIM1 runs on this portion of the clock tree:

so it uses HSI -> SYSCLK -> HCLK -> PCLK2*2 for an eventual clock input of 8 MHz. I will check the prescaler later, though I know that prior to STOP it is at the correct value.

 

[carlbidwell]

It sounds like you’re running into a common issue where peripherals, like TIM1, don’t automatically recover their clock configuration after waking up from STOP mode. In STOP, most clocks (including APB timers) are disabled to save power, so when you wake up, the timer’s clock source isn’t automatically restored unless it’s explicitly re-enabled.

After waking up from STOP, make sure to:

Re-enable the peripheral clock for TIM1 (e.g., __HAL_RCC_TIM1_CLK_ENABLE();).

Reinitialize or restart the timer (HAL_TIM_Base_Start_IT(&htim1);) after clocks are stable.

Double-check that the system clock is properly restored before touching peripherals—especially if you use HAL_PWR_EnterSTOPMode() with PWR_MAINREGULATOR_ON.

In short, STOP mode suspends timer clocks, while SLEEP keeps them running, that’s why your SLEEP case works. Focus your debug on confirming that TIM1’s clock is alive after wakeup.

[waclawek.jan]

Gated mode of the slave-mode controller? What is the input to the slave-mode controller, i.e. what is connected to TIMx_CH1? Isn't that signal/gating the source of delay?

I repeat, output PWM by the timer, in that way you'll see if it's running or not. A very good test would be to set that timer to output PWM with PSC=0, ARR=1, CCRx=1 (i.e. toggling the output at every timer cycle) and observe.

JW

[avidroneg]

---

@waclawek.jan wrote:

Gated mode of the slave-mode controller? What is the input to the slave-mode controller, i.e. what is connected to TIMx_CH1? Isn't that signal/gating the source of delay?

---

The gate function is working fine and I don't think is the source of the problem. It is tied to PA8. PA8 successfully ungates the timer both before and after STOP; the problem is that the necessary ungated duration to interrupt grows significantly after the STOP, so I still suspect timer clock configuration of the kind that @carlbidwell has described.

 

---

output PWM by the timer, in that way you'll see if it's running or not. A very good test would be to set that timer to output PWM with PSC=0, ARR=1, CCRx=1 (i.e. toggling the output at every timer cycle) and observe.

I will try that when I have an opportunity; thanks.

[Gyessine]

Hello @avidroneg 
Did you try to measure the delay and does the delay get affected by changes in the frequency supplied to the timer or other factors?
It would be helpful if you could provide more details, such as a capture from a logic analyzer or oscilloscope.
Additionally, did you refer to the "slave mode: Gated mode" in section 20.3.25, "Timer synchronization," in the reference manual.
BR
Gyessine