problem with timer interrupt

Hi,

 

ARUN said:

TACTL = TASSEL_2+TACLR+MC_2+TBIE; // Timer init using SMCLK, Clear counter and set timer to continous mode

This command actually enables the interrupts for the timerA overflow (counting from max timer value to 0) so the interrupt vector TIMERA1_VECTOR will be called.  As you haven't declared an ISR for this vector it is probably causing a reset (the value at this vector is probably 0xFFFF).  [Also using a timerB symbol in a timerA initialisation is not a great idea - although the values are identical (in this case at least) I think it is a bad habit to get into!]

Remove the "TBIE" part of the command and see if it starts generating a pulse.  With an 8MHz clock, 16bit timer value (as in continuous up mode) you should get an interrupt every 8.192ms, generating a square wave of approx 61Hz.

It is good practice to write a dummy ISR to catch interrupts for all the events you don't intentionally use.  This way you can catch any unexpected interrupts during development and sort them out!

 

ARUN said:

P4OUT ^= 0xff;                            // Toggle P4.0

Actually this will toggle ALL the P4 pins.  To just toggle P4.0 use P4OUT ^= BIT0;

If you just want to set/clear a single pin then for better accuracy it might be worth considering using the hardware to generate the pulse using the in-built PWM features - see section 11.2.5 of the user guide or some of the TI code examples or various threads on this forum.

 

 

Regards,

Chris.

hi Chris

Thanks for the reply i have corrected the errors u have mentioned but still no interrupt is generated. Is i missing somethin?. Hoping for your reply

#include  <msp430x14x.h>
#include  <stdio.h>
#include  <signal.h>


void main(void)
{

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog
P4DIR |= 0xff;


BCSCTL1 &= ~XT2OFF; // XT2= HF XTAL switch master clock to XT2IN
int x;
do
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for ( x = 0xFF; x > 0; x--); // Time for flag to set
}

while ((IFG1 & OFIFG)); // OSCFault flag still set?

BCSCTL2 = SELM_2 + SELS;
TBCCTL0=CCR0;
TBCTL = TBSSEL_2 + MC_2 + TBIE;
TBCCR0=50;



_BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/interrupt so CPU sleep and wait till 1s
while(1);
}





 interrupt (TIMERB0_VECTOR) ISRTimerB0 (void)
{
  P4OUT ^= BIT0;                            // Toggle P4.0
TBCCTL0 &= ~CCIFG;

TBCCR0 +=50;
   LPM0_EXIT;                         
}

You haven't quite resolved them all yet! :-)

 

ARUN said:

TBCTL = TBSSEL_2 + MC_2 + TBIE;

With TBIE set and no declaration for that interrupt (now TIMERB1_VECTOR) you still have the same problem as before.

 

ARUN said:

TBCCTL0=CCR0;

I'm not sure this makes much sense - if you look in the header file "CCR0" means "TACCR0" so you are just copying the value of an uninitialised capture/compare register to a control register - not a good idea!

 

Try using clock initialisation like this:

TBCCR0 = 50;                       // first ISR when TBR counts to 50
TBCCTL0 = CCIE;                    // compare mode, interrupt when TBR==TBCCR0

TBCTL = TBSSEL_2 | MC_2;           // 16bit counter length, use SMCLK (no division), continuous up mode,  no overflow interrupt required

 

Hopefully that will start running as you wanted.

 

ARUN said:

_BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/interrupt so CPU sleep and wait till 1s
while(1);

Note that the first event of the ISR would (if it were ever called) prompt to exit the low power mode and then the processor would sit in the while(1) loop on full power.  Either put the "enter LPM" in the while loop or just delete the while(1) and the ISR command to exit the LPM.

 

Chris.

Hi Chris

Thanks a lot finally i got the interrupt routine working. But i am confused in calculating the frequency it gives some random frequency on my CRO. Is there any exact forumulae to calculate?

 

Thanks u once again

 

Arun

Well, you have 8MHz crystal. For undivided SMCLK and TImer clock, this means 8 timer ticks per µs.

You set the delay for CCR0 to 50 ticks.

Now waking up from LPM takes up to 6µs = 6*8 =48 ticks. Plus 13 ticks interrupt latency plus ISR execution time... Waking up the processor and executing the ISR takes more than your 50 ticks between two CCR0 interrupts. So when you add 50 to CCR0, the timer has long passed the next trigger point and you'll have to wait one full timer cycle until the timer reaches CCR0 next time.

ARUN said:

TBCCTL0 &= ~CCIFG;

For CCR0, this is not necessary. CCIFG for CCR0 is automatically cleared when teh ISR is entered (sinc eit is the only IFG tht triggers this interrupt vector). For TBIFG and the other CCRs, you'll need to either manually clear the IFGs or use the TBIV register, which will, when read, tell you which of the various interrupts occurred, and will at the same time clear its IFG bit. (subsequent reads willr eveal the next interrupt cause, if any, or 0 if no more interrupts are pending).

 

HI

 

I have another msp430f149 board that is programmed via TUSB controller. I cant able to run any interrupt program on it means no interrupt is generated on it. The bsl is active and i can run addition, subtraction programs also i can able to run square wave generation without using any interrupt . i even changed the IC but the problem perisist. Any suggestion.

regards

arung

The time until the interrupt is the number of TBR counts divided by the clock frequency (i.e. 50/8M = 6.25us).  The interrupt frequency will be the inverse of this (160kHz) and as the pin is toggled each interrupt the overall pulse frequency would be half this (80kHz).

But as Jens-Michael points out when using a CCR0 value of 50 there isn't enough time to enter/exit the interrupt so for this example you will more likely see a frequency in the region of 120Hz (assuming the counter overflows between interrupts).  You have to be careful to avoid situations like these.  If you need this really high frequency then I suggest trying to use the PWM feature as the hardware has very little latency.

 

As for the new problem... Is this using the same firmware as we have been discussing here?  If the code runs ok on one board but not on another then perhaps there is a problem with the XT2 clock - if the other programs that run ok are using the DCO then this would point to the XT2 as the potential cause of the problem.

 

Regards,

Chris.

Hi

Thanks for the reply. Hi replaced the XT2 crystal on the board but still the problem perisists and more over i am using the same firmware. After that i that there could be a problem with the controller so i went on replacing it with new msp430f149 which also resulted in vain. I do know what is the cause or is there a way to debug the problem.

 

regards

arungk

There are various things you can try, choosing which one to start with will depend on your setup/preferences/instincts.

From what you have said in your previous posts the crystal operation would be one of my first points of interest.  If other programs are running ok then I would assume the device programs correctly (assuming that the interrupt code is being downloaded from the same PC/project settings/debug tool?).  If these other programs are not using the external crystal then it would suggest that the interrupt program should run ok but just isn't detecting any oscillator ticks so isn't counting up to the CCR target and generating the interrupt.  If you can run a debugger it should be easy to see if the timer is actually counting up or not.  Alternatively if your board layout permits it you could output the clock signal on pin P5.5 (set the SEL bit: P5SEL=BIT5) and measure it with an oscilloscope.  If it looks like the oscillator signal is not reaching the MSP then you will have to probe around the circuit looking for the problem...

 

 

Chris.

ARUN said:

i replaced the XT2 crystal on the board but still the problem perisists

Somethimes it' snot the crystal, it's the capacitors. The XT2 (or HF-XT1) requires external capacitors and is way more responsible to capacitancy varioations than the LF (32kHz) watch crystal. Where a wrong capacitance usually jsut detunes the watch crystal (up to a certain limit, of course), teh same capacitance variation mcan make the HF crystals stop completely. The influence increases with the frequency (so for 1MHz crystal is is *30).

We have a series of devices which run fine with an 8Mhz crystal for years, and suddenly on half of the new devices the crystal won't work. First we tried replacing the crystals, btu then we figured out that the difference was the brand/series of the capacitors. Same nominal capacitance but different tolerance and a different real capacitance. Which is difficult to check in the pF range.