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.

When is TIMER_A asynchronous to the CPU?



This question is to sanity check how I'm reading the TIMER_A section in the MSP430i2xx Family User''s Guide.

The section I'm talking about is 9.2.1 16-Bit Timer Counter (page 96 of slau335). The second part of the section is a note on modifying Timer_A registers and reading from TAxR:

NOTE: Modifying Timer_A registers
It is recommended to stop the timer before modifying its operation (with exception of the
interrupt enable, interrupt flag, and TACLR) to avoid errant operating conditions.

When the timer clock is asynchronous to the CPU clock, any read from TAxR should occur
while the timer is not operating or the results may be unpredictable. Alternatively, the timer
may be read multiple times while operating, and a majority vote taken in software to
determine the correct reading. Any write to TAxR takes effect immediately.

My question is about he phrase I colored blue. I think the Timer_A clock is asynchronous only when the clock source is external from TAxCLK. I think it's synchronous when the clock source is ACLK or SMCLK.

Is this a correct interpretation? Or is additional configuration required to make ACLK or SMCLK synchronous?

Leo

  • Hi Leo!

    When the timer is sourced from another clock source than the CPU. For example the CPU runs from SMCLK that comes from the internal DCO and the timer is sourced from ACLK that is an external watch crystal.

    Dennis
  • Dennis Eichmann said:
    When the timer is sourced from another clock source than the CPU. For example the CPU runs from SMCLK that comes from the internal DCO and the timer is sourced from ACLK that is an external watch crystal.

    That's possible on the msp430g- or msp430f-family chips, but the msp430i2 has a fixed DCO frequency and a fixed ACLK, which makes things a bit less clear.

    The msp430i2 32kHz ACLK is derived from the DCO, as shown on page 120 of the Family User's Guide. The clock system doesn't appear to include any XTn oscillators either. In this case I think Leo might be right to say that the Timer_A clock is asynchronous to MCLK only when the clock source is external from TAxCLK.

  • The CPU is clocked by MCLK. The Timer is clocked by either SMCLK or ACLK as selected by its control register.

    When MCLK is identical to SMCLK/ACLK (as selected), the CPU and the Timer are synchronous. When MCLK is derive from a different clock source as compared with that of the SMCLM/ACLK (as selected), the CPU and the Timer are asynchronous.

    When MCLK is derive from the same clock as that of the SMCLM/ACLK (as selected) but divided by a different factor, the CPU and the Timer may still be considered as synchronous. But I am not 100% sure about this.
  • It looks to me that the ACLK is always the DCO /512 and MCLK is always DCO /2 - /16
    But I think the 32K = 32'000 and not 32'768 people are used to with crystal?, not a big deal just make sure the time count is correct. 

  • Robert Cowsill said:
    That's possible on the msp430g- or msp430f-family chips, but the msp430i2 has a fixed DCO frequency and a fixed ACLK, which makes things a bit less clear.

    OK, thanks for the info! Did not work with an "i" device yet and did not look into the documentation before writing the answer.

    old_cow_yellow said:
    When MCLK is derive from the same clock as that of the SMCLM/ACLK (as selected) but divided by a different factor, the CPU and the Timer may still be considered as synchronous. But I am not 100% sure about this.

    I was thinking about the same question. The higher the divider the more delay you will get, but maybe this delay is negligible?

  • Thank you Dennis, old_yellow_cow, and Tony. My question seems thornier than I anticipated. Is a delayed signal technically synchronous or not? I was thinking of running a an experiment of sorts -- run a loop overnight that samples the TAR continuously and logs anomalies. But I'm not sure whether it would prove anything, for instance, if I didn't get any. I'm only using the one board, possibly other calibrations or crystals could effect the outcome. I'll have to study several sections in the Family Guide and think about it.
  • With ALCK and MCLK having exact same falling and rising edges and if counter change on falling edge (or the clock is inverted 180deg out of phase?)
    and mcu always executing on rising edge there will never be a delay introduced somewhere big enough to skew with the result.

  • Really! Well, that saves me considerable work and head-scratching. Thank you, Tony! Did you find a timing diagram that shows that? I'm not comfortable enough with the block diagram you showed (Figure 4.1) to infer whether or not there are delays in divided-down signals.

**Attention** This is a public forum