msp430f5xx timer compare output mode, TACCR0 == TACCRx

The description of the CCR units has some minor flaws which may lead to misunderstanding.

There is no direct relation between CCR0 and CCRx. ALL units are just compared to TAR. However, CCR0 plays a specific role in UP or UP/DOWN mode:
In UP mode, when the timer reaches CCR0, it will roll over to 0 with the next timer tick. In up/down mode it will reverse counting direction with the next tick.

Anyway, the double action modes have the first action happening when TAR counts to CCRx, and the second action happening when TAR counts to 0 (so not if TAR is reset or written to 0).

In case of CCR0, this means that there is eactly 1 timer tick between the two actions (so these modes are not as useless as the description implies)

Since 0 is a count, you should program CCR0 to 1 less than the number of ticks per cycle.

If CCRx is set to the same as CCR0, the same happens. First action happens when TAR counts to CCRx, second action one tick later.
Usually, you'll use reset/set mode. So on TAR->=, the output is set, and on TAR->CCRx it is reset. The duty cycle is calculated with (CCR0+1)*percentage. So for 100% duty cycle, set CCRx to CCR0+1. What happens is that the output is set on TAR->0 but never reset since TAR never reaches CCR0+1. Which is 100% duty cycle.

However, 0% duty cycle are not specified, as both actions would take place on TAR->0, which results in a race condition. To get 0% duty cycle, you should e.g. switch the output mode to reset.

Jens-Michael Gross said:

Anyway, the double action modes have the first action happening when TAR counts to CCRx, and the second action happening when TAR counts to 0 (so not if TAR is reset or written to 0).

In Continuous mode, the first action happens when TAR counts to CCRx, and the second when TAR counts to CCR0. Not to 0. See slau208H (x5xx family), page 364.

Anyway, if I put CCR0 to 0 I have the same behavior.

But if CCRx is also 0, TAR counts to CCR0 and and CCRx at the same time. Which action takes place, Reset or Set? Or both? In which order?

Jens-Michael Gross said:

In case of CCR0, this means that there is eactly 1 timer tick between the two actions (so these modes are not as useless as the description implies)

 

Since 0 is a count, you should program CCR0 to 1 less than the number of ticks per cycle.

The specification says:

The OUTn signal is changed when the timer reaches the TAxCCRn and TAxCCR0 values, depending on the output mode.

Why would there be 1 timer tick between the two actions?

Jens-Michael Gross said:

Usually, you'll use reset/set mode. So on TAR->=, the output is set, and on TAR->CCRx it is reset. The duty cycle is calculated with (CCR0+1)*percentage. So for 100% duty cycle, set CCRx to CCR0+1. What happens is that the output is set on TAR->0 but never reset since TAR never reaches CCR0+1. Which is 100% duty cycle.

I am using Continuous Mode. The timer does not reset on CCR0. Do you refer to Up Mode? The timer is also used for other functionalities, so I can't change its mode.

Gauthier ��stervall said:

In Continuous mode, the first action happens when TAR counts to CCRx, and the second when TAR counts to CCR0. Not to 0. See slau208H (x5xx family), page 364.

Gauthier ��stervall said:

Which action takes place, Reset or Set? Or both? In which order?

Did you do any programming/testing yourself or are you just in the stage of reading the users guide?

I think this is another case for Jeff Tenney, who did the tests last time for up mode and might be willing to extend them to cont mode.

Thanks. That would be a valuable note to add in the specification.

Jeff Tenney said:

In summary, the second action of the double action modes usually occurs when TAR equals CCR0.  However, in "up" mode, the second action occurs when the counter rolls from CCR0 back to zero.

This is a bit surprining. Why should it work differently on the two modes?
One possible explanation is that the second action doesn't happen when TAR counts to CCR0 but when TAR counts from CCR0. This would be the moment TAR counts to 0 in up mode and when it counts to CCR0+1 in cont mode.
This one tick difference (if this is indeed the answer) might have slipped through unnoticed when you tested cont mode.

It's difficult to test something that is the reference for your test :)

Just an 'educated' guess. As usual.

Jeff Tenney said:

Any configuration that tells the Timer to both set and reset the output on the same clock tick will result in undefined behavior.

Hi JMG,

I was intrigued by your idea that the second action might always occur as the counter counts from CCR0.  So I reviewed my notes from before and even did a couple of extra tests.  Alas, no, the second action occurs counting to CCR0 in continuous and up-down modes, and it occurs counting from CCR0 to zero in up mode.

Since two pair of eyes are better than one, please take a look at this:

int main( void )
{
  WDTCTL = WDTPW + WDTHOLD;
 
  UCA0CTL1 = UCSSEL_2 + UCSWRST;
  UCA0CTL0 = UCMSB + UCMST + UCSYNC;
  UCA0BRW = 1;
  UCA0CTL1 &= ~UCSWRST;
 
  P3SEL |= BIT3; // MOSI
  P2SEL |= BIT7; // SCLK
 
  TA0CCR0 = 2;
  TA0CCTL0 = CCIE;
  TA0CCR1 = 1;
  TA0CCTL1 = OUTMOD_3; // Set/Reset
  TA0CTL = TASSEL__ACLK + MC__CONTINUOUS + TACLR;

  P1SEL |= BIT0 + BIT2; // ACLK and TA0.OUT1
  P1DIR |= BIT0 + BIT2;

  _BIS_SR(CPUOFF + GIE);
}


#pragma vector = TIMER0_A0_VECTOR
__interrupt void test( void )
{
  UCA0TXBUF = TA0R;
}

Which generated the following scope image:

When I switched to MC__UP instead of continuous, the ISR still captured a TA0R value of 2, but the falling edge on TA0.OUT1 came afterwards; one cycle delayed:

So the final conclusion remains the same, and the documentation is still mostly right.  The examples and diagrams that are specific to each counting mode are accurate.  The summary statements later are too general and don't mention the peculiarity of double-action outputs in "up" mode.

Jeff

Jeff Tenney said:

Alas, no, the second action occurs counting to CCR0 in continuous and up-down modes, and it occurs counting from CCR0 to zero in up mode.

However, things are as they are.

On the bottom line, this means that CCR0 cannto be used for PWM output under any circumstances (even if accepting a full TimerA cycle as PWM cycle).
Makes the TimerA2 on the G2x devices even less usable.

p.s: you have a nice scope. What is it?

Yes, TimerB has the same results.  Don't forget that these results match the documentation specific to up mode:

and for Timer B:

I would say TI definitely provides this special behavior on purpose.  For some people using PWM, it makes considering the CCRn values simpler knowing that the second action occurs at zero.

And I agree about the lowly TimerA2.  Effectively it has only one PWM channel.  To get two, you'd have to use continuous mode and be very very careful with high and low duty cycles.  Not really practical.

Jeff

My scope is a Tek.  I really like it.  http://www.tek.com/products/oscilloscopes/mso4000/  (and no, I don't work for Tek).

Jeff Tenney said:

I would say TI definitely provides this special behavior on purpose.  For some people using PWM, it makes considering the CCRn values simpler knowing that the second action occurs at zero.

Jeff Tenney said:

And I agree about the lowly TimerA2.  Effectively it has only one PWM channel.  To get two, you'd have to use continuous mode and be very very careful with high and low duty cycles.  Not really practical.

Also, it makes no sense to have the second action happening on CCR0. You can achieve the very same result in cont mode when you just select CCR1 relative to the timer overflow. (if the second action would happen at timer overflow instead of CCR0).
So in cont mode, CCR0 is pretty much useless for an unattended hardware function. It's only use is something you could have gotten as well completely without it.
So you're left with a software-supported increment function as its only use.

I would also have preferred second action on return to 0. As you said it does not make much sense to have reset on CCR0 in continuous mode. Return to 0 is actually (logically, I don't mean how it's done) what triggers the second action in up mode. I suppose TI did not want to or could not take the TAIFG signal in the signal generation.

There are only few applications I could think of: if you want a pulse of length x, starting in y ticks. Not very useful compared to a real PWM.

Or if you want to have several PWM signals with a defined phase shift.

Gauthier ��stervall said:

if you want a pulse of length x, starting in y ticks.

Gauthier ��stervall said:

Or if you want to have several PWM signals with a defined phase shift.

Jens-Michael Gross said:

Since all pulses end at CCR0, you couls simply shift this so they end at TAR->0 (just add 65536-CCR0 to teh CCRx values) and you'll get the very same result.

I wrote "starting in y ticks". Assume that you do not want to change the value of TAR.

Jens-Michael Gross said:

Only if the pulse length matches the phase shift, so all end at CCR0. Which you can also get when inverting the standard PWM logic :)

I was thinking when using several timers that would somehow be synchronized.

Note that I wrote these possible use cases as an attempt to explain to myself why TI would make CCR0 behave that way. As I mentioned, I'd find a second action of PWM on TAIFG much more worthwhile.

Gauthier ��stervall said:

I wrote "starting in y ticks". Assume that you do not want to change the value of TAR.

Gauthier ��stervall said:

I was thinking when using several timers that would somehow be synchronized.

Gauthier ��stervall said:

As I mentioned, I'd find a second action of PWM on TAIFG much more worthwhile.

While we're discussing the drawbacks of timer A, the fact that they don't have latches for CCR make them very hard to use for PWM LED control or sound generation, where the duty cycle varies constantly. For that you need timer B. But we've really got far from the original topic, now.