Using CCR0 & CCR1 for Timer A0 using MSP430G2553

The paste came out weird for my code.  Please let me know if clarification is needed.

Hi,

Jonathan Hunter1

TA0CCTL0 = CCIE;

TA0CCTL1 = CCIE;

TA0CCR0 = update_delay;

TA0CCR1 = page_write;

TA0CTL = TASSEL_1 + MC_1 + TAIE;

// ACLCK, 1/8 DIVIDER, upmode to TCCR0 value

You are basically using the Up mode which means that the timer counter TA0R will count up to TA0CCR0 then resets back to zero. Which value are using at ACLK?

Jonathan Hunter1

#define update_delay 2620//1310 //0

#define page_write 3000 //5

However you are setting the value of TA0CCR1 with a value which is greater than the TA0CCR0 itself (means TA0R will never reach the TA0CCR1).

I would suggest the following:

#define ACLK_FREQ_INPUT_HZ       (32768UL)  // assume 32 kHz input at ACLK

#define CCR0_PERIOD_MS           (200UL)  // 200 ms

#define CCR1_PERIOD_MS           (5UL)  // 5ms

#define CCR0_VALUE               ((unsigned int) (CCR0_PERIOD_MS*ACLK_FREQ_INPUT/1000UL))

#define CCR1_VALUE               ((unsigned int) (CCR1_PERIOD_MS*ACLK_FREQ_INPUT/1000UL))

and use the CCR0_VALUE and CCR1_VALUE above as your input to the TA0CCR0/1 registers.

Hello Leo,

Thanks for replying!

I agree that I need to be more precise with my CCR0 and CCR1 values, but no matter what value I make CCR1 the timing does not seem to change for executing that section of code.  As I understand it with a CCR1 = 3000, that interrupt code should be occurring even less frequently than my CCR0 interrupt code.  For some reason, my code is triggering constantly and the only time CCR1 is not running is when CCR0 triggers.

I think it points to a configuration error, but I don't know what.  I also reference ADC10, SPI ports for B0, and UART A0 pins.  I will use all the rest of the pins for GPIOs to control other components.  Is there a conflict with using TA0CCR1 with these configurations?

Here are my CLK settings that I forgot to add:

    BCSCTL2 = SELM_0 + DIVM_0 + DIVS_0;

if (CALBC1_1MHZ != 0xFF) {

/* Follow recommended flow. First, clear all DCOx and MODx bits. Then

         * apply new RSELx values. Finally, apply new DCOx and MODx bit values.

         */

        DCOCTL = 0x00;

        BCSCTL1 = CALBC1_1MHZ;     

/* Set DCO to 1MHz */

        DCOCTL = CALDCO_1MHZ;

    }

    BCSCTL1 |= XT2OFF + DIVA_0;

    BCSCTL3 = XT2S_0 + LFXT1S_2 + XCAP_1;

CCR0 generates an unique interrupt.  Its interrupt flag is automatically cleared when that interrupt is acknowledged.

CCR1 shares its interrupt with other causes. Thus its interrupt flag is not automatically cleared. The ISR must clear it, otherwise it will cause another interrupt the moment your ISR finishes. And that is what you experienced.  Add a CCTL1 &= ~CCIFG; statement in its ISR.

Hi,

old_cow_yellow

CCR1 shares its interrupt with other causes. Thus its interrupt flag is not automatically cleared. The ISR must clear it, otherwise it will cause another interrupt the moment your ISR finishes. And that is what you experienced.  Add a CCTL1 &= ~CCIFG; statement in its ISR.

OCY was right. referring to the User's Guide document, the best way to do this is by reading out the TAIV register:

12.2.6.2 TAIV, Interrupt Vector Generator
The TACCR1 CCIFG, TACCR2 CCIFG, and TAIFG flags are prioritized and combined to source a single interrupt vector. The interrupt vector register TAIV is used to determine which flag requested an interrupt. The highest priority enabled interrupt generates a number in the TAIV register (see register description).
This number can be evaluated or added to the program counter to automatically enter the appropriate software routine. Disabled Timer_A interrupts do not affect the TAIV value.

Any access, read or write, of the TAIV register automatically resets the highest pending interrupt flag. If another interrupt flag is set, another interrupt is immediately generated after servicing the initial interrupt. For example, if the TACCR1 and TACCR2 CCIFG flags are set when the interrupt service routine accesses the TAIV register, TACCR1 CCIFG is reset automatically. After the RETI instruction of the interrupt service routine is executed, the TACCR2 CCIFG flag will generate another interrupt. 

Jonathan Hunter1

As I understand it with a CCR1 = 3000, that interrupt code should be occurring even less frequently than my CCR0 interrupt code.

No. In cont mode, wher ethe tiemr counts fromm 0 to 65535 and begins with 0, all CCR units trigger once per round, just at different moments.
In up mode, which you use,the timer counts from 0 to CCR0 and then begins with 0 again. But the interrupts trigger when the timer counts to the stored value. Hence 'compare mode', in opposition to 'capture mode' for the CCRs (Capture-Compare-Registers). SO if the CCR1 value is higher than CCR0 value, the timer never will count that high and the interrupt is never triggered at all.
If it is less than CCR0, it will trigger exactly as often (once per tiemr cycle), only the moment during the cycle differs with the value.

BTW: if you want the cycle to be 1000 timer ticks, you'll have to write 999 into CCR0, since '0' is a tick as well.

The reason why you got this amount of CCR1 interrupts was already explained by the others. And since CCR1 and CCR0 were 0 before you wrote the values that effectively prohibited any CCR1 interrupt, there was already one interrutp pending which you never cleared.

Thanks for the replies!

So I tried clearing the interrupt after it triggered using (because the CCR1 interrupt is not clearing):

TA0CCTL1 &= ~CCIFG;

I put this line at the end of my USCIA0RX_ISR() function call.  It had no effect on the how the code operated.

 

I then tried reading the TA0IV register with:

lnum2 = TA0IV;

This caused my code to go back to the main function each time this line was reached.  The code was planned to go through the main function once to initialize variables and then remain in the infinite loop that contained sleep and interrupt enable.  The program would only run when CCR0 and CCR1 interrupts occur.

 

I see what you are saying Jens about the CCR1 must be smaller than CCR0 otherwise the code will never trigger.  I suppose that is why I am confused because with the timer in up configuration, I should never see my SPI commands rather than always seeing my SPI commands. So I suppose this all points back to I still am not clearing interrupt correctly or my configuration is not allowing me to do so.

Do you see anything else that could be causing this?

 

 

Jonathan Hunter1

So I tried clearing the interrupt after it triggered using (because the CCR1 interrupt is not clearing):
TA0CCTL1 &= ~CCIFG;
I put this line at the end of my USCIA0RX_ISR() function call.  It had no effect on the how the code operated.

I wouldn't expect it to work :)
You must clear the IFG bit inside the ISR it was triggering. So inside the timer ISR. If you leave the timer ISR before it is cleared, you'll go into the timer ISR again right away, and never execute any ISR with a lower interrupt priority.

 

I see what you are saying.  I corrected Timer_A1 ISR function call.

#pragma vector = TIMER0_A1_VECTOR

__interrupt void TIMER_A1(void)

{

    TA0CCTL1 &= ~CCIFG;

    USCIA0RX_ISR();

}

#pragma vector = TIMER0_A0_VECTOR

__interrupt void TIMER_A0(void)

{

TIMER_ISR();

}

This change does not seem to change how the program runs. 

The only thing that seems to change how the code executes is reading/writing from TA0IV, but that just causes the program to reset and start from the beginning of main again.

Here is my current configuration:

In the main() function:

#define update_delay 3000

#define page_write 200

 

TA0CCR0 = update_delay;

TA0CCR1 = page_write;

TA0CTL = TASSEL_1 + MC_1 + TAIE;   

TA0CCTL0 |= CCIE;

TA0CCTL1 |= CCIE;

 

At the end of USCIA0RX_ISR():

TA0CCR1 += page_write;

 

In my CCR0 interrrupt function:

void TIMER_ISR(void)

{

int x;

   adc2asciihex(device_id);

    adc2asciihex(lnum);

adc2asciihex(charge_cnt);

    adc2asciihex(bytes_wr);

  

while (!(IFG2 & UCA0TXIFG));              // USCI_A0 TX buffer ready?

    UCA0TXBUF = '\r';                         // Send next value

   

while (!(IFG2 & UCA0TXIFG));              // USCI_A0 TX buffer ready?

    UCA0TXBUF = '\n';                         // Send next value

    TA0CCR1 = page_write;

    TA0CCR0 = update_delay;

  }

 

So my understanding, the code should have timerA0 count up to CCR0 = 3000 and reset. Since CCR1 += 200, then every 200 cycles it would run the SPI commands until CCR0 triggers and the timer is reset to 0.  The Timer_ISR() function that triggers at CCR0 interrupt shoud reset CCR1 value to 200.  I know that CCR0 works because I can increase that value and watch teh updates happen at a slower rate.

Is there something else that I need to do before 'TA0CCTL1 &= ~CCIFG;' that would allow me to clear the interrupt? Would it help to zip up my project to view?

Is there any further advice?  Does anyone know why reading from TA0IV would cause the entire program to reset?

Could someone point me to code that runs 2 interrupt routines in a similar setup that I am trying to acheive?

Jonathan,

could you share your code? i might try to test it myself. Looking the code above gives a little headache :)

Thanks Leo!

This code is supposed to work with a development board but you can still see the issue with out that board.

I included 2 images from a logic analyzer to show what I am seeing.

In MSP430_1.jpg, you will see a lot of activity with periods (every ~200ms) of "no activity" for the SPI lines (this is the UART update which you can see on the terminal as well).  That 200ms period will change if you modify the CCR0 value in the code.

In MSP430_2.jpg, you see the SPI commands which are 32 bytes of written data and a status register update.

In the terminal window, you will see the 4 values printed on each line.  The main value to be concerned about is the 4th value (number of bytes written in hex)  which should increment a certain rate depending on CCR1, but it does not.  As you can see from the logic analyzer, the rate is as fast as possible.

Please let me know if need any other information.

forgot the link...

5226.msp430g2xx3_usci_spi_master.zip