Correct way to read timer counter register

[christophkeiner9]

i have a question regarding the correct way of reading the timer counter registers.
I learned not to read timer couter registers asynchronously, because it can lead to spourious wrong values if i read just when the timer changes it's value.

In several posts, i read it's easy, only read TIMx->CNT.

Isn't it important first to disable the counter, then do the read operation and after reading enable the counter again to avoid this effect?

[TDK]

You can read it whenever you want with the TIMx->CNT syntax. The value will be correct at the time it is read.

The include files defines this register as volatile which forces the cpu to actually read the register every time it is accessed rather than allowing it to cache the value.

[Tesla DeLorean]

Define "wrong value"

The Read at the MCU/Peripheral level is singular and atomic. The counters are synchronous with the APB/CPU clock. CNT should always fall within zero and ARR

Depending on the relative speeds two reads will be different, so not like a slow RTC where you're reading two registers, and you read both twice until you get the same values.

You could also read twice insuring the second is different so you observe the front edge of the tick rather than some random interval between counts, but will depend on the speed of the reads vs those of the count itself. Want to measure milliseconds, perhaps use a count that's 10x or 1000x faster so you get resolution, and not low granularity.

Trying to read MULTIPLE TIMx->CNT, going to hard to be able to STOP them both at identical instant unless via common hardware gating signal.

[christophkeiner9]

I try to define wrong value:

if i read a register that is just changing it's value due to a clock event, then it is not clear to me, that the value is OK, because the bits don't change all at the same time.

assume change from 0x00FF to 0x0100. In this case, 9 bits are changed, if i read in between and maybe not any bit has already it's value.

lets assume the bits 0 to 7 are already 0 and the bit 8 is just getting "high" but at the time of read it is maybe still zero, then i would read 0x0000.

I had this issue before with other micro's.

As i understand your reply, it is no issue if the Timer is clocked by sysclock, because then the read is definitely not at the time of counter changing, is this correct?

By the way, my tests actually show that is the case, i got (so far) no wrong reads of the CNT-Register.

[TDK]

As far as reading the timer counter register from the CPU is concerned, bits all change at the same time. It doesn't change one bit at a time with the CPU having the possibility of reading an intermediate state.

[waclawek.jan · Accepted solution]

TIMx timers in STM32 are synchronouos with the APB bus on which they reside, i.e. all registers which are read do change synchronously with the bus. In other words, you can safely read them anytime.

LPTIM and RTC are a different issue, but the former is not present in STM32F1xx, and the latter is a special case anyway.

JW

[Tesla DeLorean]

The count is synchronous, you're not going to observe ripple or meta-stability, certainly clocking below critical path limits. If you're close to those the MCU is going to be malfunctioning in any case.

Even with external clocks, the inputs go through a resynchronizer which will align external edges against those of the APB/TIM CLK. This can exhibit nyquist sampling behaviour, ie aliasing / negative frequency.

[LCE]

> lets assume the bits 0 to 7 are already 0 and the bit 8 is just getting "high" but at the time of read it is maybe still
> zero, then i would read 0x0000.
> I had this issue before with other micro's.

Oh wow, I hope that's 30 years ago?
If not, which microcontroller?

Last time I saw that was with programmable logic, and some constraints were not set properly (by me).

[Piranha]

By the way, the RTC peripheral's date/time registers has such a behavior. But it's a hardware design flaw and is described in the errata.

[christophkeiner9]

No, it's not 30 years ago ;).
It had this issue with a msp430x2xx, you can choose stopping or majority vote: