TM4C1294KCPDT: GPTM CCP edge trigger polarity

Hi BP101,

BP101 said:

Seemingly a positive going edge should originate from ground to be counted as a valid CCPn positive edge. Otherwise pulses originate 3v3 pass just below logic high (VDD*0.65) shoot back up to VDD trigger an edge event.

Your signal will need to go below VIL to be recognized as logic low. Per datasheet the VIL is 0.35*VDD so you will have some hysteresis to not falsely recognize transitions. If CCP is detecting an edge then it must have seen the input goes below 0.35*VDD and lasting for some duration of time around the rising edge of the sampling clock. 

There is NO programmable hysterisis if that is what you are looking for. 

At the end, your system needs to ensure clean signal inputs to the MCU or you need to add some de-bounce intelligence into your design, either h/w or s/w. 

Hi Charles,

Charles Tsai said:

Your signal will need to go below VIL to be recognized as logic low. Per datasheet the VIL is 0.35*VDD so you will have some hysteresis to not falsely recognize transitions.

The pulses majority never cross VIL, hence the question as to why (with no input signal) PWM riding on +3v3 pull up easily triggers CCPn. The GPTM-A 1/2 wide provides 25khz PWM to +24v external device but the pulses riding on +3v3 are 12.5kHz. Point is the very same GPTM-B 1/2 wide triggers CCP edge events is not effected by 25kHz on GPTM-A, well isolated GPTM it seems.

The +24v device output (open collector) input to CCP with 5k6-20k pull up +3v3, filter values on CCP signal up to 10uf do not stop false triggering <230Hz input signal. The CCP signal 1nf-10nf decoupling at MCU pin makes no difference. Capacitance >3000n added to slower CCP input signal only rolls off >102Hz rising edge with higher frequency still riding on it.  The higher frequency riding the signal is triggering edge events well below Boolean edge logic levels. 

Seemingly VIL crossing has nothing to do with why GPTM0 CCP1 input so easily false triggering from higher frequency riding on slower >102Hz tachometer signal.

The CCP edge events are triggering without an input signal as PWM0 generators go active and the much slower 102Hz input signal gets entirely lost, Why? Will CCP1 configured for OD input work better with open collector input this case? The fear was +24v device has open collector to CCP input and with good reason Schottky diode cathode blocks +24v CCP input if ever ground floats. Has by accident done just that "Even with header locking pins" Schottky diode stops +24v direct attack upon MCU. The Schottky diode only rises CCP input signal at MCU pin 800mv above DGND, don't think it is a factor do you?

At this time have disabled the GPTM edge counter unless some way to stop higher frequency from aborting the much slower edge times.

BTW: Past configuring GPTM clock source for PIOSC was the only way to make EVM report slower <230Hz signal input to CCP edge events.

The CCPn _NEG edge events versus _POS edge events are NOT fully constrained by VIL/VIH respectively. The faster GPTM clock source (SYSCLK 120Mhz) may present a clue why Boolean logic fails with slower edge times, <230Hz. Some how the interval timing period of the edge events reporting frame filters higher frequency PWM riding on our slower tachometer edge events.

My view is It should not require software to correct hardware issues reported in this posting.

Hi Charles,

Charles Tsai said:

Are you saying a PWM generated out of GPTM-A on CCP0 can false trigger on CCP1 input pin?

That would be more plausible but is not the case it seems. Rather PWM0 generators are triggering GPTM0-CCP1 almost appears as triggering internal. 

Charles Tsai said:

You really need to check if your input is immune from noise and if you have clean power supply to both VDD and GND.

Will know for sure after removal of open collector pull up resistor on CCP pin. Bad thing is >20k pull up CCP1 does not work for open collector, impacts the signal quality. Perhaps a WPU on the GPIO will be enough current to drive an open collector output without external pull up to 3v3? As I recall WPU is roughly 20k, Schottky diode on CCP1 should block reverse voltage current from the open collector if occurs above VDD, right? 

Hi Charles,

Charles Tsai said:

I suppose you are using the M0PWM0 module, not the GPTM-A used as a PWM pin, correct? I just can't relate M0PWM0 with GPTM-B T0CCP1

The 12.5kHz is DC inverter PWM which invades CCP1 only when CCP0 is providing 25kHz PWM signal to the external device.

Charles Tsai said:

Who is driving the CCP1? Why do you need the pullup?

Somehow PWM0 12.5kHz pulses enter CCP1 via CCP0 25kHz through the open collector source only when it is plugged in. There seems to be a loop path CCP0/PWM0 into CCP1 that develops only when the device has been plugged in. The external device connector is in the low voltage zone and has 33uf electrolytic +24v pin and later added ferrite bead in series with 24v made no difference. The RF of PWM0 invades CCP0 and both signals (12.5kHz/25kHz) inflections ride on slower (102-230Hz) CCP1 signal. The pulses VIH/VIL are not obvious to scope probe and hysteresis should be in play with trigger POS edge, right? It was configured CCP1 BOTH edges with PIOSC. How did PIOSC clock source to GPTM0 stop phantom triggers CCP1 is more the mystery.

    // 25Khz PWM Duty PL4:TM0CCP0
    MAP_GPIOPinTypeTimer(GPIO_PORTL_AHB_BASE, GPIO_PIN_4);
    MAP_GPIOPadConfigSet(GPIO_PORTL_AHB_BASE, GPIO_PIN_4,
                         GPIO_STRENGTH_8MA_SC, GPIO_PIN_TYPE_STD);
    MAP_GPIOPinConfigure(GPIO_PL4_T0CCP0);

    // Taco input PL5:TM0CCP1
    MAP_GPIOPinTypeTimer(GPIO_PORTL_AHB_BASE, GPIO_PIN_5);
    MAP_GPIOPadConfigSet(GPIO_PORTL_AHB_BASE, GPIO_PIN_5, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);
    MAP_GPIOPinConfigure(GPIO_PL5_T0CCP1);

Hi Charles,

Seemingly a period violation, input edges must  low/high for TWO clock periods, SYSCLK (8.333ns) or 16.6ns . Perhaps why faster pulses PWM0  60mHz PWM clock (16.6ns) easily trigger counts no matter the path they originate from/through. Even PIOSC clock periods were/are to fast 62.5ns, e.g. x2 clock periods (125ns). The fastest expected edge count <220Hz (4.5ms) x2 or 9ms. Hysteresis may be more of a mute point in this issue.

Seemingly it requires a very slow GPTM clock source to filter out higher frequency pulses. Will a slower clock source (LFIOSC) reduce the periods (following) thus filtering out higher frequency pulses?

13.3.3.3 Input Edge-Count Mode

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

Hi Charles,

Charles Tsai said:

If your PWM period is twice the SYSCLK then the GPTM can reliably sample the input provided that you connect the PWM0 to the GPTM CCP0.

It's not directly connected but exists in the same MCU so the higher frequency pulses easily find paths to ride on the lower frequency signal input as edge counts. CCP0 is a separate 1/2 wide for PWM 20-25kHz output controlling fan speed and CCP1 tachometer edge counts. Again PWM0 uses SYSCLK/2 (60mHz) very same clock rate of GPTM even though PWM0 is divided down (12.5kHz) synchronous pulses easily inflict CCP1 edge counts perhaps internally or externally. Somehow need to reduce ability of higher frequency PWM pulses to ever inflict much lower frequency edge counts by reducing CCP1 sensitivity to high frequency PWM pulses. It don't seem like GPTM down count errata but we do use BILR to determine time of interrupt entry and reload edge match counts based on the time elapsed. The topology works well until PWM0 activity picks up, then edge counts start drifting even after synchronizing GPTM-0B with TM3A. 

Lower frequency GPTM clock (PIOSC) does produces less impact from PWM0 inflicting edge counts on CCP1. That is not the end all solution (better, still not stable) and both CCP0/1 1/2 wide timers have dedicated MCU pins so they can not be changed. Only GPTM clocking or decoupling devices can be manipulated to reduce PWM0 module pulses inflicting edge counts CCP1. Both 1/2 wide GPTM must use the same clock source. There is no other high frequency pulse immunity CCP1 other than 2 SYSCLKS are added to qualify PIOSC edge counts via ALT clock source change.

Reading datasheet LFIOS (ALT source) would be another solution to test, wide range 10KHz-33Khz-70Khz. How to make GPTM CCP0 produce 20KHz from even a 33KHz (30.3µs) clock source, 2 load value seems wrong. It seems the load and match values will not produce a PWM duty cycle range need to control fan speed. Besides the LFIOSC drifts by quite a bit MCU lot # as datasheet electrical section suggests a very broad range can be expected, right?

Hi Charles,

Charles Tsai said:

If PIOSC works for you then I think you should stay with this solution as a 33kHz LFOSC can't produce a 20kHz PWM even in the absence of its huge tolerance.

The problem was later found TBILR count reload CCP1 match count during one shot interrupt was limiting RPM bandwidth more than had believed, changes to stabilize counts on EVM system during PWM0 activity.

Charles Tsai said:

I asked you before if you had tried other PWM pins (not PWM0) or use a different GPTM for your edge count instead of CCP1. Did you see any difference?

Past EVM tested GPTM5 with same results and again GPTM0 CCP0/1 are dedicated pins on custom PCB, can't change package pins to different GPTM.

Charles Tsai said:

You keep saying the PWM0 inflicts noise onto the CCP1 when the PWM0 is only 12.5kHz

Scope probes faster 12.5Khz PWM pulses riding in/on slower <220Hz signal input on CCP1. It seems to me the faster pulses may account for more edges (phantoms) in the accumulated edge count used to determine RPM in 1 second intervals. All is good until 1 second interval oneshot timer and edge counts seem to increase due to PWM0 activity. It don't take much more oneshot load time via PIOSC second intervals/interrupts to vary speed measured.

Hard to imagine interrupts account for roaming edges up/down, NVIC nanoseconds wildly varying 1 second intervals into interrupt routine. The only other possible cause phantom counts could be related to TBAR  being subtracted TBILR, becomes unstable accumulated edge countsr. Running a test to confirm might add unknown issues but in my mind PWM0 priority should not meander TBILR count by such large count values. The update count is being obtained indirectly in the oneshot tick handler enabled in but not subtracted explicitly inside the edge counts interrupt handler, though CCP1 is re-enabled. The accumulated edge counts form a phase lock loop and incorrectly meanders frequency only during PWM0 activity. It is noted TBILR count changes as PWM0 goes active on AHB, unknown how or why.

May consider calculating edge times during edge counts interrupt but that idea failed to work any better than 1 second delay interrupt in the past. Rules apply set by the fan taco edges output, decode formula must maintain compatibility so RPM is properly calculated for digital display. Why TBILR count shifts greatly during PMW0 activity perhaps was to quickly assumed an external issue.

/* In down-count mode, the current count of the input events can be obtained by subtracting the GPTMTBR or GPTMTBV from the value made up of the GPTMTBPR and GPTMTBILR register combination. */