Tim5 in Capture mode to measure the time period between rising edge on 2 different GPIOs

[JSven.9]

Hi,

I am trying to measure the amount of time between the rising edge on two different GPIOs using TIM5. one assumption I make is that one of those GPIOs will happen first.

Actually 3 gpios are involved in the application, PA0, PA1 and PA2, PA2 is configured as an output, PA0 and PA1 are in alternate mode to be used as capture triggers for the TIM. PA0 and PA1 are both connected to some other system which Is the system I want to measure "response time of". PA2 is connected to PA0.

The Tim is configured to fire an interrupt on the event on PA1. When this happens the ISR sends a message to a mailbox, containing the contents of CCR[0] and CCR[1].

So the approach goes like this:

1. write a zero on PA2 and wait until PA0 and PA1 both read 0 (the SUT has to obey the protocol)
2. clear the CCR registers and restart timer from 0
3. write a one to PA2
4. blocking wait on the mailbox for the message from ISR.

So the intent here is to measure the time from writing a one to some external "SUT" and wait for it to reply by writing a one on another pin.

After receiving the message from the ISR, the number of ticks can be calculated by subtraction stop_ticks - start_ticks essentially. and the time in ms can be obtained by dividing that value by 84000. (I am on an STM32f407)

This seems to work quite well to measure time periods of 1,2,3,4,5... and upwards ms. But when measuring a timeperiod that on the oscilloscope shows up as approx 1.5us, this system measures a time of about 3us. (so big percentual error at small time periods).

These periods (1.5 - 3us) are some number of hundreds of clock cycles at 84MHz so I assume a rising edge can be detected a lot faster than that. An 84MHz timer should have a period of slightly above 10ns, so I was hoping to get approximately that precision on the measurements.

So I wonder, what might cause this error offset?

How long does it take to detect a rising edge in clock cycles of the timer?

Any thoughts about this approach? are there some common pitfalls?

Thanks a lot everyone.

[LCE]

I'm currently working with the STM32 timers, so to me it looks like you set up everything alright.

Are the CCMR settings (filter) for both channels the same?

Maybe it's a floating point precision problem when working in ms?

Check the "pure" tick difference, maybe that is correct?

I recently had to use 64 bit variables to get some exact results when working with nano seconds from the PTP hardware.

PS: What's a mailbox in that context? I'm a hardware guy...

[JSven.9]

Hello, Thanks a lot for the input.

The input capture filter settings are the same on both channels. They are both set to 0. I am really not certain all of the settings I have set make sense, these timers are complicated! ;)

When I checked the tick diffs and did the arithmetic I get the same results.

A mailbox is just an abstraction provided by the RTOS (in this case Chibios).

Ill keep digging though ;) Have a nice day

[Tesla DeLorean]

Typically you'd just let the counter free-run and then delta the latched CCR values from the 2-channels.

The 16-bit TIM would clock faster.

For tight/precise A-to-B timing, perhaps look at the TDC7200

https://www.ti.com/product/TDC7200

[JSven.9]

Thank you, that's true. The restart of the timer is not essential and can be dropped. Thanks for the component pointer.

[TDK]

The timer IC value is captured at the first timer tick when the condition exists. It certainly doesn't take hundreds of ticks to be written. There must be something else to explain what's going on. Perhaps multiple edges are occurring before/while the CCRx values are read.

[JSven.9]

Indeed. Something Is going on, probably me doing something a bit off somewhere. Ill keep digging.

Multiple edges should not really be the issue as I am in control of both devices, the "responder" and the "inquiry to response time measurer". The responder is a toy program currently that just reads one GPIO and copies its state to another.

[JSven.9]

Thanks a lot all of you for the hints! Turns out I was using this mode "1111: f SAMPLING=fDTS/32, N=8" on the IC1F and IC2F... And just hours ago (up there) I read the wrong line of code and was sure it was set to 0000.

Thanks for the input and have a great evening

[waclawek.jan]

PA2 is open collector? What's the rise time?

 

> 2. clear the CCR registers

 

Why?

 

> the number of ticks can be calculated by subtraction stop_ticks - start_ticks essentially

 

What is "stop_ticks" and what is "start_ticks"?

 

> timeperiod that on the oscilloscope shows up as approx 1.5us

 

Show.

[EDIT] OK solution provided meantime.

JW