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.

Query on F2012 Timer_A2 and OUTMODe settings


Is anyone out there familiar with the finer points of the Timer_A2
module? I've run into one of those areas where what I want to do is
in an area of the documentation that is subject to interpretation,
and I'd like to get a definite answer if possible.

According to section 12.2.5 of TI's "MSP430x2xx Microprocessor
Family" document (slau144e.pdf), the following pseudocode
immediately forces the chosen output pin LOW:

  // Timer_A is running in Continuous Mode

  OUT = 0b0
  OUTMOD = 0b000

The next bit of code, as I interpret the manual, has no immediate
effect on the output pin, but at some _later_ time -- specifically,
the next time the appropriate CCR has a compare match with the TAR
-- it will force the output HIGH:

  OUTMOD = 0x001

Here's my question: what happens if I try using both OUTMODe
settings in quick succession?

  OUT = 0b0
  OUTMOD = 0b000
  OUTMOD = 0x001

Does the output pin go immediately to LOW, then, at the next compare
match (and without any other intervention), switch HIGH (I hope)?

Is switching to a non-zero OUTputMODe _guaranteed_ to leave the
_current_ output pin level unchanged until there's a compare match
against TAR?

Figure 12-1, the Timer_A Block Diagram, seems to suggest this, but
I'm not sure I'm reading it correctly.

Figure 12-13 shows how the various OUTMOD settings work, but
OUTMOD=0 isn't shown, nor is the effect of changing OUTMOD in
mid-stream.

Any suggestions or hints that will help me get this clear in my mind
will be appreciated.


Frank McKenney

--
   "...each new generation born is in effect an invasion of
    civilization by little barbarians, who must be civilized
    before it is too late."  -- Thomas Sowell
--

  • I think your interpretation of the implementation of the TimerA in regards to the treatment of the output when operating in different OUTMODs is correct.
    At this point, I don't have a definite answer, as only actually watching the effects on a scope will provide clarity.  I don't have one with me right now.

    Frank McKenney said:

    According to section 12.2.5 of TI's "MSP430x2xx Microprocessor
    Family" document (slau144e.pdf), the following pseudocode
    immediately forces the chosen output pin LOW:

      OUT = 0b0
      OUTMOD = 0b000

    The next bit of code, as I interpret the manual, has no immediate
    effect on the output pin, but at some _later_ time -- specifically,
    the next time the appropriate CCR has a compare match with the TAR
    -- it will force the output HIGH:

      OUTMOD = 0x001

    That is my understanding as well based on the circuit diagram depicted in Figure 12-1.  Using OUTMODx=000b enables the asynchronous set and reset paths to the D flip flop driving the output.

     

    Frank McKenney said:

    Here's my question: what happens if I try using both OUTMODe
    settings in quick succession?

      OUT = 0b0
      OUTMOD = 0b000
      OUTMOD = 0x001

    Does the output pin go immediately to LOW, then, at the next compare
    match (and without any other intervention), switch HIGH (I hope)?

    Is switching to a non-zero OUTputMODe _guaranteed_ to leave the
    _current_ output pin level unchanged until there's a compare match
    against TAR?

    Figure 12-1, the Timer_A Block Diagram, seems to suggest this, but
    I'm not sure I'm reading it correctly.

    Given the D flip flop is directly connected to the output, I would say yes, the above is a correct interpretation.

    If the multiplexer controlled by OUTMODx was on the Q output of the flip flop, you would run a chance of glitches or the output going high.  This isn't the case.

     

    Frank McKenney said:

    Figure 12-13 shows how the various OUTMOD settings work, but
    OUTMOD=0 isn't shown, nor is the effect of changing OUTMOD in
    mid-stream.

    My view is that Figure 12-13 is illustrating the effects of the output based on the workings of the timer as it relates to the TACCRx value.  OUTMODx=000b does not depend at all on the rest of the timer functionality and only on the value of OUT.

     

  • Brandon,

    Thank you for taking the time to respond.

    BrandonAzbell said:
    I think your interpretation of the implementation of the TimerA in regards to the treatment of the output when operating in different OUTMODs is correct.

    My skill at reading the fine details of logic diagrams is a little rusty, so your comments are

    appreciated. <grin!>

     

    BrandonAzbell said:
    At this point, I don't have a definite answer, as only actually watching the effects on a scope will provide clarity.  I don't have one with me right now.

    Thanks for the suggestion. I picked up a Tek465B some years ago at FrostFest, a local amateur radio

    event, and it has been enormously useful. True, it sits unused for months at a time, but it can show me

    things (like timing) that I couldn't find out otherwise.

    BrandonAzbell said:
    That is my understanding as well based on the circuit diagram depicted in Figure 12-1.  Using OUTMODx=000b enables the asynchronous set and reset paths to the D flip flop driving the output.

    Yes, well... my instructions were out of order, A Bad Thing even in pseudocode. The correct sequence

    should be (for anyone else following this thread):

      OUTMOD = 0b000       // "No, no, no. Pillage, _then_ burn!"

      OUT = 0b0

    And this sequence also needs correction:

      OUTMOD = 0b000
      OUT = 0b0
      OUTMOD = 0x001

    BrandonAzbell said:
    Given the D flip flop is directly connected to the output, I would say yes, the above is a correct interpretation.

    If the multiplexer controlled by OUTMODx was on the Q output of the flip flop, you would run a chance of glitches or the output going high.  This isn't the case.

    Thank you for reminding me to double-check for glitches. I've been too caught up in "making it start to

    work" to think about the finer points of timing.

    The final good news is that code based on this appears to be working. <grin!>

     

**Attention** This is a public forum