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.

TM4C1290NCPDT: performance of GPIO

Part Number: TM4C1290NCPDT

Team, I am trying to figure out how short of a GPIO pulse can be detected by the schmitt triggered GPIO inputs. We have a customer that would like to detect a 30ns pulse reliably as an event trigger in their system. Assuming the device is in active mode polling, can we reliably commit? I cannot find any technical specification in the datasheet to reliably say one way or another.

20 Replies

  • Hi,
    Is there a reason why an interrupt method by detecting a change of the edge of the input not considered in the application? 30ns is about 3.6 cycles of CPU clock. Normally in design, it should be detectable for a pulse that is larger than 2 cycles. So as far as detecting a 3 cycle pulse I think it is doable. However, I don't think you can reliably poll an input with a 3 cycle width. It takes some cycles to read the GPIO register. I think the back to back read of a register will be greater than 3 cycles.




  • In reply to Charles Tsai:

    Greetings Charles,

    Recently - while working w/"Bruno" on his PWM measurement via MCU's Timer - we learned that an input signal (persisting high) for, "TWO MCU System Clock periods" is "guaranteed to be detected by that Timer!"      Note: Timer configured to, Input Edge (or) Input Time Count Mode.

    Via this method - no such "Polling" of an input is required!       We note that you (properly) identified the weaknesses of such "polling" approach.

    Might this be yet another demonstration where the "poster suggested" approach is not (quite) optimal?        This Timer approach appears superior - especially as it is essentially "AUTOMATIC" (i.e. the occurrence of the input pulse is "latched" - enabling a far less demanding "read".)

  • Hi there,
    As mentioned by cb1, the misleading word on your post is "polling".
    TM4C's - and the whole MCU planet - have interrupts for a reason! All your customer needs to do is configure the interrupt for a GPIO.
    Now, some considerations:
    - Different that timer edge capture, GPIO interrupt does not need two cycles to reliably process - if the GPIO input signal had crossed the boundary during one cycle, that will surely set a GPIO Edge interrupt - hence, >9ns is the number here for a TM4C @120MHz - 30ns detection is a piece of cake.
    - The ability of your signal actually being sent above trigger voltage for a given time is not related to the digital inner side of the MCU, but rather to the analog capacity of whatever is driving it - the capacitance of the GPIO's are published, and the time a signal takes can be calculated/measured for a particular circuit - of course, taking in consideration driver's health and trace and associated "thieves".
    - Not included in the question was HOW FAST must the RESPONSE be. That is a different story, and it depends on what else is running on the program, what are the ISR sizes, and what are the interrupt priorities - but the if 30ns is the desired response time, the answer is that no TM4C can guarantee it even if not doing anything else.
    how short of a GPIO pulse can be detected by the schmitt triggered GPIO inputs

    Bruno my friend - might you have not taken the poster's saving, (hedge, above) fully/properly into account?        As you know - the Schmitt extracts (some) price for its advantage!

    If vendor's Charles states, "2 cycles" - then I'd vote w/him!

    Have you (carefully) constructed - the (very) briefest of signals - and routed it to the MCU - and "confirmed" your "single cycle OR LESS" theory?       (high stack of chips placed upon, "NO!")

    Certain professions "dwell more in small detail" than others - might that be (especially) required, here?

    It is noted that, "While the "Search is claimed to be Deep" - it is FAR from Responsive!"

  • In reply to Bruno Saraiva:

    Hi Bruno,
    Thanks for your insights. I think we all agree that polling cannot be done reliably at 3-cycle width. I'd like to share a bit of my experience as a designer before. Normally in design, to avoid metastability we will run an asynchronous signal through two flops. This is the reason I stated that two cycles will be fine. If an input signal width is very close to the clock cycle then it may not detect the edge in all PVT (process corner, voltage, temperature) corner in conjunction with tolerances such as PLL jitter.




  • In reply to cb1_mobile:

    True, the datasheet says nothing about the minimum pulse time for the GPIO to perceive a change... nowhere!

    I dug my comment from the dark layers of my MSP430 past experience: one cycle there was sure to be captured.

    I guess one can assume, after seeing all considerations here, that one cycle is barely possible, but two are kind-of-certain. The overall comments tell poster that his 30ns won't be a problem, and that polling is not the way to go (as you quickly stated).

    Have I (carefully) reconstructed the signal? No!!!! - I don't even have hardware for such! The fastest thing I have is indeed a 120MHz launchpad. My function generator is 70MHz, and I'm not even sure I could configure it for a single pulse. More money needed into this bench to construct a 10ns spike! Actually, the question made me wonder if I could generate a 1-cycle pulse with a TM4C by using two outputs, offset by 1 cycle somehow (an even timer used to trigger another, maybe?), and then a logic gate?


  • In reply to Charles Tsai:


    Lots of good discussion here. Am I understanding correct that if the MCU detects the signal via timer capture, or GPIO interrupt from active state (not polling) then the signal can be reliably detected, assuming the CPU clock is operating fast enough?

  • In reply to DEEP SEARCH:

    Hi Deep Search,
    Yes, your understanding is correct.




  • In reply to Charles Tsai:

    In the attempt to best comply w/poster's "desire for depth" - we've just confimed the guidance provided by Charles - in which (sometimes) one System Clock cycle proves "detectable" - yet two such cycles (always) proves detectable!           We performed the combined, hardware/software test, below.

    Experimental Method:
    My group employed a Cortex M7 (alas, from another) and a (very) fast FPGA gate (another, other) feeding that gate's output into (two) TM4C123 LPads - via short, direct, shielded cable.     (only one LPad was used at a time - two used to better, "generalize" our findings.)

    Our M7 system clock was set to 200MHz (could be set higher) which yielded (math friendly) 5nS period.      Our "intercepting/blocking" FPGA gate - controlled by the M7 - could then pass a continuous "high level" signal of "integer multiplies of 5nS."      Our TM4C123s - clocked at 80MHz - thus had a 12.5nS period/clock cycle.

    A single M7 clock pulse (high) width (5nS) was NEVER detected by the 4C123 - nor were 10nS pulse (high) widths - but on occasion (3 out of 20 runs) we detected the 15nS pulse (high) width!    That 15nS is just beyond (by 2.5nS) the 12.5nS - single cycle - 4C123 period.

    And - just as Charles reported - when we "extended" the gate's pulse (high) width to 30nS (which exceeds two 4C123 cycles [25nS]) we ALWAYS succeeded in such pulse detection!


    Thus the experience/guidance provided by Charles - at least in this (limited) test methodology - has been confirmed.

    "20 out of 20" could (surely) be improved (repetition wise) - yet appears, "Good for Gov't Work" - and just may qualify as "Deep."        (sorry - could not resist...and (eventually) you did respond)

  • In reply to Bruno Saraiva:

    Good catch on the response time Bruno.

    As a side note, if a fast response time is not needed neither is the fast detect likely needed. A pulse is easily stretched or even latched in HW, unburdening the micro.


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.