MSP430 Timer glitch switching between output modes

I am highly suspicious of the accuracy that Note.  I think the suggested safe method there may actually generate a wrong OUTx.

I'm a bit suspicious too...  I do have the noted OUTMOD_7 implemented and followed with my intended output mode (below) within a TimerA1Interrupt routine. 

        TACCTL1 = OUTMOD_7 | CCIE;        // per errata, must have at least 1 bit set
        TACCTL1 = OUTMOD_4 | CCIE;        // toggle output on next compare

It is with the noted "safe method" that I get this strange behavior where about 1 out of 4 boards show a glitch on the output and it is very repeatable.  The wrong OUTx, as you suggested may happen.  As far as I'm able to tell, the glitch acts like the output signal reacts to OUTMOD_7 (output reset on TACCR1, set on TACCR0) instead of OUTMOD_4 (output toggle on TACCR1 and ignores TACCR0).  I have not tried without the noted line.

Your code is worse than the suggested safe method - which is actually:

TACCTL1 |= OUTMOD_7;
TACCTL1 &= OUTMOD_3;

I think the suggested safe method is right.

The idea is to avoid letting the OUTMOD bits all be zero even for a tiny instant during the write operation to CCTLx.  If the OUTMOD bits are ever zero, the OUT bit drives the pin, and the output flip-flop is set to match the OUT bit.  This could cause a glitch if the output flip flop was set opposite of the OUT bit.

So from this perspective, the OP's code and OCY's code are functionally equivalent (after fixing OCY's typo omitting the ~ character).  Both prevent the problem as long as the application can tolerate the temporary use of mode 7. 

However I suspect the OP's application does not tolerate the visit to mode 7 because a timer match occurs (rarely) while mode 7 is in effect.  Some application rework is in order to provide some timing clearance for getting into the new output mode.

Jeff

Jeff,

You are right. I thought the OUT bit drives the output pin and can be set/clear by the OUTMOD hardware. In that case, there would be no glitch. But my assumption was incorrect. Why didn't TI do it that way?

--OCY

I'm getting a better understanding now, thanks Jeff and OCY.

It sounds like the the safe method should really be applied to all timer modes (stop, up, cont, up/down) and not just up/down as the user guide had me a bit uncertain about at first.

Yes, as you suspected Jeff, my application doesn't tolerate the visit to Mode 7 because I can't have a rare TACCR0 match sneaking in before the intended Mode 4 output code executes.  However, I'm still not sure this is the only cause for the glitch I'm experiencing because it varies board to board (on approx 1 of 4 boards tested on). 

The inconsistency board to board makes me think it's partly manufacturing related.  A board experiencing the glitch will repeatably show it.  I also tested over supply voltage (3 to 4V) and temperature (20 to 85C) too, thinking maybe some parasitics may be putting certain parts on a marginal edge, but I had no observable changes.  I haven't been able to get a good board to turn bad or bad to turn good.

Right now, it seems my workaround options are to either: (a) adjust TACCR0 so it doesn't fall on any period of activity with TACCTL1, (b) chose a different transition mode independent of TACCR0, or (c) change to unused TimerB0 in my application. 

old_cow_yellow said:

Why didn't TI do it that way?

Not sure.  But I sometimes set an output manually using the OUT bit to prepare for a complex timer-driven sequence.  Then I "hand off" control of the pin to the OUTMOD hardware confident that I have staged it for a seemless hand-off -- in other words, changing OUTMOD from 0 to something else will not change the output pin.

That kind of control all but requires that the OUT bit have the ability to control the flip-flop in the OUTMOD hardware instead of the other way around.

Jeff

Payton said:

It sounds like the the safe method should really be applied to all timer modes (stop, up, cont, up/down) and not just up/down as the user guide had me a bit uncertain about at first.

Yes I agree.

Payton said:

The inconsistency board to board ...

What clock is driving timer A?  Is it the DCO?  The DCO runs at different frequencies unit-to-unit.  Good idea trying temperature variation.

Payton said:

or (c) change to unused TimerB0 in my application. 

I like this idea.  I am assuming you would use the triggered latch loading built into Timer B.  That would save you some algorithm/software effort trying to time your mode changes better.

Jeff

Payton said:

What clock is driving timer A?  Is it the DCO?

TimerA runs from ACLK = LFXT1CLK = 32768Hz crystal.  MCLK = DCO (7,7) = ~1.5MHz.  Maybe the DCO difference unit-to-unit is significant enough where temperature dependence isn't (or at least not marginal enough on the units I had tested).  The DCO I'm running isn't any of the calibrated DCO settings.

Payton said:

..assuming you would use the triggered latch loading built into Timer B.  Is it the DCO?

Thanks for the suggestion. I'm familiarizing myself with it right now.

-Payton

On second thought I'm not sure Timer B will help.  I was assuming more than I really know about your application.

Anyway, it sounds like you'll navigate your way around this one somehow.  Let us know if you need more help.

Jeff

Jeff,

A little detour. I tried a test with a MSP430G2xx in an attempt to see the glitch. I found none.

void main(void)
{
  WDTCTL = WDTPW|WDTHOLD;
  P1DIR = BIT6;
  P1SEL = BIT6;
  TACCR0 = 100;
  TACCR1 = 200;             // note that TACCR1 > TACCR0
  TACCTL1 = OUTMOD_0|OUT;   // Load from OUT  
  TACTL = TASSEL_2|MC_1;
 
  for(;;)
  {
    TACCTL1 = OUTMOD_1|OUT; // Toggle
    TACCTL1 = OUTMOD_2|OUT; // Toggle/Reset
  }

}

P1.6 showed an initial 3.3V pulse of about 4.5 usec as expected. Absolutely flat 0V there after (even at 10 nsec/cm on the scope).

Any suggestions to show the glitch?

-- OCY

Your code matches my understanding of the problem.  (And it's in C no less!  What's happening to you OCY?)

Perhaps there's a synchronization issue.  Maybe if the devices (Timer, CPU) were clocked asynchronously to each other.  One on 32kHz, one on 1MHz.

Perhaps there is a setup/hold time issue during the write.  Maybe a fast MCLK would make a difference or perhaps other supply voltages or ambient temperatures.

Jeff

Jeff,

Thank for checking my sanity. I will put it off for now or keep it in the back burner.

I did it in c, but I checked the assembly code it generated ;-) I was curious if the compiler would sneak in the safe method OUTMOD_7 between the lines. I am happily surprised that it did not. It would have mess up the waveform entirely. At least in this case, the cure is much worse than the disease. 

-- OCY