• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 77 subscribers
  • Views 5917 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.

MSP430F1121A TimerA

MKLI
Prodigy 50 points

I'm using TimerA in up/down count mode to create a PWM signal on I/O pin P1-2.  The timer uses an external 32K clock and I use CCR0 and CCR1 to vary the pulse width (Output Mode 6).  For the most part this works fine and as expected but occasionally I see a "glitch" and get an unexpected result.  I start and stop the timer before each pulse train sent out the port as follows:

------

Output signal driven low

Timer is cleared and started at 0

Timer counts up to CCR1 threshold and Output toggles high

Timer counts up to CCR0 threshold but Output is already high so no change expected.

Timer counts down to CCR1 threshold and Output toggles low

Timer counts down to 0 and an overflow interrupt (TAIFG) is generated.

The interrupt reloads the CCR0/CCR1 regs with new values.

The timer interrupt occurs about 50 times then stops the timer (producing 50 sequential PWM signals).   At some point later the entire sequence will begin again triggered by an external event.

-----

As I mentioned above, everything works as described but once in a while I see that as the timer first starts for the very first of the 50  PWM cycles, the output pin toggles high immediately, toggles low at CCR1 count and toggles high at CCR0.  My supposition is that if the timer starts at the low portion of the incoming 32KHz clock it will count up at the first low to high transition and every thing is hunky-dory but if the timer starts at the high portion of the incoming 32KHz clock it will still have TAR=0 after the first high to low transition and this will cause the timer to set the output pin high.  To test this supposition I modified the initial timer startup such that I set TAR=1 after setting the CLR bit and before starting. This seems to have cured the occasional "high start" symptom described above.

I've not seen where this behavior is described in the documentation so I'm coming the forum to see if my supposition is a known function of the timer...... or perhaps I'm masking  a different problem by changing the start count to TAR=1 before starting.

--Mike

 

 

 

  • 0
    TI__Guru 63205 points

    Something that is not clear to me is how you are using the 32KHz clock.  Is this the "external" trigger, or the clock to the TimerA (ie. selected by TASSELx) depicted in Figure 11-1 of the MSP430x1xx Family User's Guide (SLAU049).

    If it is the clock, I'm not sure I quite understand your point about the low portion and high portion.  Would you please elaborate?  Thanks.

  • 0 in reply to BrandonAzbell
    Prodigy 50 points

    The 32KHz clock is the selected (TASSEL0) Timer clock ( TACLK ) via an external crystal.  Since I'm not sure of the phase of the 32KHz clock when the program starts the timer via the command ( after previously stopping and clearing ); 

    TACTL = MC_3 + TASSEL0 + TACLR + TAIE; 

    my guess is that I'm seeing differing results depending on whether the 32KHz clock is high or low at that moment. 

    Especially since changing the startup to ( after previously stopping and clearing ):

    TAR = 1;

    TACTL = MC_3 + TASSEL0 + TAIE;

    seems to have cured the problem completely.   The diagram of Figure 10-23 in SLAU049 is unclear to me whether to expect the OUTx Signal to go high or stay low in Output mode 6 when TAR = 0 and the timer is just starting up.

    --Mike

  • 0 in reply to MKLI
    TI__Guru 63205 points

    MKLI said:

    The diagram of Figure 10-23 in SLAU049 is unclear to me whether to expect the OUTx Signal to go high or stay low in Output mode 6 when TAR = 0 and the timer is just starting up.

    I don't see a Figure 10-23 in SLAU049.  Would you please clarify?

    The page 11-9 in the Timer_A Section discusses the Up/Down Mode and describes when the TACCR0 CCIFG flag and TAIFG flags are set.  For TACCR0 CCIFG, it is set when the timer counts from TACCR0-1 to TACCR0.  For TAIFG, it is set when the timer completes counting down from 0001h to 0000h.  I believe it is under these transitions which enable the condition to set the flags.

  • 0 in reply to BrandonAzbell
    Prodigy 50 points

    It appears that I'm using an earlier version of the SLAU049 doc.  The figure I referred to was titled "Output Control Block" but it doesn't seem to have survived to the later revision of your link.

    As it turns out there was a code path that allowed the timer to recycle intermittently without stopping which caused my symptom.  I was indeed masking a deeper problem by setting TAR=1 and have now resolved the problem with a satisfactory fix. 

    Thanks for your help!

    --Mike

**Attention** This is a public forum