Timer_d Accuracy

Hi Jake, 

Have you tried this experiment running the timer in regulated mode? In free-running mode an internal clock to the timer is used and may result in the observed issue. If you have an external crystal on the system, you can use regulated mode and multiply it by 8 or 16 (depending on the crystal frequency) and use it for your capture system. If you don't have an external crystal, you can still use regulated mode with SMCLK as the source clock which presents a 20% worst-case jitter according to the datasheet.  

You may have seen this already, but just in case this app note has good information on Timer_D: http://www.ti.com/lit/an/slaa601/slaa601.pdf

Damian

Hi Damian,

Thanks for the reply. I have attempted using regulated mode with an external 16Mhz oscillator running the timer_d at 128Mhz; however, I still seem to have similar issues with the accuracy. Here are 6 sequential periods of 23 cycles of the 90Khz sine wave: 29235, 29272, 29269, 29297, 29285, 29246. This still results in a jitter of 62 (29297 - 29235) 128MHz clock cycles,  which is still out too inaccurate for the task. Can you think of anything else I may be able to do to enhance the accuracy? Or am I at the limits of the chip?

My initialisation code is:

PJSEL |= BIT4+BIT5; // Port select XT1
UCSCTL6 &= ~(XT1OFF); // XT1 On
UCSCTL6 |= XTS | XT1DRIVE_2;

UCSCTL3 = 0; // FLL Reference Clock = XT1

// Loop until XT1 & DCO stabilizes - In this case loop until XT1 and DCo settle
do
{
UCSCTL7 &= ~(XT1LFOFFG + XT1HFOFFG + DCOFFG);
// Clear XT1,DCO fault flags
SFRIFG1 &= ~OFIFG; // Clear fault flags
}while (SFRIFG1&OFIFG); // Test oscillator fault flag

UCSCTL6 &= ~(XT1DRIVE_2); // Xtal is now stable, reduce drive strength

UCSCTL4 &= ~(SELS_7); // Set SMCLK to the external oscillator.
UCSCTL4 &= ~(SELM_7); // Set MCk to the external oscillator.

__delay_cycles(375000);

P3DIR &= ~BIT2; // TD0.0 input
P3SEL |= BIT2; // TD0.0 option select

TD0HCTL1 |= TDHCLKCR;
TD0CTL0 = TDSSEL_2 // Use SMCLK – 16 MHz
+ CNTL_0 // 16-bit timer
+ ID_0 // Divide by 1
+ MC_0; // Halt timer until init is complete

TD0CTL1 |= TDCLKM_1; // TD0 clock = Hi-res local clock

TD0HCTL0 = TDHFW // Fast wake-up mode.
+ TDHD_0 // Set divider to 1
+ TDHM_0 // Multiply by 8. 8 MHz x 16 = 128 MHz
+ TDHREGEN // Regulated Mode
+ TDHEAEN // Enhance accuracy
+ TDHEN; // Enable Hi-Res

// Dual Capture mode.
TD0CTL2 |= TDCAPM0; // Channel 2 single capture mode

TD0CCTL0 = CAP // Capture mode
+ CM_1 // Rising edge
+ CCIS_1
+ CCIE; // Enable local interrupt for Timer TD0.0

// Start the counter (continuous mode).
TD0CTL0 |= MC_2;

Cheers,
Jake

Jake, 

How are you observing the captured values? Are you running this test with the debugger on? Also, do you have all other interrupts disabled? Can you please provide the code for your interrupt routine? I expect a more accurate reading with an external clock. Also, can you try using pin P1.7 instead of P3.2 for your input capture? 

Thanks, 

Damian 

Hi Damian,

Sorry for the late reply, unfortunately this part of the project has been put on hold for the time being.

I was observing the values using break points with the debugger and reading the variable values. However I did run a test by toggling pins based on the lower bits of the period values and reading them with a logic analyser. This confirmed my method of reading the values was unlikely to be the issue. No other interrupts have been enabled and I will try it using pin 1.7 when I get a chance to work on it again.

My code in the interrupt routine is as follows:

// Timer0_D0 Interrupt Vector
#pragma vector=TIMER0_D0_VECTOR
__interrupt void TIMER0_D0_ISR (void)
{
edge1[edgeCounter] = TD0CL0;
edge2[edgeCounter] = TD0CCR0;

edgeCounter++;

if (edgeCounter > 23)
{
edgeCounter = 0;
readyFlag = true;                                // Set the ready flag to true so the values can be processed in the main loop.
__bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
}
}

Cheers,
Jake