Timer edge count event on next cycle fails to load updated TnMatchCHR value set above 0x0001.

BP101 said:

the counter will not accelerate in the detected TnMatchCHR counts.

Is it not true that unless the counter's clock source increases in frequency - your hoped for "counter acceleration" is doomed?   You're pretty much alone here with this line of interrogation - forming precise questions is in your best interest...

BP101 said:

...straight 16 bit up count and very low count values.   TnILR has counted to 0x0000.1D0F and TnMatchCHR 0x0000.0004. In 4 edge counts the first interrupt CnMMIS triggers but the timer count does not keep synchronous with edge speed changes...

Say what?   Let us read that again (for the 3rd time!)   Even time in law school cannot prepare one to (effectively) parse that.

And - much of this to run a fan!  

My small group "feels your pain."   And long suffering Amit's pain - as well.   (few other horsemen appear - this scene. {or similar others})

Some here may note cb1's (semi-frequent) suggestion, "Resist the growing tendency to employ any MCU as, Kitchen Sink."   Yet that's what you're doing - is it not?   And if Amit & you "struggle" to communicate, (really) understand & (only then) resolve - might there be (some) alternative?

May I suggest a far simpler, multi-channel (16!) PWM solution - capable of (far faster & immensely easier) PWM generation?   TLC5940 provides 16 PWM channels - 4096 PWM "steps" (that's 12 bits) on each - and programmable output drive.  (up to 60 {yes 60} mA)   To avoid being banished (again) - we note device is from this very vendor!    And the interface is serial - up to 30MHz.   PDF detailing is available from vendor's site - too large (for some reason) for me to attach, here...

More than one way to, "Skin a Kat" - while endless digging/requesting for (very) fine & unique details creates "near guru" status - it has (YET) to "Ring your cash-register" - isn't that true?  Alternative (silver-platter served) here - may lead to that "profit-making, end goal."   (do remember that a gratuity is "normal/customary" - especially when service is special, "silver-platter.")

Hi Amit,

GPTMTnPR, GPTMTnPMR = 0x0000.0000 and remain that way as 8 bit prescaler is not enabled.

TnILR= 0x0000.0006 or any number above TnMatchCHR.

TnMatchCHR = 0000.0002 or 0000.0004 your choice.

After looking edge capture in down count mode It seems as if TnMRSU (1) is not updating TnMatchCHR but only one time during the first TnCMMIS interrupt cycle with the last highest value of TnV/TnR. Not sure what is exactly meant by TnMRSU Updates TnMatchCHR since the new match value is being directly written during the interrupt cycle. Do they mean the timer gets an update load from the MatchCHR on timeout count 0x0000 or does it update TnILR?

BTW: This needs to be updated to include count match interrupt TnCMMIS.

Register 12: GPTM Timer A Match (GPTMTAMATCHR), offset 0x030 This register is loaded with a match value. Interrupts can be generated when the timer value is equal to the value in this register in one-shot or periodic mode. and edge count mode.

BP101 said:

it is difficult to see the acceleration in the counter.

Again - if the clock input to the Timer/Counter remains constant - there can be NO Acceleration w/in that Timer/Counter!

As suggested - TLC5940 stands ready to "Speed, simplify, & enhance" your PWM efforts.   (across 16 channels, too!)

>That said - never have I heard (nor read) of a counter "accelerating."

Might seem that way but consider the edge counters timer BW is capable of synchronizing to a very short 40ns period of 25Mhz. QEI velocity timers don't really capture time between edges that is left more for slow speed GPIO edge capture for speeds under a few 100 RPM. We are hog counting at high speeds being each pulse both edges 2x per revolution from roughly 100Hz to 210Hz at 6300 RPM.

The edge counter timer HW must have a one shot that triggers the count increment synchronous to a fraction of SYSCLK and stops increment counting on the falling edge. That said, we know the time between rising and falling edges becomes shorter as the frequency increase and wider as it narrows. Seemingly the timer edge count acts much like a PLL locking on to the input frequency representing it in a digital count that should accelerate and decelerates with input frequency variations.

The edge match count value is placed in the TnV register, the interrupt fires and we read the value back during the interrupt cycle saving that 1st edge time. That is kept safe until the next interrupt we get an update and compare the time between 1st and 2nd pulses and report the calculation relative to RPM much like QEI velocity time. Now if the SW in the interrupt is indeed proper it should be able to detect the pulse width derived indirectly from the speed of the counter increments relative to input frequency changes. That way we should only be required to capture/match 4 edges or 2 pulses know to occur in each fan motor revolution. Believe me all that is not as easy as it sounds.

Hey CB1 look you hit a home run!
>Thus - if an "edge counter" does not respond "in-step" with an input signal - I'd look hard/long at the quality & delivery of said input signal - ideally right at the counter input pin!

Logic high was running a bit lower than it should have been and seemingly becomes a problem at higher speed by stopping the debug registers from counting. Now see that expected acceleration in the edge count registers.

Note: Acceleration of edge counter increment value is not keeping pace with the speed of incoming edges. Not exactly easy to spot until extending the count beyond 4 edges. CCS debug refresh interval is at the minimum of 100ms so the count at first appears move faster but in reality don't think it is.

Re: home run.  

Box-score reveals cb1's "double play" grounder went thru shortstop's legs. (E6)     Appreciate your re-write of history.   (I've "burned" all local newzpapers)

Even a blind squirrel - on occasion - blunders upon a walnut...   (and puke yellow/orange ain't as kool as GREEN)

Perhaps Amit can enlighten if a real time debugger TnV or TnR edged count acceleration is even possible when the frequency changes.The CCP input signal BW is so narrow it is difficult to know for sure. Though registers TnV and TnB readout speed appear to change with faster edges at CCP input.

Still unable to read more than 100 RPM speed difference even by setting the edge capture range from 4 to 210 edges/sec for the TnmatchCHR interrupt interval. There is no running tally of accumulated edge counts kept in a timer register and TnV=TnR reset 0x0000 at every timeout. The net result of TnMatchCHR appear relative in causing but only faster interrupt cycles with minimal deviation being captured in the count difference. Hence it seems required to move TnMatchCHR and edge capture window into the expected input frequency like PLL changes VCO frequency order to lock onto the input frequency presented to the low pass filter.  The idea remains attempting to off load taco edge counting via larger hog counts asserting fewer interrupt cycles.

PWM mode allows changes TnMatchCHR without need of disabling the timer order to manipulate duty cycle during interrupt handler time. That said it seems that same functionality should be possible in edge capture mode without disabling the timer each interrupt cycle order to update TnMatchCHR.

BP101 said:

re-enable timer does not fair well in edge count mode.

Once again - homonym over-challenges.   (fare well)

Are you doing (all that) [disable, load new value, enable] w/in an interrupt?

If you do not "disable" and the input is (relatively) high frequency - isn't your new setting going to be impacted & your count distorted? (reduced)

I'm a great believer in "modeling" such tests.   Feeding your (already admitted) varying signal level (and rate) into a counter pin seems not ideal.   Instead - use another timer pin as PWM - and feed it into your edge counter - and I BET YOU that your Timer-Counter will, "FARE quite well!"  

It is incorrect to draw conclusions when test conditions are questionable & not fully controllable and/or repeatable.   Testing - as you're doing - with "live & suspect" input signals - is not best/brightest...

BP101 said:

...counter test seems to confirm 3 minutes to count to 50200 edges is proof of skipping 1/2 the input edges.

Let's start w/math.   50,200 edges * 2 = 100,400 edges (alleged).  Then 100,400 / 180 (# of seconds w/in 3 min) = 557.77 Hz.  (frequency of edge signal)  Was that the frequency of your injected input signal?   And - immediately noted - that 100K count "exceeds" the capacity of a 16 bit counter - does it not?  (my quick calc. reveals a counter value of 34,865 - should the 16 bit counter have "rolled over."

Now the legal (you may wish to re-read "rules for & admissibility of evidence") - had your input signal - at all times (throughout the measurement period) - met the MCU input's level, frequency, and rise/fall times?   (frequency seems well w/in - level & rise/fall are of question)

Are you thus asking this kangaroo, MCU court to believe that a TM4C cannot "edge count" a ~600 Hz, "proper" input signal?    Really?  And this fact has escaped vendor's developers - and hundreds (here) who have succeeded w/"Edge Count!"

MCU defense rests...

>Let's start w/math. 50,200 edges * 2 = 100,400 edges (alleged).

Point being made is it should take 103 seconds not 3minutes. Total 50200 edges/minute @ 2pulses or 4 edges/revolution / 60.

6300 RPM the total edges: 50200/60 = 836 edges/second rounded to 840 EDGPS. 6300 RPM pulse rate being 4 edges or 2 pulses/revolution @206Hz measured by scope and DVM. There should not be any roll over with counts up to 0x0000.c4e0 (50200). That is of course if the counter would actually count that fast the way it is now configured. Did this math several times to arrive at edge counts per-minute. The fan does not follow conventional calculator formulas of RPS or Hertz converted into RPM. The fan tech guy mentioned 52.5pps @6300 which after doing the math several times was seemingly to low a pulse count and more in line with 210 PPS * 4 edges = 840 edges/second.

BTW: Have TnMatchCHR updates counting 4-6 edges during TnCMMIS interrupts without disabling the timer. The odd thing is if at any timer TnILR falls below TnMatchCHR during TnCMMIS the TnMatchCHR will rapidly jump up in count 0x0000. FFBA locking the timer interrupt. So it seems TnILR and TnMatchCHR registers will accelerate yet something is holding TnV, TnR from accelerating along with CCP input edge acceleration times.

>TM4C cannot "edge count" a ~600 Hz, "proper" input signal?
How much more proper does it have to be when 50% duty cycle square wave 2.5v logic high? Perhaps all this issue has more to do with TTL open collector to CCP input compatibility?

BP101 said:

How much more proper does it have to be

Does not your TM4C MCU serve as (both) judge/jury in that regard?    And does it not (seem) to reject the correctness of your input?   (or you may have past over-driven or done other damage to that pin)

Beyond all doubt - vendor's TM4C can (successfully) edge count a (proper) ~600Hz input signal...  

I've (past) suggested that you employ another (independent) timer set to PWM mode - and use it to drive the (suspect) CCP input which (currently) troubles.  

Actually vendor datasheet states it can capture edges up to 40ns 25Mhz when timer is clocked by SYSCLK 120Mhz. Apparently not without skipping 2 edges in every captured edge cycle either up or down count mode. That may preclude edge capture can not HOG count in that edge skipping aspect so it seems to have limited uses for edge counts.

25Khz PWM made no difference in the edge counts gathered in fact TnV register seems much slower and this is a new CCP input pin.

BP101 said:

25Khz PWM made no difference in the edge counts gathered

Might you detail - w/some clarity - how you made that determination?   How did you specify & control the "exact" number of "valid" edges fed to your timer's input pin?

As past written here (or your similar posting) my small firm prefers KISS.   Your writing here condemns vendor's MCU's "edge count capability" - yet you've added many additional "bits/pieces" to this mix - and (apparently) judge each/every one of yours, "perfect!"   (I would not - I'd bet heavily upon the vendor's implementation - and not your (nor my) "unique, one-off creation." 

When too many ingredients are, "in the pot" it becomes difficult to know just why, "the brew stinks."   KISS Lives - KISS RULES!    Well filled pot - NOT so much...

>How did you specify & control the "exact" number of "valid" edges fed to your timer's input pin?

Edge counts are relative to edges validated by oscilloscope delta 1/t and digital frequency tester. Fan data sheet claims 4T edges which actually ends up being 5 edges total at two periods per revolution. Get a fan and try it your self the count is not keeping pace even with prescaler, more on that below.


The timers several configuration sections in datasheet make claims does not mean the silicon is agreeing. Datasheet has not elaborated examples of the schemas required to capture edges effectively in all modes as only a few were selected. Table 13-5 claims Tc=8.3ns then has milliseconds for the total time of the 16 bit timer with perscaler enabled. Ok so just how is that possiblke with a 8.33ns period is not backed up by any math. So I play along but TC multiplier value seems more in line with a 16mHz alternate clock source 62.5us and we get extend maximum time for what exactly is not clarified.

My first guess was periodic or one shot modes get extended time and my second guess perhaps they mean edge capture times. That seemed logical since 100Hz is roughly 10ms so why not give that a try in the edge time capture mode. Now we should be able to capture the dang taco frequency if we cant very well capture the edge counts from what seems as edges being skipped. That really shouldn't matter if at least some count of exact edges can be captured at any frequency under 25mHz.

So I make the extended time 10.59ms for 100Hz low fan speed edge time capture for either clock source. Wouldn't you know the very same gibberish values read back from edge count register TnR also is read back for edge time capture mode. This tells me the edge time capture and count events are not actually what they seem or there is trouble in this area of the peripheral.

BTW: Did take a look at the edge count example and it was written for another MCU with LCD. The code as written really does not confirm any real functionality of external edge counts input to CPP other than a time base being in sync with SYSCLK. Amit should try to capture Taco signal counts, since it is so easy TI surly has a DC muffin fan hanging around or just use the taco signal from any BLDC encoder. Edge counts and edge times capture should not produce the exact same data in both timer modes.