STM32 timer ETR mode + slave reset

Forum|Forum|6 years ago
December 18, 2019
3 replies
1892 views

Hi,

I need to periodically count the number of pulses of signal A between two rising edges of signal B. For that I use a timer (TIM2) in ETR mode (signal A is the ETR input), input capture on signal B and slave trigger+reset on signal B rising edge.

Now I see the following problem: if both signals are in sync (e.g. B = A div 4) there is consistently one edge lost during the counter reset. I.e. the counter counts up to 3, not up to 4. Clearly, it is not the best idea to count pulses of the two signals with 0 phase shift, however I would assume that if the counter incremented during the reset it would add up to the next period of B. That does not seem to happen. I assume that is perhaps due to the internal synchronization of the two signals, each going through a different path.

Can someone please shed a bit more light upon it and possibly suggest how to get around it if the signals are in sync.

Thanks

Petr

TIM

This topic has been closed for replies.

waclawek.jan

Super User

It takes some time until the reset signal propagates from the input through the slave circuit into actually resetting the counter. This may be (and probably is) a different time than the propagation time from ETR to the clock increment. Don't forget, that the timer is still synchronous to the internal clock, i.e. all these processes are clocked by the internal clock.

Try to use plain capture instead, on both edges of signal B and then subtract the two values (you may use the capture to two different channels, as is in what ST calls "PWM input", without the reset of course). I don't say it will work better, but try.

JW

PKulhAuthor

Associate II

Thanks Jan for your response. I was expecting something like that.

An update: I was wrong, sometimes it also counts up to 4. However the number of cases where it counts up to 3 is about 7x more than the number of cases where it counts to 4.

Indeed I already tried the other proposal of yours. There no counts are lost, i.e. it always counts up to 4. However there if an interrupt is lost the difference will be over more than 1 period of B, which is not exactly what I need. That is why I am currently trying the slave-reset method.

I'm also going to try whether using the trigger interrupt in ETR+reset instead of capture would help. But it seems the problem is more the difference between the clock path and the TIx path.

waclawek.jan

Super User

> if an interrupt is lost

If this is a concern, you can use DMA to move the captured values to an array in RAM. There's still some latency and risk, e.g. if there are lengthy concurrent DMAs on the same DMA and/or concurrent and lengthy accesses on the buses used (e.g. if you'd DMA into an external memory which waitstates and/or is used in bursts by some other busmaster) but here we are talking say a dozen of system cycles, rather than hundred(s) or even more in case of interrupts (depending on how do you arrange priorities).

You of course are responsible for the latencies in your program.

JW

Sign up

Login with SSO

Login to the community

Login with SSO