• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 466 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5529: Using ACLK Divider Causes an accumulative timing error

Tal Stein
Prodigy 30 points
Part Number: MSP430F5529

Hello all,

I am trying to use TimerA0 and TimerA1 to achieve a synchronised blinking on 2 seperate leds. Both Timers are set up to have ACLK as reference and are counting up to CCR0. Interrupts are set to flip the led states. When i dont use a divider and put 32768 on TA0CCR0 and 32768/2 on TA1CCR0 i get a perfectly synchronised blinking every second and half second even when left running for a long time. But when i try to use a divider in order to get the CCR0 values closer to approximate ms for future use (32768/32 =1024Hz) I found that the led blinks get out of sync very quickly. I've tried using both a combination of TAxCTL set to divide by 8 plus TAxEX0 set to divide by 4, and leaving the timer specific dividers to 1 and using only the UCSCTL5 ACLK divider set to /32, both gave the same results.

Putting the same value in both CCR0 registers also gives me a perfectly synchronised blinking no matter with what division.

Is there something i am missing?

I am using a MSP430F5529 launchpad.

Here is my code:

void SetupTimers(){


// Setup ACLK

UCSCTL4 |= SELA__XT1CLK; // Set XT1 as source(32768Hz)

// Timer0 Setup
TA0CCTL0 = CCIE; // CCR0 interrupt enabled
TA0CTL = TASSEL__ACLK + MC__UP + TACLR + ID__8; // ACLK, upmode, clear TAR, divider 32768/8
TA0EX0 = TAIDEX_3 ;  // divider /4
TA0CCR0 = 1024;  // 1= 1.024ms

// Timer1 Setup
TA1CCTL0 = CCIE; // CCR0 interrupt enabled
TA1CTL = TASSEL__ACLK + MC__UP + TACLR + ID__8; // ACLK, upmode, clear TAR, divider /8
TA1EX0 = TAIDEX_3 ;   // divider /4
TA1CCR0 = 1024/2;  // 1= 1.024ms;

}

#pragma vector=TIMER0_A0_VECTOR
__interrupt void TIMER0_A0_ISR(void){
    P1OUT ^= BIT0;

}

#pragma vector=TIMER1_A0_VECTOR
__interrupt void TIMER1_A0_ISR(void){
    P4OUT ^= BIT7;


}

Thanks for the help!

  • 0
    TI__Expert 7015 points

    Hi, Stein, 

    Do you have tried following cases?

    Case1: TA0CCR0 = 1024; and TA1CCR0 = 1024; 

    Case2: remove ID__8 setting and keep TAIDEX_3. TA0CCR0 = 1024; and TA1CCR0 = 1024/2; 

    Case3: remove TAIDEX_3 setting and keep ID__8. TA0CCR0 = 1024; and TA1CCR0 = 1024/2; 

    Thanks, 

    Lixin 

  • 0 in reply to Lixin Chen1
    Prodigy 30 points

    Thank you for your reply, Lixin.

    Case 1:

    The LEDs seem to stay in sync for as long as i tested them (about 10 minutes).

    Case 2:

    For CCR0 value of 1024 and 1024/2:

    It's very hard to see weather or not the LEDs stay in sync because now they blink too fast for me to have an accurate assessment.

    For CCR0 values of 8192 and 8192/2:

    Bringing it back to sedond / half second blinks the LEDs do get out of sync, but the rate in which they diverege from one another is much slower than before. It took several minutes for me to notice a difference (with the initail settings it took less than a minute for them to be completely out of sync).

    Case 3:

    For CCR0 values of 1024 and 1024/2:

    Again, the blinking is way too fast for me to notice any syncing issues.

    For CCR0 values of 4096 and 4096/2:

    Same as in case 2; The LEDs get out of sync, the rate of which seems to be somewhere between the initial settings and the case 2 test. (Not as fast as the initial settings, not as slow as with the case 2 settings).

    Case 4:

    I've added a 4th case to test out a combination of UCSCTL dividing by 8 and TAIDEX dividing by 4 with CCR0 values at 1024 and 1024/2 which i haven't tried before.

    Results were same as the initial settings, LEDs get out of sync very quickly.

    Do you have any thoughts as to what could be the issue?

    Thanks,

    Tal.

  • 0 in reply to Tal Stein
    Guru 96315 points

    > TA0CCR0 = 1024;  // 1= 1.024ms

    You should assign CCR0 to (period-1) in Up mode, since the "0" tick counts. [Ref UG (SLAU208Q) Fig 17-3]. Try:

    > TA0CCR0 = 1024-1;  // 1= 1.024ms

    Similarly for TA1.

  • 0 in reply to Bruce McKenney
    Prodigy 30 points

    Thank you very much Bruce, that seemed to do the trick.

    Please correct my reasoning if necessary since i want to get to the bottom of this. If CCR0 should take (period -1)  than if TA0CCR0=1024 TA1CCR0 should have been ((1025/2)-1) = 511.5 which means i was losing the equivalent of half a count every cycle? Makes sense seeing that increasing the count speed also increased the time it took to visibly get out of sync.

    Thanks again for the help!

  • 0 in reply to Tal Stein
    Guru 96315 points

    Yes. Alternatively: (1024/2+1) isn't half of (1024+1). [I hope I said that right.]

**Attention** This is a public forum