TM4C123GH6PGE: I need the edge_time example file.

Hello. Charles

1) Yes, that's right. You have never said that it takes 8 CPU cycles.

    In the previous block diagram representation, I understood that 8 cycles were short for ISR processing.

   I asked how many cycles it would take to process an ISR routine.

   I'm sorry if I made you uncomfortable.

   I will refer to Mr Buruno's  explanation of ISR processing cycles.

2) Please check the following information.

   Input Edge-Time Mode is described in the datasheet as such.

   Note: For rising-edge detection, the input signal must be High for at least two system clock periods

               following the rising edge. Similarly, for falling edge detection, the input signal must be Low

               for at least two system clock periods following the falling edge. Based on this criteria,

              the maximum input frequency for edge detection is 1/4 of the system frequency

   Q1> What is the difference divide by 4 between Input Edge Time and input Edge Counter ?  

   Q2> Is the meaning of 1/4 because the edge needs to detect 4 edges with 2 rise and 2 fall  ?

  I do not understand what you told me, so I ask.

  Q3> What is the maximum period that can be detected = resolution x system frequency or resolution x (system frequency / 4) ?

  If divide by 4, the minimum input signal frequency that can be detected is 20MHz or 10MHz ( When system clock is 80Mhz or 40Mhz)

  Q4> Is it possible to detect 20Mhz or 10Mhz as an input signal?

         the calculation, Maximum detection period  = resolution x Sysclk

         What is resolution? If the resolution is timer resolution, With the previous values is 0.01% = 100 ns.

        if not, 16bit timer , 2^16= 65536

 For example >   100 ns x 80MHz = 8 sec

               Q5>  if not,  12.5ns x 65536 = 819.2 us  , Is this correct?

thanks.

Hello Charles.

I have been studying the source code you designed. (3124.tm4c123_timer_edge_time_mode.zip)

Input condition is 1Khz duty 50% signal. (TM4C123gh6pge, Port F, Same signal , Simultaneous input PF0(T0CCP0), PF1(T0CCP1) )

(Timer0AIntHandler, Timer0BIntHandler), only Timer0A does not jump to ISR.

I am worried and I am going to ask questions.

Q1> Let me know what's the problem. ?

I thought of the output of the log output below.

timerLoad vlaue , 39,999 ( 40,000 - 1 count) ,

Q2>  why is 1 minus ?

- timer module  clock 40MHz ( T_clk : 0.025us)

1Khz, duty 50%  T_input : 1000 us,  t1: 500us , t2: 500us

(Result ) DUTY =  500us / 0.025us = 20,000 

Q3>   Is this correct, duty = 20,000 ?

thanks

[Attach image]

1. CCS Tool

2.  Keil tool

Hello Bruno.

Thanks for the answer.

- TM4C unlocked and commit register be set.  C0-3, D7, F0, E7

Resolved.

thanks

Hello Bruno.

Let me know about three questions.

Attach images to help you understand.

thanks.

 [Attach images]

Jame,

1) Read again my message from two days ago, the part which starts with MORE IMPORTANT. You seem to have ignored it.

2) You are still confusing duty with period. Google for PWM and try to really understand those.

3) Your signals certainly varies 18 CPU cycles, simple as that. If you need better tolerance, you need to check if the sensors you use are able to deliver that, you need to check the capacitance of your traces, the healthy of your signal, all the details that bring measurements to the next level. It is not unusual in measurement science that 10x better accuracy costs 100x more time and money to be achieved.

Regards

Bruno

*LIKE*

Bruno Saraiva said:

If you need better tolerance, you need to check if the sensors you use are able to deliver that

Let me emphasis this. If you need better tolerance you first need to verify that both your sensor and the process you are measuring are actually capable of delivering consistent stable values to fit your tolerance.

Bruno Saraiva said:

It is not unusual in measurement science that 10x better accuracy costs 100x more time and money to be achieved.

This may actually be an understatement.

Robert

As always - "KISS" would direct that a known, sufficiently "precise" (not necessarily accurate) PWM signal source be employed initially.

Such substantially eliminates (surely reduces) variances caused by the "less proven" (always suspect), "sensor/interconnect/power source."

Hello Bruno.

Before I first asked the question e2e.ti.com/.../2286628,   I thought about several things.

Line capacitors from previous answers, input signal status checks

What I think is as follows.

1. It is a counter error to jitter inside the MCU chip.

2. The Timer Module clock inside the MCU chip shakes.

3. Detection input signal shakes

The input signal is not shaken to the scope as confirmation.

The input signal uses the PROBE COMP 5V & 1KHz signal in the oscilloscope.

Re-question 1> Why does not the counter value on the log picture go out sequentially?

                      - I do not know the previous contents. Please explain in detail.

                     - Ask question 1 in your previous reply.

Question 2> Is the 1Khz signal fast?

The ultimate goal is to detect the 20Mhz input signal at an edge time of 80Mhz

However, due to the edge time error of 1Khz input signal, we can not go to the next step.

Question 3> Is it possible to detect edge time of 0.05us and half period of 0.025 us?

-  The datasheet details the possible edge time or counter capture.

- The input detection signal is described as detecting up to 1/4 of the system clock.

thanks.

Jame shin said:

1. It is a counter error to jitter inside the MCU chip.

2. The Timer Module clock inside the MCU chip shakes.

Based on my experience, there is zero chance of either of the above

Jame shin said:

3. Detection input signal shakes

While "shakes" is too much of a generic description, that's what myself and others suggested: the sensor signal is probably not precise to 12ns - does the vendor guarantee that precision? Do you need that precision for your application???? What DUTY variations are you getting??? You have not yet informed such.

Jame shin said:

The input signal is not shaken to the scope as confirmation.

Can you provide evidence to such? How many samples did you log with a oscilloscope? Do they all show the very same duty cycle? I don't think so... Even on a reasonable 100MHz scope, if you apply a "typical PWM 1KHz sensor output", you will see variations at least on the 0.01% scale.

Jame shin said:

Question 2> Is the 1Khz signal fast?

To measure duty of that signal, your CPU needs to perform VERY SIMPLE CALCULATIONS after every rising edge transition. It has almos 80 thousand clock cycles to do that. I'd say that those calculations don't consume more than 200 cycles, leaving +79,000 clocks for a good rest! While there is no such thing as an official designation for "fast signal", do you think 1KHz is fast?

Jame shin said:

The ultimate goal is to detect the 20Mhz input signal at an edge time of 80Mhz

There are a few posts on this forum discussing the minimum capture period of a timer on TCCP mode. They all show the 1/4 cycle. You have been repeating and/or adding new questions to this already long thread, and this is just getting confusing and not really helping either yourself or anyone else. I'd suggest you reorganize your thoughts, read about the PWM signal definitions, apply the full-width counting approach mentioned before, and also read the "minimum period capture" posts available around here. Then, if still doubts remain, post a new, separate, concise question.

Regards

Bruno

Jame shin said:

What I think is as follows.

1. It is a counter error to jitter inside the MCU chip.

No. That's unlikely. There is an inherent precision measure of +/-1 count with a digital devices but that's really all you are dealing with.

Jame shin said:

2. The Timer Module clock inside the MCU chip shakes.

I believe the word you are looking for is jitter. Shaking involves physical movement.

However this does raise a question. What are you using for a clock source?

Jame shin said:

3. Detection input signal shakes

The input signal is not shaken to the scope as confirmation.

How have you taken this measurement? Note that you measure on the IC 18 counts in 20000 or 0.09% so whatever technique you use must have better accuracy, precision and stability than this.

Jame shin said:

Question 2> Is the 1Khz signal fast?

The ultimate goal is to detect the 20Mhz input signal at an edge time of 80Mhz

On a cycle by cycle basis!?? Not going to happen. That would leave 4 cycles between cycles for all your setup and calculations.

If you have the simpler task of verifying frequency every few ms or so there are much simpler techniques.

Robert

"And his cpu shook like a bowl full of jelly."    (love it when you/others here "speak tech.")
Yet - we are told - the "jelly" experienced (just) "jitter."     (and finally - (exhausted) others are (now) properly calling for "Slaughter Rule!")

Hello  all.

Thank you for your reply.

e2e.ti.com/.../2286628

How do I resolve this jitter? ?

I will ask the attached image and concise again.

1. Why skip instead of sequential?

    [ Figure1. Log message & SW diagram]

2. Attach the image to the input signal status.

    Oscilloscope sample rate 1GS/s (CH1: T0CCP0 , Ch2 : T0CCP1) , 

    How do you view the image? 

   - Is the count error generated by the external input signal not the internal MCU 

Finally,  How do I resolve this issue?

After solved, I want the final target to detect 20Mhz of input signal.

thanks

Jame,

Bruno

it is not possible to measure a continuous 20MHz signal with a TM4C123.
Q> Please let me know why. ?

" Input Edge-Time Mode "

Note: For rising-edge detection, the input signal must be High for at least two system clock periods

following the rising edge. Similarly, for falling edge detection, the input signal must be Low

for at least two system clock periods following the falling edge. Based on this criteria, the

maximum input frequency for edge detection is 1/4 of the system frequency.

thanks

Jame, can you agree that "the detection of a signal transition" is not the same as the "measurement of a signal's period and duty"?

Jame shin said:

it is not possible to measure a continuous 20MHz signal with a TM4C123.
Q> Please let me know why. ?

I already did.

This, however, leads to a more basic question. What are you trying to do? You've spent a lot of time of this method only to raise this 20MHz spectre. It seems unlikely to me that you are trying to measure the cycle by cycle duty cycle at 20MHz so what are you trying to measure and how frequently?

Robert

Bruno Saraiva said:

the detection of a signal transition" is not the same as the "measurement of a signal's period and duty

Indeed that's true (and once again - devil lurks, such details.)    

Poster Robert has well noted the "failure" of o.p.'s claim that, "Limiting such measure (and processed calculations) to 1/4 System Clock - insures success!"    In fact - it does not!    (clearly (some) "time" is required for the MCU to "process/calculate" - which (further) erodes the 1/4 System Clock claim!)    

Performing such measures upon a "cycle by cycle" basis - I would think - is reasonably rare - and "aggravates the impact of (both) signal & measurement "jitter."    

As Robert has identified - posters rarely (i.e. never) justify their desires - yet expect, "never ending, high-level response."    And - as posters are "unable to solve their challenge" - how likely is (that challenge) to be correct - or best suited - or even reasonable?    

The "time-logging" of a reasonable number of (both) "rising & falling edges" - via the long suggested "dual Timer approach" (i.e. for simplicity) - well enables, "After the fact" calculation of (both) signal period AND duty cycle - over a reasonable time interval - which likely reduces the impact of "signal & measurement jitter."    There is - almost surely - no basis to poster's quest for "cycle by cycle" measure.

cb1_mobile said:

"After the fact" calculation of (both) signal period AND duty cycle - over a reasonable time interval - which likely reduces the impact of "signal & measurement jitter."  

Defense of the poster complaint of (jitter) like to state for the record have witnessed similar behavior 120Mhz SYSCLK even capturing 25Khz signal CCP edge counts. Earlier suggested for low frequency KHZ signals poster to use PIOSC clock source further reducing error % inherit in the GPTM counts. The opposite might well be true of 20Mhz signals where GPTM clock source 80-120Mhz derived from the PLL 480 400Mhz clock source divided down can capture the (stable) edges with less error %.

The faster the monkey bangs on the drum, the more bananas he wants in return.

To.  Dear all.

I'll tell you what I see.

1. A count error occurred.

2. It's a jitter problem.

3. Why Jitter Occurs is two main causes.

   3.1 Waveform distortion caused by signal reflection or impedance mismatch on the line.

        - Check the waveform captured by the Oscilloscope and it looks fine.

          it's  can apply a filter, but it is not a fundamental solution

   3.2 MCU internal PLL was designed incorrectly.

         -M4C, Phase Locked Loops (PLL) design failure of MCU.

          Timer A and Timer B This is the jitter that occurs when synchronizing timers.

4. Ti DataSheet specifies that an 80Mhz system clock is detected at an edge time of 1/4 of a maximum input of 20Mhz

     - The content of the datasheet is a lie. !!

5. Do not ask me the contrary way. 

  I want to hear the objective truth.

  - Do not hide the truth. -

If not, please provide evidence.

thanks.

You are one interesting character.

Suddenly, your one oscilloscope capture is more reliable than years of engineering design! Well, congratulations!!! No one else has ever performed such test!!!! You just found it, while so many blind engineers got involved with the project and development of applications using these micro controllers for all those years... Call the Nobel Prize organizers, they probably have something waiting for you.

Jame shin said:

an 80Mhz system clock is detected at an edge time of 1/4 of a maximum input of 20Mhz

Again, this (grammatically inaccurate) text says DETECTED. There is no lie on this information.

Jame shin said:

If not, please provide evidence.

Why does anyone here need to provide you evidence? It is a fact, the TM4C MCU is 100% able to detect a signal that lasts for at least the duration of 4 clock cycles. If you are ever able to produce a 50ns square signal, send it to a TM4C123 MCU running @80Mhz, and prove that it did not get detected, then come back with your evidence.

As you may suspect, my voluntary contributions to this thread have come to an end.

Bruno

Jame shin said:

I'll tell you what I see.

1. A count error occurred.

No, you've seen a jitter. There is, of yet, no evidence of error. There will be error in any measurement but you've yet to provide evidence of the magnitude.

Jame shin said:

3. Why Jitter Occurs is two main causes.

   3.1 Waveform distortion caused by signal reflection or impedance mismatch on the line.

That does could cause jitter. Easy enough to verify the edge sharpness. I don't think we've seen that.

Jame shin said:

    it's  can apply a filter, but it is not a fundamental solution

If by filter you mean something like a low pass filter then that's pretty much the opposite of a solution. You could add a Schmidt trigger buffer to sharpen the edge but I think that would still leave you with jitter. If this is the cause then you really need to clean up the transmission and impedance matching.

Jame shin said:

   3.2 MCU internal PLL was designed incorrectly.

         -M4C, Phase Locked Loops (PLL) design failure of MCU.

No.

Now all PLLs have jitter (it's how they work) and I do agree its jitter is not fully characterized but it's not designed incorrectly.

3.3 Input waveform has jitter.

You've not shared your signal source or any measurements of its jitter but any signal source will have jitter.

Jame shin said:

4. Ti DataSheet specifies that an 80Mhz system clock is detected at an edge time of 1/4 of a maximum input of 20Mhz

     - The content of the datasheet is a lie. !!

There is absolutely no evidence presented of this. And your measurements wouldn't be sensitive to whether it was 1/4 or 1/2 of a system clock.

And none of this matters in the slightest since your stated goal of measuring 20MHz period on a cycle by cycle basis simply cannot be met.

I strongly suspect that you actually want to measure something different (frequency maybe?) but have stuck to this particular method has being the only acceptable one for some unknown reason.

Jame shin said:

  I want to hear the objective truth.

  - Do not hide the truth. -

No one is hiding the truth. I'm not sure you're listening though. Bruno and cb1 have been quite helpful, Bruno in particular has been  giving you a hand each step of your path.

Robert

cb1_mobile said:

"Does "biting the hand" attached to an (already) broken wrist - yield greater (even some) sympathy?"

The resulting rabies shots surely does.

Robert

I'm unsure if "rabies vaccine" has reached Portugal.    (i.e. Bruno must be "especially" careful...)

(even our combined, "tri-country" response, has failed to satisfy our, "NEED the edge time" & (added), "20MHz or bust" evidence seeking poster...)

Jame shin said:

2. It's a jitter problem.

3.2 MCU internal PLL was designed incorrectly.

-M4C, Phase Locked Loops (PLL) design failure of MCU.

Please review Section 5.2.5.5 of the Datasheet which specifies the PLL Frequency Configurations:

"If the main oscillator provides the clock reference to the main PLL, the translation provided by hardware and used to program the PLL is available for software in the PLL Frequency n (PLLFREQn) registers (see page 274). The internal translation provides a translation within ± 1% of the targeted PLL VCO frequency. Table 24-14 on page 1431 shows the actual PLL frequency and error for a given crystal choice."

The internal translation provides a translation within ± 1% of the targeted PLL VCO frequency.

Perhaps this documented information is related to this 'jitter' you are concerned with? Of course, if you think that the 1% translation is poor design, that is your opinion and you are free to do so, but for a Cortex M4 MCU that is hardly a critical design flaw. We unfortunately aren't going to have 0.01% accuracy for a 400MHz PLL on a chip that costs $6.

Jame shin said:

4. Ti DataSheet specifies that an 80Mhz system clock is detected at an edge time of 1/4 of a maximum input of 20Mhz

- The content of the datasheet is a lie. !!

On this point, the datasheet is not 'a lie'. It is 100% accurate. You are not reading it correctly.

You posted it before, but I'll repost the passage in question:

"For rising-edge detection, the input signal must be High for at least two system clock periods following the rising edge. Similarly, for falling-edge detection, the input signal must be Low for at least two system clock periods following the falling edge. Based on this criteria, the maximum input frequency for edge detection is 1/4 of the system frequency."

This clearly states Detection not Measurement. There is a very stark difference between the two. Bruno and cb1 have both tried to express this to you...

What this means is that at 80MHz, you would be able to see the edge changes of a 20MHz signal, but not a 25MHz signal reliably. That doesn't mean you can measure the exact frequency of it. You just know it is there. You won't know instantly on the spot if it's 18MHz or 20MHz but you'll know an edge change occurred. But at 30MHz, you might not even notice the edge change before it toggles back again.

As cb1 suggested, to measure frequency of such a signal, it may be possible to do over time with many samples and then post-sample calculations/algorithms to pick out a frequency. Certainly not even close to an immediate cycle by cycle, instantaneous measurement. That sort of instant measurement is entirely out of the realm of a single measly Cortex M4 to provide. Hence why our lab oscilloscopes are in the $1000's of dollars and not $10's of dollars to deliver 'instant measurement'.

Only appropriate (yet banned) response is (of course) *** *** LIKE *** ***.

Humble outsiders have invested (much) blood, sweat, tears (in the assistance of vendor staff) - yet are (themselves) deprived of their "LIKE."    (So hard to justify - and SO UNWANTED/MISCAST!)

Ralph,

As cb says this needs a like. I do, however, think you are wrong about one thing.

Ralph Jacobi said:

"If the main oscillator provides the clock reference to the main PLL, the translation provided by hardware and used to program the PLL is available for software in the PLL Frequency n (PLLFREQn) registers (see page 274). The internal translation provides a translation within ± 1% of the targeted PLL VCO frequency. Table 24-14 on page 1431 shows the actual PLL frequency and error for a given crystal choice."

The internal translation provides a translation within ± 1% of the targeted PLL VCO frequency.

Perhaps this documented information is related to this 'jitter' you are concerned with?

This is not jitter. The table referred to does not show the error column as the text states. However, the  '123 documentation does appear to have a more complete table in this regard.  It's the equivalent table 20-14 and does show the error term.  It's consistent with my interpretation that this is referring to the error that comes from non integer relationships between the PLL and the crystal frequency. As such it is a fixed error, and could be calibrated for unlike jitter.

Jitter is a potentially important PLL characteristic but it's different from this translation error (that's rather badly named I think and certainly not properly explained) and I haven't been able to find figures for either the instantaneous jitter or the longer term jitter average (say over 50 cycles of the PLL frequency).

Robert

Maybe I have a different version of the manual?

Is it not "poetic" that "translation" (itself) requires translation?       (don't believe staff nor I have (ever) seen "translation" used in such "tech" manner - it is (likely) a rushed (& non-explanation) - highly notable as such!)

Hello. Bruno

Rather you are an interesting character. !!

You are still talking sarcastically.

Your personality seems to be in a impatient

The Ti engineer I know speaks honestly in a humble posture

Who is more knowledgeable than the interrogator?

Is not that you !!

The definition of E2E seems to be faded.

thanks

Jame shin said:

The definition of E2E seems to be faded.

Really - after "87" back-forth posts - how can that (by any stretch of imagination) "seem faded?"   

Have not three "outsiders" - and the vendor rep - made honest & sustained efforts to guide & assist?    Even when - and especially when - you "upped the game" from the 1KHz scope cal. signal to the 20MHz one.    (of still unknown origin.)

Might it be that "requesting poster's" understanding - and "acceptance of suggested methods" - more properly registers (alone) as, "faded?"

Hello cb1.

cb1 :Q > "E2E seem faded?"
A> I made a mistake in expression. Sorry.

cb1 : Q> Have not three "outsiders" - and the vendor rep - made honest & sustained efforts to guide & assist?
A> Everyone said honestly, But somebody told sarcastic

I thought of seeing your post.
I learned how to detect and measure the method of detecting 1 KHz. 0.01% duty
I wanted to detect a 20MHz edge time using a 1Khz detection method.

How can I detect 20Mhz?

thanks.

Jame shin said:

How can I detect 20Mhz?

It is suspected that you meant "MEASURE" - as your MCU is well able to detect such signal!    (especially if you employ the "Dual Timer Simplification" I've described...one for rising - 2nd for falling edges)

If you can "escape" from your past (so limited) desire for "Cycle by Cycle ONLY measures" (far outside the capability of this & similar MCUs) - my most recent postings - along w/those of others - did describe the method to measure over a "multiple cycle interval!"     And this offers the added benefit of "reducing the impact of signal jitter!"

Relaxing a bit - re-reading (several times, slowly) - then deep-thought & planning - should lead to your success.     (More focused thought - not (another) diagram - (I believe) is your best path to success.)

Thanks for the answer.

I will try after reading the post.

Thank you.

Robert Adsett72 said:

Please spend some time and define what you are measuring and how frequently you need a new value (not how you want to measure it).

Spot & Dead on - Bravo, Robert!     (may I offer (another) EXTRA EFFORT *** LIKE ***)

Vendor - most always - "Shies from such (VITAL) guidance!"    Poster's cannot (yet) satisfy their desires - yet (always) express, "No Qualms" in unleashing their (often questionable) "Problem Solving Method!     And - as we've witnessed here - will defend (that flawed method) "to the death!"

That's "poetic" (you note ironic) - likely, "both hold true!"     If posters' cannot solve their issues - by what logic are they sufficiently competent to, "Devise an optimal Problem Solving Method?"

Yet - all too often - such "flawed poster promoted methods" are (almost blindly) accepted - when more properly they should be (at minimum) questioned - on occasion (even) challenged!

And that's just what you've done!     Bravo!      (and WHERE is the LIKE Button? ... ... SO illustrative of a GRAVELY FLAWED (enfeebled) "NON-Solution!")

Hello . cb1 &  Ti engineer

As you have told me " Relax -> again post reading -> thinking -> analyzer  !! "

I looked at the previous post and thought about it.   https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/610275/2257664#2257664

cb1 post A>  Should highest accuracy be your goal it may prove best to capture the "time delta" between "n" such "like-polarity" signal edges - which will reduce the effect of "timing jitter" upon your measurement.
                     (you would then divide that "total duration" by "n" - to determine the signal's period.)

A_Q> for example from an previous post that was a jitter problem.

sysclk 40Mhz Tc 0.025us , input signal 1Khz, Duty 50%, Ts=1000us  t1(H) 500us, t2(L) 500us. when if application requires a duty 0.01%.(0.1us)

        Time Load value = 1000 us / 0.025us = 40000 (0 ~ 39999 (0x9C3F)) setting,  H duration cycle = 500us/0.025us= 20000

        Jitter occurred :  H duration +- 18 cycle ( n ?)

       - total duration / n =   40000 / 18  = 2222.222...  

     I do not know if I want to set this value to the Time Load Value or how to do it

     Please give detailed explanation. ?

Q1>  The input signal was changed and tested.

        The problem 1Kh has changed the PROBE COMP (cailibration) 5V, 1Khz in Oscilloscope to crystal Oscillator.

    Q1-1> Input signal 20Mhz, Duty 50%, Ts=0.05us t1(H) 0.025us, t2(L) 0.025us / Sysclk 80Mhz Tc 0.0125us,Time Load Value 0.05/0.0125 = 4 (3(0x3))
    Q1-2> Input signal 1Mhz, Duty 50%, Ts=1us t1(H) 0.5us, t2(L) 0.5us / Sysclk 40Mhz Tc 0.025us, Time Load Value 1/0.025 = 40 (39(0x27))
    Q1-3> Input signal 500Khz, Duty 50%, Ts=2us t1(H) 1us, t2(L) 1us / Sysclk 40Mhz Tc 0.025us, Time Load Value 2/0.025 = 80 (79(0x4F))
    Q1-4> Input signal 200Khz, Duty 50%, Ts=5us t1(H) 2.5us, t2(L) 2.5us / Sysclk 40Mhz Tc 0.025us, Time Load Value 5/0.025 = 200 (199(0xC7))

•    ISR  process cycle :   (Measure H / L output duration by oscilloscope)

                when Sysclk 80Mhz,  duartion 0.6 us,  cycle : 0.6 / 0.0125 = 48 cycle

                when Sysclk 40Mhz, duartion  0.9 us,  cycle : 0.9 / 0.025  = 36 cycle

      [Test Result ]

      Q1-1,2,3> : "No Good " , (Reason) Can not execute printf statement and ISR processing cycle is not enought

                                                               (because, H duation 4cycle & ISR 48 or 36 cycle)

     Q1-4> : " Good " , (Analysis) execute printf statement but skip sequence counter value. (Reason) Printf statement processing time is 3.5ms.
                                                  - H duation 200 cycle / ISR 36 cycle = 5.5 enought
                                                    [note] The accuracy of the log contents is +- 1cycle 0.5%(1/200=0.005))

Q2>  How do I printf statement it sequentially?

        Under see  "[Figure 3]  200Khz Input , System Clock 40 Mhz,  Log  Message " count value .

Q3> I'm confused 11.3.2.4 Input Edge-Time Mode in Datasheet 

      Note: For rising-edge detection, the input signal must be High for at least two system clock periods
               following the rising edge. Similarly, for falling edge detection, the input signal must be Low
               for at least two system clock periods following the falling edge. Based on this criteria, the
               maximum input frequency for edge detection is 1/4 of the system frequency

      If you look at the above, System Clock 80Mhz, Input 20Mhz Edge Time Why does datasheet explain this possibility?

thanks.

[ Attach related images] 

Ch1 :T0CCP0,   Ch2 :T0CCP1,  Ch3 : ISR process time duration (use GPIO)

[Figure 1]  1Mhz Input , System Clock 40 Mhz, " No Good"

[Figure 2]  500Khz Input , System Clock 40 Mhz, " No Good"

[Figure 3]  200Khz Input , System Clock 40 Mhz,  Log  Message  " Good"

[Figure 4]  200Khz Input , System Clock 80 Mhz, ISR  process duration time  0.6us

[Figure 5]  200Khz Input , System Clock 40 Mhz, ISR  process duration time  0.9us  " Good"

Jame shin said:

Q> for example from an previous post that was a jitter problem... I do not know if I want to set this value to the Time Load Value or how to do it

Your Subject Line (properly) lists "Edge Time" as your chosen, "Problem-Solving" method.    I suggested that you present the signal to be measured to TWO Different, Timer Input pins, one set to "Interrupt upon RISING EDGES - he second to Interrupt upon FALLING EDGES."    Then - within both (separate) Timer Interrupts - you "log that Edge Time" into RAM.  If you encompass "n such interrupts - then subtract the "time delta" (difference) between the "nth RAM value and 1st RAM value" (those values "Saved to RAM by each Edge Timer) and then, "Divide that "time delta" by your chosen "n" (8-16 should work) your result is a "reduced jitter measurement of (both) "Rising and Falling, Edge to Edge, duration."    To be clear - this process is followed upon the SAME, RAM stored data - one specific Edge at a time.   (i.e. you may first calculate the "average time duration between "Rising Edges" - followed by the same for "Falling Edges."    The use of such "averaging" serves to null deviations - raising your measurement's accuracy.

Now you seek to set a "Time Load Value" - may I ask, "Why is that a requirement?"    If you've followed my instruction (repeated just above) your employing TWO Timers - both in edge time mode - is essentially "Fully Automatic!"   Recall that you seek to "Capture multiple Edge Events" from TWO Timers - each one responding to Different Signal Edges.   (of the same input signal - and both "collection of edge-time values" logged together.   Again - this eliminates your "need" for Timer Load Value - as your writing seeks.   Is this (now) clear?

Jame shin said:

Q2>  How do I printf statement it sequentially?

As the "printf" requires reasonably long, "MCU attention" - that presents (added & unwanted) challenge/demand upon the MCU - and w/little benefit!   Your real "Data Logging" must occur via the "Collection of Edge Times written to RAM" - and (only) viewed & recorded, AFTER the "Collection of n signal edges has completed!"    That "printf" may add errors or cause certain edges to be missed - neither acceptable!   Is this clear?

This post has gone "on & on" for so long - few here (surely not I) can recall what's being done w/in both Timers' ISR.    You show (just one) ISR w/in your caps - you do (perhaps now) realize that there must be TWO separate ISRs - each ISR "Logging to RAM" the edge time it has (just) recorded!

To raise accuracy these two ISRs should be - for now - the (only) ISRs allowed to run - during this "Edge Timer Mastery" exercise.    That's just standard "KISS" - which as always provides the best/fastest (often ONLY) path to user success.    (even if "banned here" - especially as "banned here!")

The log you've presented - to me - has minimal value.   Far better - I believe - would be the "Log of Edge Times - collected by EACH Timer!"    And that does not (anywhere) appear!

I leave "unstated" for now the method to calculate Duty Cycle.    This is (almost) intuitive - that exercise left to the "engaged" reader...   (if any...)

cb1_mobile said:

As the "printf" requires reasonably long, "MCU attention" - that presents (added & unwanted) challenge/demand upon the MCU - and w/little benefit!

I have the jitters after seeing such robust ringing in Jame's captures above post. Suspect inductive current (dv/dt & di/dt) may impact GPTM CCP input structure ability to  settle on the intended (stable) edge by the required 4 SYSCLKS clock periods. The EK-TM4C1294-XL launch pad is a superior to TM4C123 as James expects such accuracy less jitter may result GPTM count accuracy via ability to select PIOS 16Mhz clock source for each GPTM module. More expense yet just as robust DK-TM4C1294-XL with LCD screen removes need of UARTprintf() over a virtual port, yet adds the LCD application interrupts into the mix. 

cb1_mobile said:

To raise accuracy these two ISRs should be - for now - the (only) ISRs allowed to run - during this "Edge Timer Mastery" exercise.

Perhaps more is not less when it comes to NVIC interrupt handling which SYBIOS CPU load monitor reveals CCS debug is not so predictable as we might believe, even via INT priority levels being enforced. What of the final applications growth impact upon NVIC & GPTM timers INT source handlers ever drifting outside hard coded CCP (intended) capture window.  

cb1_mobile said:

Then - within both (separate) Timer Interrupts - you "log that Edge Time" into RAM

Your earlier comment (zillion&1 posts ago) seems highly plausible to have GPTM determine frequency only, 1/p=F & F=1/p P=1/F. Allow embedded C code to resolve the duty cycle % in a simple algorithm via 1 INT handler only, suspect even that will be difficult with all that ringing in the edge times. Notice Jame's edge to edge time captures are only testing 50% duty, ring as if taken directly from resistive network tied to MOSFET inductive load.

Jame shin said:

As you have told me " Relax -> again post reading -> thinking -> analyzer  !! "

And you appear to have spent your time on determining how a particular technique would work rather than determining what you are measuring and to what purpose.

You haven't placed any limits on the signal you are measuring.

So the following questions are outstanding

1. What is the ultimate source of your signal?
2. What range of frequencies does it have?
3. What is the range of duty cycles?
4. How frequently do you need to measure the signal (and what properties do you need to measure)?
5. Are there alternative signals available (why are you stuck on measuring high frequency (RF) signals)?
6. What tasks do you need to perform between measurements?
7. When it comes to your tests (where you complain about the jitter). How repeatable is your source signal? And just as importantly how do you know?
   
   1. BTW 18 counts in 40000 is about 450ppm. So what is your crystal accuracy and drift specs?

Robert

Hello cb1.

CB1_Q1>   Your Subject Line (properly) lists "Edge Time" as your chosen, "Problem-Solving" method.

         A1>  I proceeded with the solution you proposed.

                A 1Khz input signal test using two timers and a rising falling event interrupt resulted in 18 count jitter.

               As you say. " Relaxing a bit - re-reading (several times, slowly) - then deep-thought & planning - should lead to your success."

               What I do not understand is "time delta".

              It is calculated by this content. As you say " cb1_post:  divide that "total duration" by "n"

             So I calculated 40000 (total duration) / 18 (n).

             I asked if the intention was correct.

            Maybe,  Is it the following ?

            Formula>   TBR (END:nth RAM value) - TAR (START: 1st RAM value) = H duration cycle ( time Delta) 

   A1.1> H duration cycle( time Delta) / n, rise 1th, fall 2th does n mean 2 ?

            I explained you, but I still do not understand.

           BP101's post tells the number of induced current,voltage derivative, in a deep mathematical differential.

           You seem to be talking a simple thing. Anyway, I do not know how to reduce jitter.

  A1.2> Please let me know again, for example?

CB1_Q2> Now you seek to set a "Time Load Value" - may I ask, "Why is that a requirement?" 

        A2>  I was wondering if I should set the Time Load Value. As you say " cb1_post: divide that "total duration" by "n"
                ex> Time Load Value of 1Khz input signal & 40Mhz Sysclk , 1ms/0.025us = 40000(39999(0x9C3F)
                So I thought this was a change in value.

CB1_Q3> both in edge time mode - is essentially "Fully Automatic!"   Recall that you seek to "Capture multiple Edge Events" from TWO Timers

         A3> I did that.
                Please check the source code to post.

CB1_Q4> this eliminates your "need" for Timer Load Value
         A4> Set the initial Time Load Value to 0x39CF for that limited period.
                What do you mean about "eliminates your "need" for Timer Load Value" ?

CB1_Q5>Is this (now) clear?

          A5> No.
                signal path : 200Khz Crstal OSC --> Schmitt trigger --> T0CCP0(TA) & T0CCP1(TB) of MCU
               Test result(Log message) + - 1 cycle (0.025us) error occurs.
               The error ratio is 1/200 = 0.005 (0.5%).
               One pulse is lost per 200 consecutive cycles.
               So the cumulative error will occur.

My Post > How do I printf statement it sequentially? 

CB1_Q6> neither acceptable!   Is this clear?

          A6> Yes, it is.

                  Simply calculated

               ex>  when input signal 200Khz with 40Mhz Sysclk , TA-ISR( need 36 cycle), TB-ISR (need 44 cycle) ,Two event signal intervals (need 100 cycles)
                       printf processing time approx. 3.5 ms
                       printf () prints after TB-ISR processing.
                       Must be output within the amount cycle of the ISR(TA+TB), 80 cycle x 0.025us = 2us.

                Is there a method to continue printing without losing the printf statement ?

CB1_post>  This post has gone "on & on" for so long 

   Post_A>  Yes, I do not enough understand
                  I do not know what it means, but I guess it's standard "KISS"!!

CB1_tag>  Why does "Edge Timer" require "Load Set?"

  Tag_A>  Count starts at edge input signal event.

                 The count ends at the next edge input signal event.

                 So set the time Load value to be counted.

thanks.

[ attach Source code ]

//includes
#include <stdint.h> // Variable definitions for the C99 standard.
#include <stdio.h> // Input and output facilities for the C99 standard.
#include <stdbool.h> // Boolean definitions for the C99 standard.
#include "inc/tm4c123gh6pge.h" // Definitions for the interrupt and register assignments.
#include "inc/hw_memmap.h" // Memory map definitions of the Tiva C Series device.
#include "inc/hw_types.h" // Definitions of common types and macros.
#include "inc/hw_gpio.h"
#include "driverlib/sysctl.h" // Definitions and macros for System Control API of DriverLib.
#include "driverlib/interrupt.h" // Defines and macros for NVIC Controller API of DriverLib.
#include "driverlib/gpio.h" // Definitions and macros for GPIO API of DriverLib.
#include "driverlib/timer.h" // Defines and macros for Timer API of DriverLib.
#include "driverlib/pin_map.h" //Mapping of peripherals to pins for all parts.
#include "driverlib/uart.h" // Definitions and macros for UART API of DriverLib.
#include "driverlib/adc.h" // Definitions for ADC API of DriverLib.
#include "driverlib/fpu.h" // Prototypes for the FPU manipulation routines.
#include "utils/uartstdio.h" // Prototypes for the UART console functions.
                             // Needs to add "utils/uartstdio.c" through a relative link.
//definitions
#define UART1_BAUDRATE      115200  // UART baudrate in bps

// function prototypes
void init_timer(void);
void duty_cycle(void);
void init_UART(void);

// global variables
uint32_t sys_clock;
uint32_t  start = 0, end = 0, length = 0;
uint32_t int_flag = 0;

int main(void)
{
    // Configure system clock at 40 MHz
   SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

    sys_clock = SysCtlClockGet();
		
    //ISR Processor Cycle 
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
		SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);
		
		// Enable the processor to respond to interrupts.
    IntMasterEnable();
    
			 
		init_UART();
		UARTprintf("\n TCLK = %d\n" , sys_clock);
		
		// GPIO PD[2]-TA, PD[3]-TB output duration  for  ISR  processing time 
		 GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_2 | GPIO_PIN_3  );
		 
    init_timer();
		
    TimerEnable(TIMER0_BASE, TIMER_BOTH);

    while(1){
			GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, ~GPIO_PIN_2);
			
        if (int_flag == 0x1)
        {
            int_flag = 0;
						
				//		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, GPIO_PIN_2);
            UARTprintf("\nDUTY : %d  =  %d (End) - %d (Start) \n", length, end,start);
    		//		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, 0);

        }
    }
}

void init_timer(void)
{
    // Enable and configure Timer0 peripheral.
    SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
		
    // Initialize timer A and B to count up in edge time mode
    TimerConfigure(TIMER0_BASE, (TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_CAP_TIME_UP | TIMER_CFG_B_CAP_TIME_UP));

    // Timer a records pos edge time and Timer b records neg edge time
    TimerControlEvent(TIMER0_BASE, TIMER_A, TIMER_EVENT_POS_EDGE);
    TimerControlEvent(TIMER0_BASE, TIMER_B, TIMER_EVENT_NEG_EDGE);

    //set the value that the timers count 
		// Input signal 20Mhz,  Ts=0.05us  , Sysclk 40Mhz Tc=0.025  , Count = 0.05us/0.025us = 2 (2-1=1 (0x1)	
		// Input signal 1Mhz,    Ts=1us      , Sysclk 40Mhz Tc=0.025  , Count = 1us/0.025us     = 40 (40-1=39 (0x27)		
		// Input signal 500Khz, Ts=2us      , Sysclk 40Mhz Tc=0.025  , Count = 2us/0.025us     = 80 (80-1=79 (0x4F)
		// Input signal 200Khz, Ts=5us      , Sysclk 40Mhz Tc=0.025  , Count = 5us/0.025us     = 200 (200-1=199 (0xC7)
		// Input signal 1Khz,     Ts=1ms     , Sysclk 40Mhz Tc=0.025  , Count = 1ms/0.025us    = 40000 (40000-1=39999 (0x9C3F)
		
    TimerLoadSet(TIMER0_BASE, TIMER_BOTH, 0x4F);
		
    TimerSynchronize(TIMER0_BASE,TIMER_0A_SYNC|TIMER_0B_SYNC );

    //Configure the pin that the timer reads from (PF0)
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
		
		//  TM4C Port-F0 unlocked and commit contol register be set.  PA[1:0], PA[5:2] , PB[3:2] , PC[3:0], PD[7], PF[0]
  	HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
	  HWREG(GPIO_PORTF_BASE + GPIO_O_CR) |= GPIO_PIN_0;
    
		//  GPIO Configuration , T0CCP0 (TA)-PF[0], T0CCP1(TB)-PF[1]
		GPIOPinConfigure(GPIO_PF0_T0CCP0);		
    GPIOPinConfigure(GPIO_PF1_T0CCP1);
    GPIOPinTypeTimer(GPIO_PORTF_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    // Timer Interrupt Clear ( TA , TB)
    TimerIntClear(TIMER0_BASE, TIMER_CAPA_EVENT|TIMER_CAPB_EVENT);
		
    // Enable the indicated timer interrupt source.
    TimerIntEnable(TIMER0_BASE, TIMER_CAPA_EVENT|TIMER_CAPB_EVENT);
		
    // The specified interrupt is enabled in the interrupt controller.
    IntEnable(INT_TIMER0A);
    IntEnable(INT_TIMER0B);

}

// TIMERA , rise edge , Interrupt ISR
 void Timer0AIntHandler(void)
{
		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, GPIO_PIN_2);
		
    TimerIntClear(TIMER0_BASE, TIMER_CAPA_EVENT);
    start = TimerValueGet(TIMER0_BASE, TIMER_A);
		
	  GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, 0);		
}

// TIMERB , fall edge , Interrupt ISR
 void Timer0BIntHandler(void)
{
		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_3, GPIO_PIN_3);
		
    TimerIntClear(TIMER0_BASE, TIMER_CAPB_EVENT);
    end = TimerValueGet(TIMER0_BASE, TIMER_B);
    length = end - start;
    int_flag = 1;
		
	  GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_3, 0);
}


void init_UART(void)
{
    // Enable and configure UART0 for debugging printouts.
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, (GPIO_PIN_0 | GPIO_PIN_1));
    UARTStdioConfig(0, UART1_BAUDRATE, sys_clock);
}

Hello Robert.

Thank you for your reply to the post.
It seems like I'm going to take a survey out of my question.

Robert_Q1> What is the ultimate source of your signal?
             A1> This is to detect and correct the error of high speed signal output from linear encoder.

Robert_Q2> What range of frequencies does it have?
             A2> Depending on the transmission speed, (Min) 1Mhz ~ (Max) 20Mhz.

Robert_Q3> What is the range of duty cycles?
             A3> A1 The answer is the same.
                    Duty ratio 0.01% ~ 100% (The smallest unit bit to the maximum bit of the transmission data)

Robert_Q4> How frequently do you need to measure the signal (and what properties do you need to measure)?
             A4> I do not know why you ask this question.
                    Depending on the application requirements, it will be two weeks long and one day short.  (Same as A1 answer)

Robert_Q5> Are there alternative signals available (why are you stuck on measuring high frequency (RF) signals)?
             A5> A1 The answer is the same.
                    What should I think about it when I say that it is possible in the Ti Datasheet of chapter 11.3.2.4 ? (truth & lie)
                    You stick to the questionnaire !! The question is not appropriate.
                    So 20Mhz is not going to be?

Robert_Q6> What tasks do you need to perform between measurements?
             A6> Like A1 answer
                    The error value is sent to the control device through the serial interface

Robert_Q7-1> When it comes to your tests (where you complain about the jitter).
             A7-1> It seemed that I continued to reply to the previous poster.

Robert_Q7-2> How repeatable is your source signal?
             A7-2> A1 & A4 The answer is the same.

Robert_Q7-3> And just as importantly how do you know?
             A7-3> Did not see the previous post,
                       Please read the post again slowly regarding 1Khz signal jitter.
                       You know how to tell JITTER to complain about expression !!
                      1 kHz signal uses calibration signal in oscilloscope
                      200Khz, 500Khz, 1Mhz, 20Mhz signals use crystal oscillator

Robert_Q8> BTW 18 counts in 40000 is about 450ppm. So what is your crystal accuracy and drift specs?
            A8> 1khz is requesting Frequency stability from Tektronix company
                    200Khz, 500Khz, 1Mhz, 20Mhz Crystal Oscillator Frequency stability : +- 50ppm
                    What does BTW mean?

thanks.

PLEASE, PLEASE, PLEASE!!!!

Can someone at TI LOCK this thread????? As in "prevent it from new posts"?

This thread is now USELESS. Including original post, this is now message number 100!!!! The title is "TM4C123GH6PGE: I need the edge_time example file.", and there are all sorts of loose discussions going back and forth without any logic.

Folks Robert, cb1, Ralph, BP101, Jame yourself, could you please NOT WRITE HERE anymore?????

Jame, we can still help you. Just open ONE THREAD with ONE SUBJECT, with a clear and specific question. WE ARE NOT DENYING HELP.

MIND THE FUTURE READERS: people come here and search for previously answered issues - put 2 and 2 together, and these current posts under this title are - again - USELESS!

Jame, your descriptions change along time, and the first application is clearly different than what you are trying to do now. For the hundredth time, open a separate thread, give it a proper title, ask a clear question in it!

It is impossible to continuously detect, measure, analyze and output information related to a 20MHz signal using a TM4C129. Period. But THIS THREAD is not the place to discuss it, for it will be a WASTE OF VALUABLE RESOURCES.

PLEASE! 100 is enough!

Bruno