what is the timing diagram about writing TIMx_CNT register

[Yang Yang]

Hello, ST expert

 

STM32F407 is used for our custom design. And htim2 play the role of precise timing base.

When htim2->Instance.CNT = xx  is used for setting a new counter start value for timer2, it seems that the new counter value does not functions immediately, I mean that the next counter value does not appear one clock period later. 

Is there any timing diagram when TIMx_CNT register is written by user program?

 

BR

Yang

[Tesla DeLorean]

There isn't

Several things clocking at different speeds, assume write to AHB->APB is going to take in the order of 4 cycles. and is deferred through 2 write buffers. You need to use a fencing instruction like DSB or a memory read to force completion / in-order-execution 

The TIM are synchronous, but can run at 2x the APB clock, the prescaler (PSC) is not visible to you, so CNT may latch vs count apt to be somewhat unpredictable for PSC != 0

[BarryWhit]

[Retracted]

[Yang Yang]

Hello, BarryWhit

 

I am sorry for the unclear description. I am talking about the TIMx_CNT register.

 

BR

Yang

[waclawek.jan]

> the next counter value does not appear one clock period later. 

True, as @Tesla DeLorean said above too; but why does it matter?

JW

[Yang Yang]

Hello, jan

 

According to my measurement, it takes effect after about 4 micro seconds in the case of 8MHz CPU main frequency, 4MHz htim2 clock frequency. That means the next counter value appears 4 micro seconds later. I am not sure this is correct. Is 4 micro seconds delay possible?

In our application, the interval between two successive GPS PPS(pulse per second) signal should be recorded precisely. E.g. After the first PPS, the htim2->Instance.CNT set to 0, and when the next PPS comes, the interval is recorded using the change of htim2. And I found that the first interval is always 1 second minus 4 micro second, but the later intervals are always precise 1 second. So I doubt that the reason is the delay.

 

BR

Yang

[waclawek.jan]

As you haven't posted further details, let me guess: you have an external interrupt (EXTI) set to trigger upon edge on the GPS PPS signal, and in the interrupt service routine, you decide upon some flag, whether

A) to set TIM2_CNT or

B) to read out its value and store/check/process.

If yes, then the main difference is in the amount of software executed for those two cases A) and B).

JW

 

[BarryWhit]

> the interval between two successive GPS PPS(pulse per second) signal should be recorded precisely.

 

Isn't this exactly what timer input capture is for? you can also (on G4 at least) configure the peripheral so that each input capture resets the count. That gets you a time-difference value for free. You can use DMA to write these delta values into a buffer offloading the CPU from both the memory accesses and the math (you said you're running at 8Mhz, so save your cycles). The resulting precision should be very high.

 

Update:  remember to discard the first delta value, since its t=0 is the moment you start the counter in software, and not the moment an edge occurs on the external pin.

[waclawek.jan]

> you can also (on G4 at least) configure the input capture event to reset the counter after each capture event, so that you get a delta value for free

That's available on all STM32; but be aware of that that delta is off by an undocumented value (one or two cycles - @Tesla DeLorean posted an experimentally found value this in the past), due to the slave-mode controller quite understandably delaying the reset after the capture.

Calculating deltas "manually" from the captures is a sure bet.

JW

[BarryWhit]

@Tesla DeLorean do you remember the thread JW mentioned? I'd like to read it.

 

Update:

> but be aware of that that delta is off by an undocumented value (one or two cycles)

I wouldn't have expected it to be even that good, since the external signal is async to the STM32 clock domain. There has to be a synchronizer somewhere in the path (even if you were using an FPGA) and that is fundamentally non-deterministic.  Any fixed (systematic) error can be compensated for, sometimes even for free (for example by tweaking some threshold constants in a conditional). If it's a couple of cycles it's usually not an issue.

In the stated application (GPS PPS) the external interrupt apparently has a nominal period of 1 second. So way way not an issue. Still good to know.

[waclawek.jan]

https://community.st.com/t5/stm32-mcus-products/reset-after-capture-delay-in-timer-a-lost-thread/td-p/689584

JW