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.

Debugger giving different timer values..

Other Parts Discussed in Thread: MSP430F5438A

Hi guys,

             im using MSP430F5438A with MSP-FET430UIFdebugger.Im running a simple code for measuring the time it takes for a ADC Sample.The code is simple as posted below.The problem is when i debug the same code and when i observe the TA1R register,it gives 0X2D(i.e 45 in decimal),so the conversion time is 45/(8MHZ) which gives 5.6 micro seconds.But instead of using the debugger and when i output the same TA1R value in LCD it gives 175 in decimal which is 22 micro seconds.Why is it different?i stop the timer as soon as sampling is done and then im displaying the value in LCD.This is the code..(i have posted only the  the logic of code.im using SCLK)

static bool flag=0;

static uint8 temp=0;

main()

{
ADC12CTL0 = ADC12SHT02 + ADC12ON; // Sampling time, ADC12 on
ADC12CTL1 = ADC12SHP; // Use sampling timer
ADC12IE |=BIT0; // Enable interrupt
ADC12CTL0 |= ADC12ENC;

P6SEL |= BIT0; // P6.0 ADC option select

updateLcd();

TA1CCTL0 = CCIE; 

TA1CCR0 = 65535;

TA1CTL = TASSEL_2 + MC_2 + TACLR;

ADC12CTL0|= ADC12SC;
while(flag==0);
TA1CTL=MC_0;//Halt the timer
updateLcd();
}

//#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector = ADC12_VECTOR
__interrupt void ADC12_ISR(void)
//#elif defined(__GNUC__)
//void __attribute__ ((interrupt(ADC12_VECTOR))) ADC12_ISR (void)
//#else
//#error Compiler not supported!
//#endif
{
switch(__even_in_range(ADC12IV,34))
{
case 0: break; // Vector 0: No interrupt
case 2: break; // Vector 2: ADC overflow
case 4: break; // Vector 4: ADC timing overflow
case 6: // Vector 6: ADC12IFG0
temp=ADC12MEM0;

flag=1;

break;
case 8: break; // Vector 8: ADC12IFG1
case 10: break; // Vector 10: ADC12IFG2
case 12:break; // Vector 12: ADC12IFG3
case 14: break; // Vector 14: ADC12IFG4
case 16: break; // Vector 16: ADC12IFG5
case 18: break; // Vector 18: ADC12IFG6
case 20: break; // Vector 20: ADC12IFG7
case 22: break; // Vector 22: ADC12IFG8
case 24: break; // Vector 24: ADC12IFG9
case 26: break; // Vector 26: ADC12IFG10
case 28: break; // Vector 28: ADC12IFG11
case 30: break; // Vector 30: ADC12IFG12
case 32: break; // Vector 32: ADC12IFG13
case 34: break; // Vector 34: ADC12IFG14
default: break;
}
}

static void updateLcd(void) {


lcdBufferClear(0);
lcdBufferPrintString(0, "Timer Test", 0, eLcdPage0);
lcdBufferSetHLine(0, 0, LCD_COLS-1, 7);
lcdBufferPrintString(0, "Timer value:", 0, eLcdPage3);
lcdBufferPrintInt(0,temp ,70, eLcdPage4);
lcdBufferPrintInt(0,TA1R,30,eLcdPage5);
lcdSendBuffer(0);
}

  • Hi Eswaran,

    How/where are you reading out TA1R using the debugger - where do you place your breakpoint? I'm wondering if you could be stopping the debugger before the timer is halted and therefore it is still running. Then when you continue on you see a higher count in TA1R when you read it later - that would be one guess as to what may be happening.

    In any case, I think it would be better practice in general to read out TA1R into a variable immediately after stopping the timer, and then use that variable in the LCD printing functions.

    Regards,
    Katie
  • Hi katie,

                   Im reading the TA1R at the register view.(i have attached a picture.)

    I dint place any breakpoints.Im executing it step by step. Im halting the timer and tried out writing the TA1R register value into a variable.Eventhough,the TA1R register shows 2F which is 47 written to the 'k' variable.When im debugging i can see in LCD that 47 displaying.But when im executing the code normally without the debugger,i see 176 at LCD.why is that?

  • Ah I think I understand your question better now - you are saying that when you single-step debug the result on the LCD and in the register do match, but when you run the code without debugging you see a longer value. I didn't know you were single-stepping the debugger when doing this.

    I believe when you single-step in the debugger, the device is constantly being started/stopped and accessed by the debugger. When you do this, the timer clock is also being started and stopped. Because it takes some time for the timer clock to start ticking again (and therefore to timer to start counting again) I think this could be why you are seeing a lower timer count when you single-step the part - the timer clock is not on the whole time.

    Single stepping is not going to be a good way to test anything timing-sensitive in your system in general because the debugger is going to interfere with your timing and make it different than it will be in your real system. I'd recommend running totally stand-alone, or doing "free run" in the debugger.

    Regards,
    Katie
  • Hai Katie,

                         Yes, i did a free run in my debegger and it worked.The variable k in watch window showed 176.Thanks for the reply:)

                                      

**Attention** This is a public forum