CCS/MSP430FR2311: Timer based PWM output glitches

Hello,

This issue could be caused by your SYSCFGx settings. Please refer to the following two threads for some related discussion.

Regards,

James

MSP Customer Applications

Hi James,

I checked the Cout pin and there is no voltage correlation between the PWM output and P2.0. Also I am not using P2.0 for any function in my program.

I also added the recommend line "SYSCFG2 |= TB0TRGSEL;" because I am using TB0 and it did not stop the glitches. Alternately I tried using  "SYSCFG2 |= TB1TRGSEL;" and that did not stop the glitches either. 

The P2.0 voltage is the top waveform below and one of the PWM outputs is below. The voltage is only about 100mV on P2.0.

Do you know of any other solutions?

I made the changes where I stop the timer before making changes to the CCR values, I only change the CCR values if the ADC value changes by a certain amount,

and I changed the output mode to Set/Reset and Reset/Set. This did not solve the issue. However the blinking now happens less. This may be because the ADC

is not doing as many conversions as when it was polling.

Is it possible to dynamically change the CCR values without altering the PWM pulses? How would you solve this issue?

Hey Matt,

The oscilloscope images are at the very top of this forum. I stopping the timer but it has not solved the issue.

I also received an app note on generating variable duty cycle PWM signals using a MSP430F5529. They use a method of checking the value of the CC timer output using the CCI bit in the TBxCCTLx register in order to choose an appropriate CCR value. Also they don't stop the timers before setting the CCR values. What are your thoughts on that method?

app note: www.ti.com/.../slaa513a.pdf

Here is a code snippet of their interrupt.

/*Multiple timebase PWMs
*Period is determined by the sum of the two TBCCRx offset values
*Duty cycle is determined by the ration of the high/low TBCCRx value
*to the total period.
*/

// Timer B0 interrupt service routine
#pragma vector=TIMERB0_VECTOR
__interrupt void TIMERB0_ISR (void)
{
if(TBCCTL0 & CCI) // If output currently high
{
TBCCR0 += 300; // 75% high
}
else
{
TBCCR0 += 100; // 25% low
}
}

// Timer_B1 Interrupt Vector (TBIV) handler
#pragma vector=TIMERB1_VECTOR
__interrupt void TIMERB1_ISR(void)
{
switch(__even_in_range(TBIV,14))
{
case 0: break; 
case 2: if(TBCCTL1 & CCI)
{
TB0CCR1 += 100; // 33% high
}
else
{
TB0CCR1 += 200; // 66% low
}
break;
case 4: if(TBCCTL2 & CCI)
{
TB0CCR2 += 1250; // 31.25% high
}
else
{
TB0CCR2 += 2750; // 68.75% low
}
break;
case 6: if(TBCCTL3 & CCI)
{
TB0CCR3 += 4000; // 80% high
}
else
{
TB0CCR3 += 1000; // 20% low
}
break; 
case 8: if(TBCCTL4 & CCI)
{
TB0CCR4 += 1500; // 25% high
}
else
{
TB0CCR4 += 4500; // 75% low
}
break; 
case 10: if(TBCCTL5 & CCI)
{
TB0CCR5 += 4000; // 57.1% high
}
else
{
TB0CCR5 += 3000; // 42.9% low
}
break; 
case 12: if(TBCCTL6 & CCI)
{
TB0CCR6 += 3000; // 37.5% high
}
else
{
TB0CCR6 += 5000; // 62.5% low
} 
break; 
case 14: P1OUT ^= 0x01; // overflow
break;
default: break;
}
}

Hey Matt,

The LED driver seems to shut down at a point that is unrelated to the interrupt... I have a GPIO going high when in the interrupt and the driver does not shut down at that point. The driver seems to shut down when channel 1 goes low. Note that I do have overlap between the PWM outputs.

The top waveforms channel 1 and 2 are the PWM outputs. Channel 3 is the GPIO that is set high when the interrupt is set. Channel 4 is the LED driver current.

The time where I set both PWM outputs to be high manually is shown in the first capture. At that point channel 1 is already high so setting the GPIO high did not help as I thought it would..

Hey Neville,

Does the LED driver documentation define any other circumstances where the LED driver will reset? 

Regards,

Matthew