Updating Timer Register on MSP430F5529

As an update, I have swapped over the Timer A interrupt to a Timer B interrupt with the same sort of initialization and configuration, getting the same results.  I'm still not sure how to perfectly implement the Timer B function that allows it to properly reset the period, but here's the new snippet of code for reference.  If anyone knows how to utilize Timer B to avoid missed pulses/long pulses, please let me know!

//***************** BEGIN TIMER B INTERRUPT SETUP *****************\\

TBCCTL0 = CCIE; // TBCCR0 interrupt enabled
TBCCR0 = 1000; //Capture/Compare register value
TBCTL = TBSSEL_1 + MC_1 + TBCLR; // ACLK, upmode, clear TBR

__bis_SR_register(GIE); //enable maskable interrupts

Timer_Calib = Timer_Calib_Freq*Timer_Calib_Reg_Value; //Value used for calibrating foot pulse to Timer A

//***************** END INTERRUPT TIMER SETUP *******************************\\

Math_Sub_Routine(){

//blah blah, non-related stuff.

Timer_Register_Value = Timer_Calib / Foot_Pulse_Freq;
TBCCR0 = Timer_Register_Value;

}

// Timer B0 interrupt service routine
#pragma vector=TIMERB0_VECTOR
__interrupt void TIMERB0_ISR (void)
{
P1OUT ^= 0x01; // Toggle P1.0 using exclusive-OR
P2OUT ^= BIT0;
}

Again, thank you in advance for looking at my issue and trying to help.

-Thomas

Hello,

You could try with this:

If you are using up mode, clear the TXR register each time you refresh the compare register.

If you are using continuous mode, refresh the timer like this "TXCCRY += newTimingPeriod;"

Alrighty,

So I've come to a solution about this issue.  Apparently it is not a great idea to update the frequency of the timer  (A or B) in up-mode.  This can cause the timer to have extra-long pulses if the new period is smaller than the old period.  I fixed the issue by running the timer in continuous mode and then writing the new period to a temporary variable and then updating the timer comparison register with the temporary variable.  A simple demonstration of this is code is shown below, resulting in a full period for 2 different frequencies, without any issues:

#include <msp430.h>

/*
* main.c
*/
int main(void) {
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x01; // Set P1.0 to output direction
P2DIR |= BIT0;

TBCCTL0 = CCIE; // TBCCR0 interrupt enabled
TBCCR0 = 10000;
TBCTL = TBSSEL_1 + MC_2 + TBCLR; // ACLK, contmode, TBR counts to 0, clear TBR

__bis_SR_register(LPM0_bits + GIE); // Enter LPM0, enable interrupts
__no_operation(); // For debugger
}

// Timer B0 interrupt service routine
#pragma vector=TIMERB0_VECTOR
__interrupt void TIMERB0_ISR (void)
{
static unsigned int k = 0;
static unsigned int tempccr0 = 10000;

P1OUT ^= 0x01; // Toggle P1.0 using exclusive-OR
P2OUT ^= BIT0;  //Digital output signal on P2.0
if(k==2){
tempccr0 += 20000;
k++;
}
else if(k==3){
tempccr0 += 20000;
k = 0;
}
else{
tempccr0 += 50000;
k++;
}
TBCCR0 = tempccr0;
}

Maybe this will help anyone in the future who ran into my problem.

-Thomas

Thomas O'Connor said:

 I fixed the issue by running the timer in continuous mode and then writing the new period to a temporary variable and then updating the timer comparison register with the temporary variable.

That's indeed an alternative way. It also allows different PWM frequencies and duty cycles on the same timer module. However, each update requires a software interrupt that must be handled before the new destination is reached.

Thomas O'Connor said:

Apparently it is not a great idea to update the frequency of the timer  (A or B) in up-mode.  This can cause the timer to have extra-long pulses if the new period is smaller than the old period.

Actually, the TimerB is designed to circumvent this problem by latching writes to the CCR registers and synchronizing the update to the next timer overflow. I don't know why it didn't work for you.

But I have an idea. Just guessing, based on your observations. In your code you do

TBCCTL0 = CCIE + CLLD_1; // TBCCR0 interrupt enabled
TBCCR0 = 50000;
TBCTL = TBSSEL_1 + MC_1 + TBCLR; // ACLK, upmode, TBR counts to 0, clear TBR

So on power-up, TBCCR0 is zero. You program the CCR0 to update CCL0 on timer overflow. Then you write 50000 to CCR0. Now no overflow has happened yet, so the 50000 doesn't make it into CCL0. When you start the timer, it stays on 0 (counts form 0 to 0).
It is possible that in this situation, the update will never happen.

So set CCLD_0, write the inital value to CCR0, then set CCLD_1.

Usually, you use CCLD_1 on CCR1 or CCR2, and leave CCR0 constant, once the PWM frequency has been set.

The combination of CCLD_1 on CCR0 with timer in up or up/down mode will probably not work.