MSP430G2231: SLAA340 - Calibrating the VLO with DCO

Hi Sunset,

The timer starts counting at this line of code:

            mov.w   #TASSEL_2+MC_2+TACLR, &TACTL; SMCLK, cont-mode, clear

After that line is executed, there are several other operations performed, including setting ACLK = VLO, clearing BCSCTL2, dividing ACLK = VLO/8, and clearing the capture flag. During this time the TimerA counter is ticking and at the first CCIFG capture, I suspect that TAR is ~0xFD43. Then when the second capture occurs, TAR has overflowed and is ~0x64. I hope this helps clear things up. 

Best regards, 
Caleb Overbay

Hello Caleb,

thanks for jumping in.

My problem is actually between the following code:

    bic.w   #CCIFG,       &TACCTLX  ; Clear capture flag
edge_one    bit.w   #CCIFG,       &TACCTLX  ; Test capture flag to skip first signal
            jz      edge_one
            bic.w   #CCIFG,       &TACCTLX  ; Clear capture flag
edge_two    bit.w   #CCIFG,       &TACCTLX  ; Test capture flag to skip second signal
            jz      edge_two                ;
            mov.w   &TACCRX,      r13       ; save hardware captured value
            bic.w   #CCIFG,       &TACCTLX  ; Clear capture flag
edge_three  bit.w   #CCIFG,       &TACCTLX  ; Test capture flag to capture a good clock
            jz      edge_three              ;
            bic.w   #MC_3,        &TACTL    ; stop timer
            mov.w   &TACCRX,      r12

on the first edge I clear TACCTLX. so on the second edge, the counter should be around 800 counts and not 100 as I measure.

On the third it should + 800 additional counts.

So I would have expected something around 800 and 1600 instead of 100 and 900 counts.

this is what I cannot understand.

Thanks,

SunSet

Hi Sunset,

Sunset said:

on the first edge I clear TACCTLX. so on the second edge, the counter should be around 800 counts and not 100 as I measure.

You're only clearing the capture compare interrupt flag (CCIFG) and not the counter register, TA0R. So the timer is still counting and doesn't restart at 0. 

Best regards, 
Caleb Overbay

good point.

maybe another thing.

By starting the timer I'm assuming that the TACCR0 start from 0.

mov.w   #TASSEL_2+MC_2+TACLR, &TACTL; SMCLK, cont-mode, clear

the counter should not get up to ~800 on the second edge?

Thanks,

SunSet

Hi Sunset,

Setting the TACLR bit in the TACTL register clears the timer's count register, TAR. When a capture is triggered by ACLK, the value of TAR is stored into the TACCR0 register. TACCR0 does not count, it only stores the value of the count register, TAR.

So I'm not sure what you're asking with the above question. I still think the edge_two trigger is 100 because TAR overflowed between the edge_one and edge_two triggers.

Best regards,
Caleb Overbay

Hello Caleb,

is ok that the TACCR0 is not counting directly but it store the count from the TAR. My mistake in mixing it up. I'm thinking in counts without considering that we are in capture mode.

But if the TAR, after the routine initialization called within the SLAA340 gets a reset every time and than start the count, on the first edge it may have any value between few cycle and 800, but then on the second edge must have necessarily something around 800 additional cycles, since the TAR continue counting.

There are just few instructions executed and the capture trigger is the edge of the ACLK that is 800 cycles away from each other.
from any capture to another I would expect 800 counts (out of the TAR).

A TAR overflow should not be reached during the calibration since there are only few instructions and worst case 3 time 800 counts (considering 12KHz VLO), so 100 counts are little bit too less for the second capture.

Thanks,

SunSet

Hi Sunset,

That's a very good point. There aren't that many instructions between the timer starting and the first edge trigger. I would expect the second trigger to capture a value higher than 100. I tested this out on a G2553 and I'm seeing the following:

• First Edge: 0x89 (137 decimal)
• Second Edge: 0x304 (772 decimal)
• Third Edge: 0x582 (1410 decimal)

These numbers are more in line with what I would expect from the way the code is structured. So I'm not observing the same behavior that you are. Can you see what the value of the CCR0 register is during the first edge capture when you run the code?

Best regards, 
Caleb Overbay

Hello Celeb,

thanks for testing and confirm the measured.

SunSet

This thread is being handled offline.

Best regards,
Caleb Overbay