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?

[Tesla DeLorean · Accepted solution]

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 ?

[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.

[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