STM32H7 Input Capture Measurement Offset

[Tkmn]

I am am trying to assess the accuracy of the input capture measurements by capturing a stable periodic pulse, setting the output compare on another channel of the same timer to the measurement, and then measuring the offset on a scope. It appears there is a pretty consistent 25ns lag in the input capture measurement. 

What primarily drives the lag and should/can this be calibrated out?

[AScha.3]

You connect pwm output with a wire to capture input pin - right ?

Then the external signal is going to input filter and is synchronized to the internal timer clock.

This needs minimum 1 clk.

see rm , timer x :

 

[Tesla DeLorean]

The typical resynchronizer has multiple stages, this filter setting might drive that, but I'd expect it to act as a delay line all the same.

[Sarra.S]

Hello @Tkmn 

As @AScha.3 already mentioned, this lag could be primarily driven by the filter value set in the CCMR1 register.

Incorrect filter values can cause a delay in the input capture measurement, you can manually modify the register to set the correct bit.

Please note that this might not be the only factor (configuration of the timer, the clock speed,.. ) 

[waclawek.jan]

> and then measuring the offset on a scope

Offset of what against what?

JW

[TDK]

> setting the output compare on another channel of the same timer to the measurement

Details matter here. How are you doing this exactly?

I wouldn't expect a 25 ns lag on IC.

[Tkmn]

I was not expecting 25ns either....

Hardware wise, I am running everything off of a GPS disciplined oscillator. So HSE is on 10MHz and I am capturing 1PPS off of the same DO so the input capture value is extremely stable.

I have configured TIM2 with a 240MHz clock rate to update once a second. I input capture 1PPS (rising edge) on channel 1 and then I set the output compare value on channel 4 (polarity low to high)  to be equal to the input capture value. When I compare the rising edge output of channel 4 to the rising edge of 1PPS input on channel 1, I always observe a 25ns delta.

I can play with the filter configuration as suggested but I suppose I was expecting this to be maybe 1/480MHz or 1/240MHz and I'm not sure what is driving the additional delta.

[TDK]

When you look at the 25ns delta on the scope between the two edges, you're looking at the current TIM2_CH1 edge (from the GPS) vs the previous IC value that was captured and sent to TIM2_CH4 from the previous second. To me it seems like you have ~25ns drift over 1s.

I may be misinterpreting the details a little, but it does feel like you're comparing edges from different things.

This would be a good test to determine the same thing: Hook up TIM1_CH1 and TIM1_CH2 together, set CH1 to be IC and CH2 to be a PWM and see if the IC value exactly matches the programmed PWM value.

[MasterT]

GPIO pin driving strength? 

FYI, Timer's input capture pins as any general GPIO pins, have logic synchronization module, so they always jittery - depends on system clock derived to GPIO bus. 

There is LPTIM that possible 'd be driven externaly, I have not tested yet it's functionallity

[Tkmn]

I am seeing the same issue when I loop back. For example when I set output compare of CH4 to 1000 and I feed it into my CH1 input capture, the input capture is 1008. 

This is on the Nucleo... I'm not sure that there is any hardware that would cause a line delay in between but I can check filtering next. I never messed with the filter settings in the register. I assumed the default was none but not sure.

[Tkmn]

My CR1 value is 129 and my CCMR1 value so I think it should be sampling at 240MHz and not applying filtering. I can try to increase the rate to 480 MHz to see if it halves.

[Tesla DeLorean]

There is a resynchronizer circuit on the input figure 2 - 3 flop-flops in a chain.

It's going to add delay, and behave like a nyquist sampler.

I think it's off the TIMCLK, 120 MHz ?

[Tkmn]

That tracks with the delay, but is that a limitation of the H7 package? To maybe reset here...should I be using the HRTIM instead for something I want to capture as accurately as possible? Just saw in the clock tree that everywhere else 240 MHz is the max except for feeding HRTIM.

Sorry I'm a stm newb and still working my way through the docs and TIM was a bit more accessible to begin with. Should I migrate to HRTIM?

[Tkmn]

Looking through the HRTIM section and I don't currently think it is that attractive compared to standard timer right now due to the limitation in period counts. However, it does seem that the delay is documented in the external event section of HRTIM as 2-3 cycles of internal re-synchronization and then a 3 cycle delay on the output totally 5-6 cycles of latency.

I assume the same holds for the standard timers. So my 7-8 cycle offset seems to be ultimately attributable to a combination of GPIO speed and this delay. Going from LOW to FAST/VERY FAST GPIO speed on output compare reduced the count offset to 5, which is explainable by the ~2 + 3 slip documented for HRTIM. 

But understanding that also means I think I can safely adjust it out. Thanks all!

[waclawek.jan]

> I am seeing the same issue when I loop back. For example when I set output compare of CH4 to 1000 and I feed it into my CH1 input capture, the input capture is 1008.

Interesting; thanks for that experiment.

> Going from LOW to FAST/VERY FAST GPIO speed on output compare reduced the count offset to 5

I wouldn't expect even 5.

Btw. you might've done the experiment not at high system/timer clock, but low - as things are synchronous, the real frequency does not matter - and then the GPIO contribution would be negligible.

Another remark is, that you cannot distinguish latency of the output (i.e. delay due to circuitry between the comparator and actual output, which e.g. in case of timers with complementary-outputs-and-break (such as TIM1) may IMO be more substantial than in timers without that) from latency of the input. They add up.

JW