• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 910 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Halting the clocks while debugging

Silver Diamond
Genius 4010 points


My system does not halt the micro while debugging, so when I debug, I always enter into the ISR.  Why wont the Clock halt?

Timer Setup:

// Timer T0_B3 init
TB0CCR0 = 99999;
TB0CTL = TBSSEL_2 + MC_1; // SMCLK, UP mode
TB0CCTL0 = CCIE; // TBCCR0 interrupt enabled

ISR:
#pragma vector=TIMER0_B0_VECTOR

__interrupt void TIMER0_B0_ISR_HOOK(void){
g_time_msec++;
}

Setup

  • 0
    Guru 227245 points

    Halting the clock at a breakpoint doesn't mean it will stop in an instant. Programming the JTAG and stopping/starting the clocks takes some time.

    Also,

    Silver Diamond said:
    TB0CCR0 = 99999;
    won't do what you expect, as 99999 is >16 bit and truncated to 34463. At 1MHz clock speed (you didn't post your device config), this is an interrupt every 3.4ms.

    You cannot expect realtime timings in your code when you interrupt it with breakpoints. If you don't want to stop in the ISR, then don't place a breakpoint there.

  • 0 in reply to Jens-Michael Gross
    Genius 4010 points

    So when I am stepping through program step by step, the timer runs contiguously, not just enough to run the code in the step then halting?

    On the other note, the TB0CCR0 is normally 999 which makes my duration 1 msec @ 1 mhz.  I just tried different values to see how I can trouble shoot.

  • 0 in reply to Silver Diamond
    Guru 227245 points

    Silver Diamond said:
    So when I am stepping through program step by step, the timer runs contiguously, not just enough to run the code in the step then halting?

    At least it may be that the timer gets more clock ticks from  SMCLK before it is stopped again than you'd think by the amount of code processed.
    It's possible that during single-stepping though the ISR code, enough for the next trigger to have accumulated.

    I don't know how the clock control feature internally works. Also, it doesn't work on all MSPs equally well (and on some, there is no clock control at all).

  • 0 in reply to Jens-Michael Gross
    Genius 4010 points

    Very well, that makes sense, thank you, at least I know now what to expect .  My solution was to use UART to spit out needed data to terminal.  It worked pretty well.

**Attention** This is a public forum