TM4C123GE6PM: Reading PWM pulse width

May I note yours as an "excellently constructed & presented post?"       Very well done.

Now that said - immediately noted:

void IntDefaultHandler(void)
{
uint32_t status = 0;
status = GPIOIntStatus(GPIO_PORTF_BASE, true);

// Clear interrupt flag
GPIOIntClear(GPIO_PORTF_BASE,status);

// Check which pin triggered the interrupt
if((status & GPIO_INT_PIN_0) == GPIO_INT_PIN_0)
{
InputPF0();
}

and continues...

Had you noted that you've chosen the "Default Name" for each/every "to be implemented" Interrupt Service Routine - listed (repeatedly) w/in your "Start-Up file?"       Can that be good?     I am "beyond surprised" that you report this "SO INVITING" (every interrupt source under the sun!) ISR to function.

Might your "inaccuracy result" from a, "Timer Over-flow?"    Reducing the timer's range from 32 bits to 16 - demands that you properly, "Clear and/or Reset the Timer - prior to each/every "Timer Enable" to prevent such unwanted overflow.      Suggest that you look there (Timer Overflow, first) and kindly report...

I must plead (very) temporary insanity for suggesting (earlier) that your move from 32 bit timer to 16 bit timer - caused an overflow.     If your System Clock (which i now note) is 20MHz - your 16 bit timer should enable up to 3mS of time measure - prior to overflow.

That said - directly from the "Peripheral Driver Library User Guide" (SO helpful) arrives:

"When configured for a pair of half-width timers, each timer is separately configured."      And alas - you configured "together" - not separately!   (i.e. A & B appear w/in the SAME TimerConfigure()!)

TimerConfigure(TIMER1_BASE, (TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PERIODIC_UP | TIMER_CFG_B_PERIODIC_UP);    // your existing config - suspect you need TWO such configs!    "A" & "B"

That 2nd - 16 bit config -  (highlighted delightfully, above) may have to "stand on its own"    (I do not make these rules!)      Your test is "Quick & Easy" - thus (my kind) of test...

This data gleaning (may) - resolve your issue!       

ARM  MCUs are noted for "multiple timers" - your desire to "conserve resources" - at the cost of your programming mission - of course - cannot be supported!  

(note:  several "bouts" of temporary (disability) plagued this posting.   Order may have (just now) 14:07 CST - been restored...)

Thank you - yours is a complete (and quick) response - much appreciated.

Well - that's troubling - the data I supplied came directly from the PDL - usually it is "Spot On."

May I confirm that your MCU's System Clock remains @ 20MHz? (via your earlier "divide PLL (200MHz) by 10)

You report two different results - may I ask that you repeat your tests - (say 5 times - back to back) - and see if each result is consistent? Also - how accurate & repeatable is your signal source? Firm/I ALWAYS suggest that "in such troubleshooting" (forego your remote RC means) and drive the Timer Input directly from the MCU's (spare) GPIO - which you can set - and vary - with precision.

The difference between your readings is 301. At 20MHz that's a difference of 15µS - that very well may result from your source! I calculate your 3275 Timer Counts as a pulse duration of 163.75µS - do you agree? As you note - that's quite FAR - from the desired 500µS! If things are "in order" we'd expect 10,000 Timer Counts to accumulate w/in your Timer - when a 500µS pulse arrives!

[edit]   I composed this post prior to your (latest) 1000µS info arriving.     I am now confused (more confused) - WHAT really is the Source Signal which you feed to the measuring Timer?    Is it - as I've suggested - coming directly from the MCU?

Firm/I are very strong believers in KISS.    PF0 is a (potentially) distressed pin (it is an NMI pin) - even though you've attempted to "tame it" - may we "Remove it" from this mix?    PF1 is fine - it is just PF0 which I'd REALLY prefer to avoid - ok?

We appear NOT to be well communicating - might you respond:

• is your System Clock (still) as listed - 20MHz?
• have you employed,  "TimerClockSourceSet()?"    It is not shown anywhere in your code listings.    Is it your belief that your Timers are being clocked - via the System Clock - at 20MHz?
• how have you measured your PWM signal - from PF1 - to be 1KHz?    (with a scope - if not - how?)
• sending such a continuous PWM signal to PFx - to be measured - proves NOT ideal.    I'd much prefer to see you generate a single, timed pulse.   (just one - easily generated by Timer in One-Shot.)   Might you comply.    (the continuous arrival of the PWM signal - especially at this early stage - is NOT helpful - in fact VIOLATES KISS - and adds time/effort to our task.
• insure that "nothing else" is connected to your NEW PFx input - which attempts to measure the width of your NEW, ideally One-Shot pulse.   (NOT a continuous PWM signal - at this time)

Firm/I have (some) experience (record of success) kindly comply as best you are able.    Instructions are (I think) clear & detailed - my effort is unduly increased if bypassed.

here is a demo of the approach I wrote earlier, on an ATtiny @ 8Mhz, 8:1 prescaler:

the ISR is quite simple:

//PCINT isr
//count cycles on both edges
ISR(PCINT0_vect) {
	static uint8_t sPORT=0;					//prior state of the port
	uint8_t tPORT;							//current state of the port
	uint8_t dPORT;							//1->pin changed state
	uint32_t tmp;							//time stamp
	static uint32_t ticks1[4];				//rising edge timestamps

	tmp = systicks();						//timestamp the edge
	tPORT = PWMCH_PORT;						//read the port
	dPORT = tPORT ^ sPORT;					//1->pin changed state

	//test for pin change on ch 0
	if (dPORT & PWMCH0) {					//ch0 has changed state
		if (tPORT & PWMCH0) {				//rising edge on PWMCH0
			pr[0]=tmp - ticks1[0];			//period = distance between two rising edges
			ticks1[0]=tmp;					//update rising edge time
		} else {							//falling edge on PWMCH0
			dc[0]=tmp - ticks1[0];			//duty cycle = distance between rising and falling edges
		}
	}

	//test for pin change on ch 1
	if (dPORT & PWMCH1) {					//ch1 has changed state
		if (tPORT & PWMCH1) {				//rising edge on PWMCH1
			pr[1]=tmp - ticks1[1];			//period = distance between two rising edges
			ticks1[1]=tmp;					//update rising edge time
		} else {							//falling edge on PWMCH1
			dc[1]=tmp - ticks1[1];			//duty cycle = distance between rising and falling edges
		}
	}

	//repeat for other channels

	sPORT = tPORT;							//save the state
}

I'm counting two pwm inputs:

ch0: 1Khz, 10% duty cycle -> pr[0]=1000us, dc[0]=100us;

ch1: 250Hz, 10% duty cycle -> pr[1]=4000us, dc[1]=400.

here is a screen shot of the simulation:

Our period counts are spot on: 1000 and 4000, our dc counts are 101 and 401, off by 1 count.

Now, your chip will be different, and your code will be different, but the basic concept behind it will be identical. if anything, the isr will be quite a bit simpler on your chip.

if you take much more than that to do it, there is something seriously wrong.

Danny F said:

if you take much more than that to do it, there is something seriously wrong.

Will not be the "first time" then - that this reporter falls into the, "seriously wrong" category...     

In general - I applaud the cleverness demonstrated w/in your code - yet believe (some) more ... IS required!      (unknown is whether "some" rises to poster's definition of  "much.")

"Some" or (even dreaded) "More" follows:

• unstated is the "Calling Mechanism" for the ISR!     May we assume that GPIO's are driven by external,  (PWM signals) and that each/every GPIO - so driven - has been programmed to "Interrupt upon such external signal's, "Edge?"     (that should have been included - should it not?)
• variable  "dPORT" likely defaults to the "lowest PWM channel" - yet the ISR reveals,  "No mechanism" to alter "dPORT" - so that (other) channels may be examined.    Is this true?
• it is thus assumed that  (somehow)  "dPORT" is (loaded and "aimed") ... outside of the ISR.    (this so - "other" than the "default  dPORT channel" is selected.    Is this correct?      And - if  so - how do you propose "best" implementing this?
• agree that "w/in the ISR" is NOT the place to calculate the input signals'  Frequency or Duty Cycle - yet the "Coordination & timing" of that (may) demand (some) explanation...    (if clarity is indeed, a goal)

Your effort is appreciated - yet I continue in the belief that  "KISS" -  by far - best serves the requester.     His first task must be to capture & confirm the measure of a single pulse - NOT a "Pulse Bombardment!"

Had you "had more time" - it is certain that more "intuitive or recognizable" variable names - could have been chosen.      (dPORT, tPORT, sPORT, tmp ... Not so much!)

While we're glad that you believe your isssue solved - would not that  "SAME UART printf" have equally impacted your Timers EARLIER - when they were set to "32 bit mode?"      You reported the 32 bit mode to perform properly - using that  "SAME UART printf!"       I believe that to be true.

Note that I did suggest that you, "Reduce the WHOLE" of your program - into far smaller, individual pieces - thus enabling the "EASED DETECTION" of the "ERRANT PART(S)."    That guidance may have achieved (somewhat) more than "try to help."

At any rate - good luck.

In retrospect - your use of the API Timers' function, "Edge Time Mode" appears a superior means to, "Achieve your PWM measure goal - while enabling, "Many more program code pieces to execute w/out time-delay penalty..."

Our posts just crossed - do note my most recent one - (now 2 up!)     Once again - KISS came to one's rescue - Good for you!