CCR0 Interrupt MSP430F5338

I recommend following materials to start with:

• http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/18546.aspx
• http://e2e.ti.com/group/universityprogram/educators/w/wiki/2043.msp430-teaching-rom.aspx

You can download MSP430Ware and find there code examples for devices similar to yours. 

I do not see global interrupt enable in your code.

Regards,
Maciej 

Hello,

 the global interrupt gets enabled in the main routine. The example is from the MSP430Ware 

Still works for MSP430F5419 but if i use the MSP430F5338 i have to change it from:

#pragma vector=TIMER0_A0_VECTOR
__interrupt void TIMER0_A0_ISR(void) 

to

#pragma vector=TIMER0_A1_VECTOR
__interrupt void TIMER0_A1_ISR(void)

I'm also using the right header file....

This is strange. It almost looks like there is a mixup in the defines. Maybe the vector numbers have been twisted in the header files? But then, why didn't anybody notice it before?

Which compiler/version do you use?

IAR MSP430 IDE 5.51.2

Today i tested it with TA1 and it worked correctly. The ISR vectors are correct!

Daniel Hartl said:

The ISR vectors are correct!

If the vectors are correctly defined, then an interrupt by TA0CCR0 goes to TIMER0_A0_VECTOR.
Also, if TIMER0_A1_VECTOR is called, thsi means that there is one of the IFG bits stills et, and since you do nto reset it in your ISR, this would lead to an endless loop of ISR calls after this first itnerrupt.

So either there is a problem with the defines, or there is a hardware problem in thsi MSP and a problem with what you reported to observe. THe first option is a littel bit more likely :)

But since I don't use CCS, I cannot check. Perhaps someone else can.

It seems that the ISR is for ADC12 Conversion Result Interrupt??  

#pragma vector=TIMER0_A0_VECTOR

__interrupt void TIMER0_A0_ISR(void)
{
switch(__even_in_range(ADC12IV,34))
{
case 0: break; // Vector 0: No interrupt
case 2: break; // Vector 2: ADC overflow
case 4: break; // Vector 4: ADC timing overflow
case 6: break; // Vector 6: ADC12IFG0
case 8: // Vector 8: ADC12IFG1
case 10: // Vector 10: ADC12IFG2
case 12: // Vector 12: ADC12IFG3
SETPORTPIN(LED_PORT,STATUS_LED);
F_Voltage = ADC12MEM0; // Move A0 results, IFG is cleared
F_Current= ADC12MEM1; // Move A1 results, IFG is cleared
case 14: break; // Vector 14: ADC12IFG4
case 16: break; // Vector 16: ADC12IFG5
case 18: break; // Vector 18: ADC12IFG6
case 20: break; // Vector 20: ADC12IFG7
case 22: break; // Vector 22: ADC12IFG8
case 24: break; // Vector 24: ADC12IFG9
case 26: break; // Vector 26: ADC12IFG10
case 28: break; // Vector 28: ADC12IFG11
case 30: break; // Vector 30: ADC12IFG12
case 32: break; // Vector 32: ADC12IFG13
case 34: break; // Vector 34: ADC12IFG14
default: break;
}
}

#pragma vector=ADC12_VECTOR
__interrupt void ADC12ISR (void)
{...

}

And I get the following warning:

Warning[w52]: More than one definition for the byte at address 0xffec in common segment INTVEC. It is defined in module "hal_interrupts" as well as in module "hal_adc"

Daniel Hartl said:

__interrupt void TIMER0_A0_ISR(void)
{
switch(__even_in_range(ADC12IV,34))
{

Obviously, the ISR is checking the ADC12 interrupt vector register for a pending ADC12 interrupt. It makes absolutely no sense doing it inside the timer interrupt:

If interrupts are gloablly disabled, then the tierm ISR isn't called too. If they are, the ADC ISR would be called.

If a specific ADC12 interrupt source isn't enabled by IE bit, it won't of coutrse call teh ADC12 ISR, but then it also won't show up in the ADC12IV register.

So yes, the code inside the tiemr ISR belongs into the ADC12 ISR. No idea what else might be messed up here.