Why does RCC_APB1ENR:TIM2_EN get cleared in Stop Mode when DBGMCU is set?

[skoe]

We noticed that our TIM2 did not count after our STM32L152 went to Stop Mode and woke up again.

When we analyzed the problem, we found that our debug probe set DBGMCU to DBG_STANDBY | DBG_STOP | DBG_SLEEP. When we power cycled the µC or set DBGMCU to 0 in our start-up code, it worked as expected. A closer look revealed that RCC_APB1ENR:TIM2_EN got cleared by/during Stop Mode when DBGMCU was set. Without DBGMCU it remained set. Is this documented and intended behavior? Did we miss something?

Btw., we use external clock source mode 2, but I think this is not relevant for this issue.

[waclawek.jan]

> RCC_APB1ENR:TIM2_EN got cleared by/during Stop Mode when DBGMCU was set

The debugger sets DBGMCU_CR.DBG_STOP for a reason: that bit allows the processor core, thus the debugger to run during STOP.

In other words, I'd guess it's the debugger which clears RCC_APB1ENR.TIM2EN during STOP, for whatever reason. Debuggers usually perform "magic" without telling much to the users (and users expect the "magic" to happen).

Try an experiment: run this code without having the debugger connected. Still RCC_APB1ENR.TIM2EN cleared in STOP mode?

JW

[Tesla DeLorean]

Is the project using a TIM rather than SysTick as a timing source?

What debugger or toolset are we talking about?

[skoe]

Thank you both for the responses. Yes, we are aware of the primary meaning of DBG_STOP, leaving an internal oscillator active to allow debug access during Stop Mode.

I forgot to mention one experiment we made which may clarify the question: When we do not connect a debugger at all, set DBGMCU_CR.DBG_STOP manually in our start-up code, and power-cycle the device, the same happens: RCC_APB1ENR.TIM2EN gets cleared when the device was in STOP. When we write 0 to DBGMCU_CR.DBG_STOP instead, it does not happen, TIM2EN is still active in the same situation.

This shows that the type of debugger makes no difference, as it's not involved in this test. But just for completeness: We use an ST-Link V2 with openocd. We can remove the DBGMCU_CR from the openocd script to get rid of that behavior, but we'd prefer to fully understand the situation.

> Is the project using a TIM rather than SysTick as a timing source?

It's a basic loop with Stop Mode, woken up by an RTC seconds tick or an external pin, do some processing and go back to Stop.

Let me add that it's all "handwritten" code and reviewed by multiple people, we made sure that none of the code fiddles with the TIM2EN bit. A single line changed (DBGMCU_CR as described above) makes the difference.