• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 383 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Edge count CCP input not keeping synchronized with GPTMTnR and GPTMnV.

Genatco
Guru 56043 points


Timer in edge capture up count mode does not seem to properly increment relative edge speed to TnV or TnR keeping synchronous to CCP input edges.

Example if TnILR=0x0000.CE44 and TnMatchCHR=0x0000.CE40 it takes well over 3 minutes for the TnV or TnR to reach 50,400 edges. That is if the CCP input signal edges are incrementing the count at 210Hz the count speed in TnV or TnR does not appear to change to CCP edges input. Timer keeps counting slowly until it resets 0x0000 3 minutes later.  Remove the CCP input signal and TnV and TnR stop counting. The timer CCP input at 50,400 edges should roughly take 103 seconds to reach at 480 840 edges per second.

There seems to be a disconnect between the actual timer register increments in TnV or TnR as to the input frequency of edges. regardless 100ms debug refresh interval.

Should not the edge count timer mode be capable to keep up with the edges on CCP input incrementing the count, from 100-210 Hertz @2v52 high level? 

Should not the timer edge counts accelerate or decelerate relative to CCP input frequency changes, long as the edge remain in state for more than 2 clock periods and no alternate clock source is being used?

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/467999/1682525#1682525

  • 0
    Guru 117855 points

    BP101 said:
    timer CCP input at 50,400 edges should only take 103 seconds to reach at 480 edges per second.

    Math alert!   Even our humble Z8 MCU "knows" that 103 * 480 = 49,440!   Which is NOT your 50,440!  (very recent guru status does not enable such (obvious) lack of "fact checking.")   {and should a non-obvious factor (explain) those "missing" 960 edge counts - such should be explained...)

    You've long since kicked KISS to the curb.   Methods & interlocks you employ (may) overcomplicate - and are fraught w/peril.

    KISS would see your (proper) input signal (first) injected into the CCP pin (which is not exclusively an input) and test/verified.   Only then would one (build) to the (only one new item) next level of bp101 complexity - and repeat the test/verify of the (now) interlocked timer(s) set-up.

    As you've found (quite consistently) - especially over the past few months - "all in one" function cobbles too often "confound rather than clarify!"

    KISS has been - and remains - your salvation...  (such "cobbles" (may) work - but should be individually tested to "tease out" their sensitivities & secrets...)

  • 0 in reply to Genatco
    Guru 117855 points

    Non guruian...  ("typo" hardly describes/justifies)
    Such lack of "attention to detail" renders the remainder of your request/reporting equally "questionable/suspect" - does it not?