Is timer A considered synchronised to CPU even when sourced from SMCLK / 2?

Patrik Dahlstrom

Hello,

The short version:

Is timer A considered synchronised to CPU if it is sourced from SMCLK with the input divider set to 2, or does it need to be exactly synchronised to the CPU?

The long version:

I'm implementing a fix for the DCO drift errata bug present in MSP430 and CC430. Here is some pseudo code of what I do:

bool dcoStable = false;

// Setup timer A0 in continuous mode, SMCLK/2
timerSetup();

while (true) {
    disableInterrupts();
    if (dcoStable) {
        dcoStable = false;
        sleepAndEnableInterrupts();
        TA0CCR4 = TA0R + DCO_DRIFT_FIX_TICKS;
        TA0CTL4 &= ~CCIFG;
        TA0CTL4 |= CCIE;
    } else {
        enableInterrupts();
    }
}

void TIMER0_A1_VECTOR(void)
{
    dcoStable = true;
    TA0CTL4 &= ~(CCIE | CCIFG);
}

I'm worried that my read from TA0R might be unpredictable. Unfortunately I can only use 1 CCR register (all other are already occupied) and I don't want to mess up the timing by stopping timer A.

To put it differently:

Can I safely read TA0R if timer A is sourced from SMCLK/2?

Will I have a problem with propagation delays in the timer divider or counter?

over 9 years ago

0 Jens-Michael Gross over 9 years ago

Guru 227245 points

It's not a question of consideration but of signal timing. :)

If MCLK and SMCLK are sourced from the same oscillator, then both have the clock edges at the same time (only that some of them are missing, if there is a divider). So they can be considered synchronized.

Problems may arise when you have, e.g. MCLK running on DCO/8 while the timer runs on SMCLK=DCO with a prescaler TAIDEX_7 (or 5 or 3). Then due to the oddity of the dividers, it might be that the timer counts right at the moment the CPU wants to read. But likely (I didn’t calculate) the time between the clock edges will still be either zero or larger than the critical time span. And as long as all dividers are binary steps, they are for sure. Also, I think this would require to run DCO far above the allowed limit for SMCLK (even if SMCLK/7 then would be inside the specs again)

The read problem will only happen if the timer counting operation and the cpu register read operation happen right at the same moment, which will only happen if the CPU clock edge and the timer clock edge differ by exactly a certain amount (few ns). Which will of course be possible if MCLK and SMCLK run form different sources.

0 Patrik Dahlstrom over 9 years ago in reply to Jens-Michael Gross

Prodigy 30 points

Jens-Michael Gross said:

The read problem will only happen if the timer counting operation and the cpu register read operation happen right at the same moment, which will only happen if the CPU clock edge and the timer clock edge differ by exactly a certain amount (few ns). Which will of course be possible if MCLK and SMCLK run form different sources.

In my application, the clocks are setup like this:

MCLK = DCOCLK
SMCLK = DCOCLK
TA0 clock = SMCLK/2

Will this mean that the counting operation and the cpu register read operation could happen right at the same time?

I am worried about propagation delays in the TA0 divider and timer latches.

0 Jens-Michael Gross over 9 years ago in reply to Patrik Dahlstrom

Guru 227245 points

In this case, things are simple. The MSP will put the TAR address on the address bus at the rising edge of MCLK and pull the value at the falling edge. TAR counts on the rising edge of every second MCLK cycle, so the moment TAR is counting and the moment TAR is read are always 1/2 MCLK cycle apart. No risk of a wrong reading.
The glitch can only happen when the clock edge that makes TAR counting happens immediately before the CPU reads the value. Then it might read the incremented lower bits but the not yet incremented higher bits while the increment is still propagating through the TAR register. It’s a matter of nanoseconds. However, if both clocks are independent (e.g. from two different crystals), this may (will) happen sooner or later.

0 Patrik Dahlstrom over 9 years ago in reply to Jens-Michael Gross

Prodigy 30 points

Then it works as I suspected. Now I have a confirmation.

Thank you for your help!

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

Is timer A considered synchronised to CPU even when sourced from SMCLK / 2?