STM32L052 random TIM2_CR1 register reset

[Marc1]

Hi there,

I’m using STM32L052 for PWM generation with TIM2.

TIM2->CR1 is initialized once at start of the program and never touched again during runtime:

TIM2->CR1 = 0x00000081;

Even though, in some random cases TIM2->CR1 switches back to 0. How can that happen? How can TIM2->CR1 accidentally switch back to 0? Is there a known issue? I really don’t know how to debug such an error. TIM2->CR1 is the only register that changes randomly.

Thanks in advance for your help!

 

[TDK]

CR1 does not spontaneously change back to 0. If the clock is disabled, it may be read back as 0. Or if the chip is reset, it will have its reset value.

Instrument your code to find out where/when it gets changed. It’s possible a bad pointer or a stack overflow is causing the issue. Unfortunately, hardware watchpoints do not work on registers.

[Marc1]

Hi TDK,

Thank you for your response.

> If the clock is disabled, it may be read back as 0.
Clock is still running: APB1ENR = 0x98800001

> Or if the chip is reset, it will have its reset value.
Chip reset would also reset all other registers.

> It’s possible a bad pointer or a stack overflow is causing the issue.
This was my first thought and I’m still searching.

TIM2->CR1 is at address 0X4000 0000 and there is no register or RAM below.
Address range 0X2000 2000 - 0X3FFF FFFF is marked as “reserved”.

[gbm]

Check all the occurrences of TIM2 symbol in your code. I suspect some incorrect register assignment or DMA transfer setup.

[Marc1]

The error does not occur on every device. Some devices are affected and on other devices the error never occur.

[db16122]

how many pcs has this error while how many pcs do not have this error? Any trigger point?

[Marc1]

About 5% have that error (100 / 2000).

[waclawek.jan]

>  in some random cases TIM2->CR1 switches back to 0

How do you know?

If running with debugger attached, you can place a data breakpoint (“watchpoint”) on this register. It will then break the execution a couple of instructions after the point where this register was written, in most cases allowing to observe what code was it.

TIM2_CR1 can be reset also by resetting selectively TIM2 through RCC_APB1RSTR.TIM2RST bit; that wouldn’t affect registers of other peripherals, but it would clear all TIM2 registers.

JW

[Marc1]

> How do you know?

I read it.

> TIM2_CR1 can be reset also by resetting selectively TIM2 through RCC_APB1RSTR.TIM2RST bit; that wouldn’t affect registers of other peripherals, but it would clear all TIM2 registers.

Other TIM2 registers are not cleared, only TIM2->CR1.

[waclawek.jan]

> I read it.

Using debugger?

If yes, then I’d suggest to try placing watchpoint on that register, as I’ve mentioned above.

[EDIT] Now I see @TDK above to say that watchpoints don’t work on registers - don’t they? I did use them successfully in the past, but in Cortex-M4, not Cortex-M0+. However, I don’t see why wouldn’t they work there either, provided they are available at all in that architecture.

JW