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.

EK-TM4C1294XL: GPTM edge counts accelerate GPTM OneShot when PWM0 active.

Guru 55913 points
Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: LM4041-N, INA240, TM4C1294KCPDT, TM4C1294NCPDT

Conditions of issue:

1. GPTM 12 bit in 1/2 wide input edge down count of incoming tachometer signal. Every 210 edge counts @4PPS drives an interrupt and triggers One Shot timer set for 201Hz used for match count variable updates via the interrupt handler reloading the same 201Hz time each cycle. That cycle drifts greatly when ever PMW0 becomes active.

2. The Oneshot handler uses GPTM edge counter register to determine the current count of edge input events by subtracting GPTMTnR from the value of GPTMTnILR register and updates the match count static variable used in the edge count frequency of interrupts. The hander then reloads the Oneshot  @201Hz for the next cycle. This proves a faster method to update RPM digital display than waiting 60 seconds each interval and counting the same number of preset edges to produce edge count interrupts relative to CCP1 input frequency.

3. The Oneshot speed updates are stable and accurate long as the PWM0 peripheral is not using NVIC or GPIO ports. When PWM0 duty cycle accelerates so does the frequency of the Oneshot reload, 201Hz accelerate but CCP1 input remains steady 102Hz or 1671 RPM. How can that occur if the same CCP1 (102Hz edge counts) is maintained and there is virtually no phase jitter in either rising or falling edges >1us when PWM0 is outputting on GPIO pins? Also tested POS edge only event counts which have 0% phase jitter at 102Hz, same false triggering CCP1 occurs.

4. Verified 201hz pulse is produced via GPIO pin placed inside edge count interrupt handler, accelerate and become steady 1us pulses. Very difficult to measure a 201Hz strobe pulse other than by human eye/brain witnessing the frequency of a single strobe pulse incorrectly accelerates as the CCP1 edge count remains static.

5. GPTM edge count and Oneshot timers have been synchronized after both were configured and each have same INT priority level 0x40,  INT51 / INT36 respectively.

Q: Possible GPIO pin MUX value for one of the PWM peripheral GEN pins is internally MUX crossed with CCP1 of GPTM edge counts input?

Q: How else can PWM0 interrupt/ADC0 triggers or GPIO pins so seriously impact CCP1 input of GPTM-0 or Oneshot GPTM-3?

A: 5.10.2018; EXTERNALLY

// Taco input PL5:TM0CCP1
MAP_GPIOPinConfigure(GPIO_PL5_T0CCP1);
MAP_GPIOPinTypeTimer(GPIO_PORTL_AHB_BASE, GPIO_PIN_5);
 //Enable PD1 pin 2  for COMP1 Co1 (Digital) GPIO Output
MAP_GPIOPinConfigure(GPIO_PD1_C1O);
GPIOPinTypeComparatorOutput(GPIO_PORTD_AHB_BASE, GPIO_PIN_1); 

 

  • Otherwise GPIO PD1 is alternate selection pin of GPTM0 CCP1 being used for Analog Comparator C01 output from C1- analog input.  

    PD1 is providing analog comparator feed back for PWM0 generators via INA240 current monitor output and typically signal amplitude does not rise above ANIx input relative 1.225v VREF1/2 via LM4041-N. PD1 seems to be an internal GPIO analog I/O pad cross triggering edge counts into digital CCP1 PL5(3). These cross triggering GPTM0 CCP1 edge  counts are not directly visible on PD1 but seem to cause falling edge jitter CCp1 input when PWM0 is outputting data from PWMENABLE  REG3. Likewise GPIO pin H3 is monitoring this dilemma shown in the edge count interrupt handler code below. Oddly PD1 is not configured and timing issue still occurs, perhaps from C1- analog input even being configured?

    Suspect Analog Comparator C1- input alternate PD1 somehow is triggering edge counts internally, not from CCP1 but GPIO PL5 directly....

    
    

  • Speeding up the edge count process to 201Hz maximum taco speed only made the speed count drift lower. Trying to subtract GPTM0 edge counts derived match value in GPTM3 interrupt is futile to offset edge count drift from unexpected triggered edges bleeding into CCP1.

    
    

  • Hi BP101,

     

    BP101 said:

    Q: Possible GPIO pin MUX value for one of the PWM peripheral GEN pins is internally MUX crossed with CCP1 of GPTM edge counts input?

      Not that I can see from the datasheet. The M0PWMx from the PWM module are brought to the PF, PG and PK ports which will be independent of PL5. 

    BP101 said:
    Q: How else can PWM0 interrupt/ADC0 triggers or GPIO pins so seriously impact CCP1 input of GPTM-0 or Oneshot GPTM-3 ?

     Is it possible that one type of interrupt (i.e. PWM interrupt) happens too frequently before the CPU can serve the GPTM interrupt. Otherwise, I can't connect the relationship between PWM interrupt and the GPTM edge count on CCP1. 

      

  • Hi Charles,

    Charles Tsai said:
     Is it possible that one type of interrupt (i.e. PWM interrupt) happens too frequently before the CPU can serve the GPTM interrupt.

    Both CCP1 and GPTM3 are synchronous time bases and only TM3 uses timeout INT for tick handler, PWM0 zero INT occurs every 80us at 12.5Khz.  TM3 is reloaded for 201Hz in FanSpeedTickHandler(void) every time it expires.  Long as TM3 was set for 1 second all edge count drift went away after adding 0.001uf capacitor on X11 header pin. No other measures were required to get correct speed readings when PMW0 was active. 

    Disabling the analog comparator input/output drive into PL5 PD1 made no difference. The 12.5Khz PWM0 pulses riding on 24v DC are perhaps effecting the fan logic more than expected. The CCP1 edge count seems to fall off with 220uf capacitor placed on 24vdc fan motor plug, parallel to existing 33uf electrolytic. Prior to posting in forum tested 0.047uf ceramic to GND on CC1 input parallel to existing 0.001uf near MCU input pin. All it did was further roll off the rising edge of CCP1  which is already leaning quite far over removed PWM0 pulse detents riding top of signal.

    Adding Schottky diode in series to taco signal CCP1 made phantom edge counts further drop. Yet counts randomly change around the lower (fake) speed, well above 102Hz. The diode rises CCP1 signal off ground by 50mv and with two 50mOhm ferrites also in series with 3R9k, still not stopping would be phantom edge count pulses.

    The taco signal into CCP1 is active high and 12.5Khz PMW0 pulse detents riding the signal top never drop below Boolean logic level low, even @102Hz taco speed. That's why it seems the issue is edge counter related more than fan circuit, since GPIO marker pulse rate returns to strobe @201Hz after PWM0 shuts down. How can CCP1 be triggering from 12.5Khz detents riding the top of signal? What can be done to stop PMW0 detents from falsing CCP1 other than add Schottky diode tied to 3v3 at CCP1?

     

  • Hi Charles,

    Going from the premise the application is not causing count drift from NVIC processing GPTM3 interrupts; CCP1 input is perhaps a bit sensitive to the fans open collector output pulled up via 4R8K to 3v3 rail. The person testing for such intrusion would be unaware of how external signals might effect the CCP1 input drive structure. They as we are also unaware the fact CCP1 input triggers from un restrained input logic structures triggering on inverted runt pulses above the Boolean Low logic level, outline in electric characteristics. False triggering becomes apparent reviewing rising edge of CCP1 signal slope receive random inverted runt pulse infliction especially in rising edge triggering CCP1 input when it should not. That seems to occur from inverted runt pulses that never cross into a Boolean low level area, unrestrained Schmidt trigger behavior occurs and edge counts become unreliable via CCPn input triggers.  

    1. Could CCP1 configured OD (In/Out) per GPIO table 10-4 produce better logic filtering of input signals than typical input configuration shown?

    Perhaps by filtering the fans signal differently than CCP1 shown in table 10-4 the Boolean level for high will be less sensitive to PWM0 output on the GPIO pad?

    2. Low value pull up R at Fans open collector signal pin may introduce undesired PWM0 signals riding on DC rail into CCP1.

    Oddly issue may fall under the same PDF given another recent post (failed GPIO OD outputs) controlling PWM0 gate drivers.

    3. High value pull up R on OD or simple GPIO input may help to arrest PWM0 signals riding on DC supply rail from affecting GPIO pad from the outside in?

    That would assume CCP1 configured for OD and large value PullUp R being optimized to reduce the effect of PWM0 signals false triggering CCP1 input drive structures. That is sort of an oxymoron for CCP0 signal as GPTM0-A 1/2 wide produces 25Khz PWM output to the same fan on another wire.

  • You give up that easily?

    Quiet as the edge count CCP1 input pin has been made it seems the GPTMTnR or GPTMTnV subtracted from GPTMTnILR is causing the count to escalate from internal PWM0 noise. GPTM#13 seems to be occurring even with 120Mhz SYSCLK time source. The only way to overcome #13 when PWM0 is outputting has been to wait an entire second between subtraction of GPTM0-B TnR/TnB from TnILR values update the interrupt count value of CCP1.

    Making the CCP1 input float via WPU with Schottky diode placed in series of taco signal, 100R parallel with diode gives CCP1 better isolation. Timed loop then produces somewhat lower counts and it can be noticed GPTM3 (Oneshot) when enabled inside the tick handler (below) proves the TnR/TnV values are not keeping consistent counts in the timed frequency update. 

    void
    FanSpeedTickHandler(void)
    {
    	uint32_t ui32TBVEdgeCount;
    	uint32_t ui32TBILREdgeCount;
    
    	/* Clear the periodic 102.7Hz TIMEOUT interrupt.*/
        MAP_TimerIntClear(TIMER3_BASE, TIMER_TIMA_TIMEOUT);
    
    	/* In down-count mode, the current count of the input
    	 * events can be obtained by subtracting the GPTMTnR
    	 * or GPTMTnV from the value made up of the GPTMTnPR(prescale)
    	 * and GPTMTnILR register combination. */
    
        /* Get GPTMTBV free running count value. */
    	ui32TBVEdgeCount = HWREG(TIMER0_BASE + TIMER_O_TBR);
    	/* Get GPTMTBILR current matching edge counts */
    	ui32TBILREdgeCount = HWREG(TIMER0_BASE + TIMER_O_TBILR);
    	/* Determine the total number of counted edges up to ISR */
    	ui32EdgeCount =  ui32TBILREdgeCount - ui32TBVEdgeCount ;
    
        	/* Disable GPTM-B0 to update TnMATCHR count register */
    	//HWREG(TIMER0_BASE + TIMER_O_CTL) &= ~(TIMER_CTL_TBEN);
    
    	/* Reload GPTM0B TnMATCHR with counted edges up to this ISR */
    	//MAP_TimerMatchSet(TIMER0_BASE, TIMER_B, ui32EdgeCount);
    	//HWREG(TIMER0_BASE + TIMER_O_TBMATCHR) = ui32EdgeCount;
    
    	/* Re-enable GPTM-B0 edge counts. */
    	//HWREG(TIMER0_BASE + TIMER_O_CTL) |= TIMER_CTL_TBEN;
    
    	/* Reload GPTM-3 Oneshot for 120.7Hz interval. */
    	HWREG(TIMER3_BASE + TIMER_O_TAILR) = 0xBC0CA0;  
    
        /* Trigger GPTM3 oneshot */
        HWREG(TIMER3_BASE + TIMER_O_CTL) |= TIMER_CTL_TAEN;
    

  • Hi BP101,
    GPTM#13 is when you use an alternate clock source. I don't think it applies to you unless you are using the alternate clock source like PIOSC.
  • Hi Charles,

    The funny thing is making GPTM3 use alternate PIOSC for writes of 1 second intervals resolved the issue in the past. Using the SYSCLK source for GPTM3 made GPTM0 CCP1 counts very high. After making GPTM3 use alternate source PIOSC the PWM0 activity no longer caused random high edge counts in GPTM-0B

    Notice in the code above HWREG can enable direct writes of the same Match value directly into GPTM-0B. When enabled edge count match values remain inconsistent. Seemingly GPTM3 one shot write value is lost per GPTM#16,  when SYSCLK or PIOS are made the clock source.

    Making GPTM3 a periodic timer enabled from GPTM-0B interrupt handler produces same behavior in GPTM-0B edge counts continue following PWM0 speed and not GPTM3 one shot time value.  

    What would cause GPTM3 oneshot  to not write register value  (0xBC0CA0) during a zero cycle inside the tick interrupt handler or update the count down value in either case?

    Perhaps why this issue seems to be faking us out there are phantom edges occurring at all times but are not actually trigger pulses.

        /*****************************************************
         * GPTM-3: 32 bitwide Oneshot timer configuration
         * for generating 102Hz fan Taco Tick intervals.
         *****************************************************/
        /* Set GPTM-3A clock source 120Mhz/16Mhz */
        MAP_TimerClockSourceSet(TIMER3_BASE, TIMER_CLOCK_SYSTEM);//TIMER_CLOCK_PIOSC
        /* Set GPTM-3A for OneShot next timeout.  */
        MAP_TimerConfigure(TIMER3_BASE, TIMER_CFG_ONE_SHOT);
        /* Disable the PWM interrupts */
        HWREG(TIMER3_BASE + TIMER_O_TAMR) &= ~(TIMER_TAMR_TAPWMIE);
        HWREG(TIMER3_BASE + TIMER_O_TBMR) &= ~(TIMER_TBMR_TBPWMIE);
        /* Set GPTM-3A load value for 102.7Hz */
        MAP_TimerLoadSet(TIMER3_BASE, TIMER_A, 0xBC0CA0); //1sec SYSCLK:0x7270E00, PIOSC:0xF42400
        /* Enable interrupt to occur on timer timeout.  */
        MAP_TimerIntEnable(TIMER3_BASE, TIMER_TIMA_TIMEOUT);
        /* Enable 1 second oneshot taco tick timer */
        MAP_TimerEnable(TIMER3_BASE, TIMER_A);
        /* Register the global interrupt in the controller */
        TimerIntRegister(TIMER3_BASE, TIMER_A, FanSpeedTickHandler);
        MAP_IntEnable(INT_TIMER3A);
    
        /* Synchronize CCP1 and 102.7 hertz timers
         * arresting drift between the two counters */
        MAP_TimerSynchronize(TIMER0_BASE, TIMER_0B_SYNC | TIMER_3A_SYNC);

  • Hi BP101,
    Even though I don't understand why PIOSC would make it work better in your use case in contrary to what is stated in the errata, I'm glad that it sort of solves your problem.
  • Hi Charles,

    PIOSC did but only for 1 second GPTM3 one shot load value did it stop edge count drifting with PWM0 zero interrupts. That is no longer true with TM4C1294KCPDT MCU on custom PCB. Neither clock source has any effect to stop edge counts accelerating with PWM0 interrupts. It seems GPTM3 one shot write value is being ignored when ever PWM0 GEN0 zero flag is interrupting NVIC and not ignored after. Even tested another on shot timer, GPTM5 made no difference with either clock source. This issue was thought resolved long ago TM4C1294NCPDT after POISC was made GPTM3 clock source.

    Recently tested 150uh chokes on Taco signal and +24vdc into Fan, only reduced escalating edge counts by a small margin. That seems to suggest part of the issue is internal delay time failure, enough so that external counter measures have little effect to arrest escalating edge counts. The idea to capture CCP1 edges and determine the time between then as RPM using Edge Timer mode with edge Count mode also failed in similar way. So the interval timer GPTM3 is critical to determine speed of edges (frequency) not just the count of edges occurring on CCP1 each interrupt cycle.
  • Hi Charles,

    Yesterday replaced old MCU with brand spanking new MCU. Just cut the old MCU from PCB via Dremel carbide wheel and stick on a new one (no heat) to stress surrounding components. Brings great idea for hand held inductive de/re-mounting apparatus. Better yet stick on MCU's pre-pasted package pins, simply heat pins with 235*C hot air, stick forever more. That would be an industry game changer!

    Sadly the same accelerated edge count issue remains with brand new MCU.
  • "That would be an industry game changer!"

    I thought your idea on fractional integer is a far better attempt.
  • BTW: Tested edge count circuit without D13, instead two series ferrites using D13 pads. Higher value R121 cuts off taco signal and edge counts go to zero.

    Seemingly simple fan control should not need a low pass filter and works great until GEN0 starts interrupting faster than idle mode 1ms periods. Hard to imagine NVIC interrupt tail chaining would somehow be causing an interrupt priority issue on the AHB. Especially in GEN0 80us periods where GPTM3 102Hz one shot timer is also interrupting NVIC.

    Perhaps your earlier mention edge count interval timer GPTM3 incorrectly becomes asynchronous to CCP1 when PWM0 is interrupting NVIC. That much seems more obvious as GEN0 1ms period changes to 80us or shorter frequency periods.

    Perhaps how 1 second interval (GPTM3) somehow skirted around PWMCLK=SYSCLK/2 as PIOSC is in alternate time domain. Earlier testing of GPTM-0B (CCP1) to also use PISOC did not help even for 1 second intervals via SYSCLK source. Seemingly I may have missed a connection exists and only focused on edge counts being wrong. PWM0-GEN0 is always running but the period changes from 1ms to 80us as PWMENABLE is asserted when the edge counts incorrectly start to accelerate. That phantom seemed to be related to the signal riding on DC B+ but only causes minimal impact to edge counts.

    So if we try making GPTM-0B/GPTM-3 exist in PIOSC clock domain there is GPTM#16. That seems an unreasonable solution and we can wait for TI to update MCU silicon to RA3 version, fixing GPTM#12/#13 errata.

  • Have you ever replaced an MCU or several at a time?

    Solder paste concept sucks bigly and requires stencils, precision applications by humans or robot arms. Radiant heat is destructive to surrounding components and degrades component life expectancy with each solder heating session.

    Inductive component release is a more logical approach to remove an MCU, easily possible today when it may not have been 20 years ago. If one of the largest revenue generators in US economy can not change a poorly thought out concept then who will?

    Huge advances have been made in conductive polymer technology where 3D printing has evolved to produce an entire electric motor, copper windings coated via ceramic polymers.
  • "Huge advances have been made in ..."

    All of them pale in comparison to your fractional integer invention which in my humble opinion is the only game changer the industry has seen over the last 127 years.
  • Really insults disguised as an attempt to smear a posted question, is far from being focused... Attempting to inject unsolicited opinion taken from context of past thread you obviously did not fully grasp the intent of may not be the humblest way forward!