Design Anomaly with TIMx Input Capture Prescaler

[design5]

Posted on March 11, 2009 at 19:09

Design Anomaly with TIMx Input Capture Prescaler

[design5]

Posted on May 17, 2011 at 13:06

Hi Fellow Programmers:

After a few days of sleuthing, I discovered a design anomaly with the TIMx Input Capture Prescaler. At first, it appeared that the prescaler, which can be programmed to divide by 1,2,4, or 8, was always dividing by ''one'' in my application. After a thorough investigation with test hardware jigs, I discovered the following anomalous behaviour, which may help some of you avoid the inherent pitfalls:

When the TIMx Input Capture circuit is disabled (TIMx->CCER register bit CCxE = 0) the Prescaler 2-bit code may be loaded into the ICxPSC bits of registers TIMx->CCMR1 or TIMx->CCMR2 (if required). Whether or not a new value is loaded, according to the Hardware Manual (page 315/682, IC1PSC description associated with section 13.4.7) ''The prescaler is reset as soon as CC1E = 0''. This is well and good, provided we know what ''reset'' means. After the Input Capture Circuit is enabled (with CCxE = 1), the prescaler is ready to accept the input capture pulses and start dividing those pulse by 1,2,4, or 8, according to the ''set-up'' modulus.

However, the prescaler DOES NOT count out the first modulus before making a capture, but instead, makes a capture on the FIRST input pulse. Thereafter, the modulus begins to function according to its ''set-up'' value.

CAPTURING ON THE FIRST PULSE IS THE PROBLEM, INSTEAD OF COUNTING OUT THE MODULUS BEFORE CAPTURE.

There may be some applications which would like to have an initial capture, and subsequently have the prescaler functioning, however there is at least one application (mine) which requires that the modulus be effective from the beginning. That is, when the prescaler is ''reset'' (or should I say ''pre-set''), I expected it to be reset (or pre-set) to its ''set-up'' modulus value and I expected it to count down the first 8 pulses (in my case) before making a capture. Too bad it does not work this way.

In my application, I need to capture only after more than 8 pulses occur within a given time window. Therefore, at the beginning of my 50ms time window, I reset the prescaler (with CCxE = 0 then CCxE = 1, because I don't know how many pulses have been prescaled before my time window begins) then test for a capture within the remainder of the time window. Unfortunately, I always get a capture from the first pulse, so the prescaler is effectively useless in my application.

If anybody has a solution (that is, don't capture until at least 8 pulses occur on TIM3 input during a 50 ms window) then I would welcome any ideas.

For the ST Moderator, and ST Design Team, I would like to know what can be done to modify this behaviour so that the Input Capture prescaler can be used effectively right from the very first input pulse, and not have the first pulse make a capture.

If you could have new silicon for me within the next 6 weeks, that would be wonderful.

Thanks,

Garry.

[David Brooks]

Posted on October 20, 2015 at 18:36

I'm experiencing the exact same problem. Despite several related posts, I have not found a solution. My 2-channel frequency measuring code is working fine. I enable input capture via HAL_TIM_IC_Start(), wait for 1ms and then HAL_TIM_IC_Stop(). I read the data at the end of the 1ms just fine. However, when I change the prescaler to 8 in order to make better use of the 16/32 bit range, the captured count does not change.

[waclawek.jan]

Posted on October 20, 2015 at 19:18

Accepting it as a fact?

Why would that be a problem?

JW

[waclawek.jan]

Posted on October 20, 2015 at 22:21

> However, when I change the prescaler to 8 in order to make better use of the 16/32 bit range, the captured count does not change.

Then it's not the same problem. The problem described here is that the capture happens after the very first incoming edge, rather than after 8th. You say you have no capture.

Please start a new thread, stating exactly what are the circumstances are (including the STM32 model) and what is the problem. (Don't edit your older posts, this forum then messes up the posts order.)

JW