Timer drift

[Bumping_Mos]

I've picked up two discovery f3 board and configured to toggle a pin(in irq timer handler) everytime ARR=17999 on TIM2 with a clock of 36Mhz, derived from HSE crystal on board.

If i connect the two pin to an oscilloscope i notice a drift between the two waveform , not constant offset. How is it possible that timers drift so fast? I need to understand if my timer drift more than 2ms in 4 hours , please give me some advices.

[Uwe Bonnes]

Is there really a drift or is this jitter? Toggling in an interrupt is no good idea. Interrupts have varying response time. Use the compare unit to toggle!

[Danish1]

Crystals are good, but not perfect. Frequency tolerance is often quoted in ppm i.e. parts-per-million.

2ms in 4 hours corresponds to 0.002s in 4*60*60=14400s.

So that tells me your crystals have drifted apart by 10^6*0.002/14400 = 0.14 ppm.

Checking random data sheets for a crystal I see frequency tolerances between 10 ppm and 50 ppm.

I don't think that much drift is surprising.

But what Uwe Bonnes said about driving GPIO from an interrupt is true - you will get jitter. How much depends on the clock-frequency of your processor, and if there are other things that delay that interrupt happening. But these effects are non-cumulative - they'll just be a little fuzziness on the lines - perhaps 1 us - not the 2000 us you quote.

Hope this helps,

Danish

[Tesla DeLorean]

Indeed, but even at ppb and ppt level two independent clock sources will walk away from each other, these things never converge.

[Uwe Bonnes]

Argh, did not read carefully, I though Bumping notices a drift between two timers on the same chip.

[Bumping_Mos]

you are both right , i've already tried what uwe said and it's true but not related to my goal. Your analys Danish is right(i'll check the number on my datasheet)and maybe i've to implement some routine to correct that dinamically at least to halv the error ( i don't if is possible or not)

[Bumping_Mos]

I'm still having trouble with my application. I have a reference 100 Hz signal not always available and i want to count with timer at 100 Hz during this dead period creating a signal "in phase" with the reference one and than re-lock on it when available. I'm trying to debug through value in CNT register or with the aid of a toggling pin but i can't get the two signal in phase even after 20 seconds. I'm starting the counting,in update mode, in an EXTI isr triggered by reference signal but as i've already said with unreliable results. Any ideas?

[Piranha]

Starting the counting with an EXTI by software is nonsense and will not get you to precise times. As a minimum it should be done with timer external trigger or edge on input channel.

But actually to me it seems that you need to implement a "hardware (timer) + software" PLL. You need two input capture channels and one output compare channel. Set input channels so that one captures the rising edge and the other captures the falling edge of your input signal. From those two values and the current ARR value you can calculate the relative (compared to the timer) phase of the input signal. Adjust the ARR to compensate phase. Probably do it gradually and use some filtering for the delta values. Implement the "signal lost" logic, which stops the ARR adjustment.

Not a trivial task, but should be doable...