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.

WTimer5 pin B capture not working



Hi everyone,

I've got the following code which is working great on WTIMER5, pin A which is PD6 (I'm using a Tiva-C launchpad btw). This is a freq counter, timegated by an external 1 sec signal. I'm feeding an 5 MHz signal into it and getting the correct result.

#define CAPTURE_TIMER_PH			SYSCTL_PERIPH_WTIMER5
#define CAPTURE_TIMER_BASE			WTIMER5_BASE
#define CAPTURE_TIMERA_INT			INT_WTIMER5A
#define CAPTURE_TIMERB_INT			INT_WTIMER5B

/* Edges to count from oscillator (5V tolerant!!!) */
/* WT5CCP0 - PD6 -#53*/
/* WT5CCP1 - PD7 -#10*/

#define EXTEDGE_PH SYSCTL_PERIPH_GPIOD 
#define EXTEDGE_PIN_BASE GPIO_PORTD_BASE

#define EXTEDGE_PINA GPIO_PIN_6
#define EXTEDGE_PINB GPIO_PIN_7

#define EXTEDGE_PINA_CONFIG	GPIO_PD6_WT5CCP0
#define EXTEDGE_PINB_CONFIG	GPIO_PD7_WT5CCP1

void Init_Capture_Timer(void){

	/*
	 * Enable Capture Timer peripherial
	 */
	SysCtlPeripheralEnable(CAPTURE_TIMER_PH);

	/*
	 * Configure 24 bit capture timer
	 */
	TimerConfigure(CAPTURE_TIMER_BASE, TIMER_CFG_A_CAP_COUNT_UP);

	/*
	 * Capture on positive edges
	 */
	TimerControlEvent(CAPTURE_TIMER_BASE, TIMER_A, TIMER_EVENT_POS_EDGE);


	/*
	 * Load and Match registers
	 */
	TimerLoadSet(CAPTURE_TIMER_BASE, TIMER_A, 0xFFFFFFFF);
	TimerMatchSet(CAPTURE_TIMER_BASE, TIMER_A, 0x00);

}

void Enable_Capture_Timer(void){

	TimerEnable(CAPTURE_TIMER_BASE, TIMER_A);
}

void Disable_Capture_Timer(void){

	TimerDisable(CAPTURE_TIMER_BASE, TIMER_A);
}

//Pin interrupt handler, asserted by an external 1 sec signal

void TimeGateIntHandler(void){


	ui32EventCount = HWREG(CAPTURE_TIMER_BASE + TIMER_O_TAR);
	HWREG(CAPTURE_TIMER_BASE + TIMER_O_TAV) = 0;

	GPIOIntClear(TIMEGATE_PIN_BASE, TIMEGATE_PIN);
	Task.Bits.FRQDRDY = 1;
}



Now I want to use the other capture pin (pin B) which is PD7. I changed the code to pin B, however it is not working.

void Init_Capture_Timer(void){

	/*
	 * Enable Capture Timer peripherial
	 */
	SysCtlPeripheralEnable(CAPTURE_TIMER_PH);

	/*
	 * Configure 24 bit capture timer
	 */
	TimerConfigure(CAPTURE_TIMER_BASE, TIMER_CFG_B_CAP_COUNT_UP);

	/*
	 * Capture on positive edges
	 */
	TimerControlEvent(CAPTURE_TIMER_BASE, TIMER_B, TIMER_EVENT_POS_EDGE);


	/*
	 * Load and Match registers
	 */
	TimerLoadSet(CAPTURE_TIMER_BASE, TIMER_B, 0xFFFFFFFF);
	TimerMatchSet(CAPTURE_TIMER_BASE, TIMER_B, 0x00);

}

void Enable_Capture_Timer(void){

	TimerEnable(CAPTURE_TIMER_BASE, TIMER_B);
}

void Disable_Capture_Timer(void){

	TimerDisable(CAPTURE_TIMER_BASE, TIMER_B);
}

//Pin interrupt handler, asserted by an external 1 sec signal

void TimeGateIntHandler(void){


	ui32EventCount = HWREG(CAPTURE_TIMER_BASE + TIMER_O_TBR);
	HWREG(CAPTURE_TIMER_BASE + TIMER_O_TBV) = 0;

	GPIOIntClear(TIMEGATE_PIN_BASE, TIMEGATE_PIN);
	Task.Bits.FRQDRDY = 1;
}

I'm getting xFFFFFFFF in the ui32EventCount variable. I may miss out something obvious...but I can't find the problem.

  • In TimerConfigure() you need to configure the timer to work in split timer or else you don't have a TimerB, only 1 TimerA.

    You need to add TIMER_CFG_SPLIT_PAIR to it.

    Without this you will have just 1 64bit timer, if you add the SPLIT_PAIR config then you have 2 32bit timers wich are TImer5A and Timer5B

  • Hello Luis

    thank you for your help. I changed the code to

    /*
    	 * Configure 24 bit capture timer
    	 */
    	TimerConfigure(CAPTURE_TIMER_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_B_CAP_COUNT_UP);

    Now I'm reading 0x00000000 as the result :-(

  • Hi Greg

    First since it's 32bit you can't load 0xFFFFFFFF, you need to subtract 1 i belive.

    Also, how to you actualy capture with the pin B? Timer5B is only conected to PD7

  • Luis Afonso said:
    since it's 32bit you can't load 0xFFFFFFFF,

    Why not - 0xFFFF.FFFF fits nicely w/in 32 bits!   (there may be other (perhaps timer limitations) but surely 0xFFFF.FFFF is legal & fits w/in a 32 bit space)

    Missing here is the dreaded "Default" behavior of PD7.  It's twin - PF0 - also defaults to NMI and both require special unlocking procedure to achieve more standard usage...  (i.e. alternately selecting PD7's "Timer" function) 

    You're far from alone in missing this "strange/unwanted" default behavior.  (imho "few" require or exploit NMI - that option should remain - but the vast majority of users would be  better served by eliminating the NMI default behavior)  The NMI behavior is described (in the "mice-type") and several here have shouted long/hard to vendor to, "far better emphasize."  Vendor "Duly notes" - yet posters land this trap repeatedly - such "vendor note" has yet to yield any effective correction.   

    Fix that PD7 default & then observe Timer B's behavior...

     

  • noooooo, i was betrayed by my fingers . I used windows calculator to convert hexadecimal to decimal and got it wrong somehow 

    Sorry, 0xFFFF FFFF fits in 32bits

  • Fear not Luis - we've all been there - done that.

    BTW - you're making nice progress and aiding others as well.  That's good to see.

    Some post's detail strikes me as bit, "too much" for forum appearance - believe that more general issues - of interest to most here - are those best for forum analysis/discussion.  (one man's opinion...)

  • Thank you. I do notice that i tend to write to much and get into to much detail, it's just the way i normaly think 

  • Luis Afonso said:
    write too much and get into too much detail...

    Who doesn't?  Again - great to see you use your knowledge & time to  assist others...

    As to forum content - and "reasonable" detail - how much is too much - how deep is too deep?  (forum provides no guidelines - despite past "bounding" suggestions - {we're told they've been "duly noted"}...)

    You/I note that forum has become very much a, "one-man show" - and too much focus on the "fine details" of a single peripheral prevents the creation of a new, improved, "Peripheral Usage - detailed guidelines."  To my small tech group - that would seem the best use of our forum helper - his time/energy is limited - should not we think (and care) about what's best for most - here?   Responding to such specific - deep peripheral detail - constrained w/in a single forum thread - is clearly not the "best/brightest" outcome for most here! 

    There are posts which essentially ask the helper to do, "Everything."  Or demand that the response be only in a certain form (i.e. direct register) - perhaps because of others (or my) suggestions - those poster demands are now being (somewhat) resisted.  (i.e. use the API's)

    We don't want to leave posters "hang" - yet there should be some consideration given to what is appropriate/proper detail for so diverse a forum - with users of widely varying background, experience & MCU/engineering familiarity.

    The uDMA w/in these MCUs is an especially powerful & engaging peripheral - and one of the last to arrive.  Having some background @ large semi firm - I'd suspect that "time-crunch" forced the uDMA chapter to be bit rushed - thus its write-up is too vague for clear, complete understanding.  (especially so when operating at/around the uDMA fringes). 

    This shortcoming can be corrected via a series of (pardon) seemingly disjointed poster questions - or can be attacked by those w/key insider knowledge (not everything known is shared) in the most logical and effective (i.e. comprehensive App Note {or similar} manner.) 

  • Thanks cb1 for the info on the PD7 default behaviour. I don't want to struggle with 2 issues at the same time so I temporarily moved the signal input to a different pin, namely PC7 (WT1CCP1) in order to check if timer B code is functioning properly - and it is not. Again, I checked with WT1CCP0 (Timer A, PC6) and it was working great so it's likely that the problem is in my Timer B code.

  • Hi Greg, 

    did you remember using TIMER_CFG_SPLIT_PAIR in TimerConfigure?

     

    Edit: To unlock pins, it is described in the datasheet on the GPIO 

    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = 0x80;

  • Hi Luis,

    thank you for your input. Yes, I'm using TIMER_CFG_SPLIT_PAIR in TimerConfigure. Regarding the PD7 unlock issue  please note my earlier post .

  • Sorry about asking again TIMER_CFG_SPLIT_PAIR, i almost a bit sleep walking (sleep posting maybe?) yesterday so i didn't realy remember

    Just wanted for you to know how to unlock it, since i have a noted down that for easy access.

    Could you please post your full code? with GPIO initialization. Maybe it's a very simple issue with initialization

  • your using TIMER_CFG_B_CAP_COUNT_UP but you configure the LOAD to the last value of a 32bit counter, so it instatly goes to 0x00 when it starts counting and interrupts.

    I belive that is the problem

  • Luis, I'm not using any capture timer interrupt here. My method is:

    - in test.c, I create a time gate signal with a timer and a gpio output pin. 

    - in test.c I create a 5 MHz test signal using a PWM

    - I connect my 1 sec time gate signal to my time gate input input using a jumper wire

    - I connect the 5 Mhz signal to my capture timer (edge count) input

    In every 1 sec, I'll have a pin interrupt (fired by the 1 sec timer period) where I simply read my capture timer's counted edges and zero the timer. Please check test.c, board.c, capture_timer.c)

  • In edge count normaly the the timer should stop counting, by ignoring any edges, when the match value is reached, so you having the load at 0xFFFFFFFF (max o a 32-bit value) and having the edge count in up mode, the counting should stop just after 1 edge count, since it goes to 0, the match value. So that's probably why it is not working.

     

    If you want to use up-mode you need to load 0x00, and use a match of 0xFFFFFFFF, or just switch to down-mode