cancel
Showing results for 
Search instead for 
Did you mean: 

Weird timer behavior right after reset on STM32G4 - Inconsistent timebase

ARoth.1
Associate II

I'm using a timer as a 1ms timebase, which is configured right after hitting main, so very early. I use this timebase to implement timeout functionality in my drivers as I prefer to not just use while loops when waiting for something to complete.

What I have noticed is that the timebase is way off very early in the boot process, but it is spot on later. For example, I use that same timebase to blink an LED at a 1Hz interval and it does behave as expected. However, some earlier delays pretty much just fly by. Case in point: After configuring the timebase, I have a 10 second (10'000 ms) delay and when I run the code, I see no perceivable delay in the boot process. If I set a break point right before the delay and then manually step OVER the delay function, it does delay for 10 seconds....

Also, when stepping through the code and keeping an eye on the CNT register of the timebase counter, I see huge increases when stepping from one instruction to the next. After a few instructions it seems to "slow down" and only increase after a while. Since the timer is prescaled to have a 1ms tick (running of the HSI @ 16MHz) I would expect the CNT register to increase very slowly when stepping through code.

Based on what I have observed, it looks like the clock is much faster right after startup and then settles. This is weird, I would expect it to be the other way around. Note that I use the HSI and do not modify the clock structure at all.

Really shooting in the dark here, this is such a strange issue... I have implemented a check on the HSIRDY bit in the RCC CR register to make sure that the HSI is ready before I continue, but that doesn't help at all.

I should also mention that I'm not using the HAL.

Any ideas or suggestions are appreciated!!

1 ACCEPTED SOLUTION

Accepted Solutions
ARoth.1
Associate II

Well, I posted this prematurely... Did some more googling and found a similar post that had the solution:

https://community.st.com/s/question/0D50X00009Xki8ySAB/stm32f051-tim2-counting-way-too-fast

A timer's prescaler is taken into account after an update event, so for a free-running counter that is used to just count ticks (i.e. it runs up all the way and then rolls over), it will take the full timer count (in my case 65536 - 16-bit timer) for the prescaler to take effect. Manually setting an update event using the UG bit in the EGR register is the solution to this and fixes the issue.

View solution in original post

1 REPLY 1
ARoth.1
Associate II

Well, I posted this prematurely... Did some more googling and found a similar post that had the solution:

https://community.st.com/s/question/0D50X00009Xki8ySAB/stm32f051-tim2-counting-way-too-fast

A timer's prescaler is taken into account after an update event, so for a free-running counter that is used to just count ticks (i.e. it runs up all the way and then rolls over), it will take the full timer count (in my case 65536 - 16-bit timer) for the prescaler to take effect. Manually setting an update event using the UG bit in the EGR register is the solution to this and fixes the issue.