Forums

I don't really understand what your problem is.

However, when a port interrupt is detected (IFG bit set) and the ISR is called (only if IE bit is set too), this doesn't remove the interrupt condition (except in a few cases, e.g. the TA/TBCCR0 interrupt auto-clears it).
Inside your ISR, you'll have to clear the IFG bit. In some cases this is done by handling the interrupt reason (e.g. reading RXBUF clears the RXIFG bit), in most other cases you'll have to manually do it.
For soem ISRs there is an interrupt vector register (xxxIV). If read, it will return a number that represents the highest pending interrupt for this module and at the same tiem clear the IFG bit for this interrupt.
If you don't use this, you'll have to manually reset the IFG bit, or the interupt is still pending, and leavign the ISR will enter it again right away, unless a higher priority interrupt is pending.
So an enabled but not properly reset interrupt may block all other (lower priority) interrupts from ever being handled (and prevents main from running at all).

I think I understand what you are saying.  If you look at my program I have to set a flag "Start2" because when I do a reset it triggers the Port 1 ISR and inside the Port 1 ISR it thinks that BUTTON has been pushed.  I have been working on this problem for three days and have tried clearing the BUTTON flag by using BUTTON_IFG &= ~BUTTON;  to clear the BUTTON interrupt flag and BUTTON_IE |= BUTTON;  to reset the interrupt.  This didn't work.  By what you are saying its the interrupt from a higher priority interrupt, keeping the Port 1 ISR from working and also the reason why I am entering the Port 1 ISR right away.  It sounds like I need to reset all P1 and P2 interrupts and restart them.  I don't know exactly where to do this but I will try it in the RX ISR.  I appreciate your help on this and I will let you know what I come up with.

I fixed the problem.  I put

BUTTON_IFG &=~BUTTON;
BUTTON_IE&=~BUTTON;

at the end of the Port 1 ISR which stopped the double entry into the ISR.

I reset the BUTTON interrupt in the CASE a routine and also in the Timer ISR using BUTTON_IE |= BUTTON;

I'm still not sure why I have to clear and reset the P2 interrupts when I don't use BIT1, BIT2 or BUTTON ,which is BIT7, in my program for P2.

You enabled P2 interrupt for DAT (P2IE = DAT). As soon as an itnerrupt is detected on P2, it sticks there. You don't have an ISR for P2, do you? (the unformatted code is difficult to read). If no ISR is handling the P2 interrupt...

If you want to have a timer capture interrupt on P2.0, you don't have to set P2IE. These two are totally different things.

BTW: "P2SEL = DAT; // Set P1.1 to TA0" doesn't seem to fit, as you're programming P2.0 where the comment talks about P1.1.

Besides this, you already tried to do some sort of debouncing mechanism with butdeb[0].
Pressing the button will likely trigger a series of itnerrupts which will cause the button ISR to be called several times.
However, your inital approach to handle the interrupt only if butdeb[0] wa snot preventing further interrupts from happening (stealing CPu time). It only suppressed their handling inside the ISR.

Disabling the button IE bit (blocking all further interrupts) until the timer expired, and then clearing the button IFG bit before re-enabling the IE bit is indeed a good way to have a proper debouncing.

But: calling TX from inside the port ISR (or any ISR) is not a good idea, as its current incarnation uses busy-waiting for transfer completion (so the CPU is locked and won't accept any further interrupt sor do anything useful) until the transfer is done. And if a later version uses interrupts itself for doing the transfer, thsi wouldn't work sicne during ISR execution, all other interrupts are locked.

You should instead set a global flag and let main() do the time-consuming I/O.

A furhte rimprovement: don't do anything inside the por tISR except for settign up the timer. In teh tierm ISR, check the current state of the port pin and initiate any action if the button is still pressed. This will eliminate glitches or button presses below the duration of the timer ISR. it also prevents additional button triggers due to bouncign while the button is actually released. (any bouncing during button release will trigger another button press in your code, but if you delay the check whether the button was really pressed into the tiemr ISR, you'll see that the button is no longer pressed afte rthe debounce time and it was a bounce during button release. (I hope this was not too confusing)

What this program does is measures the pulse width that comes in on P2.0.  Sorry about the misplaced comment.  It also counts the number of pulses.  This is all handled under the vector=TIMER1_A0_VECTOR.  This part of the programs work just like it should.  Even my reset routine works "Case a".  My problem is when I introduced the button.  I am using the butdeb[0] to prevent bouncing.  This appears to work but even after clearing the BUTTON interrupt flag and do a reset,Case a, I get an interrupt on the Port1 ISR and it thinks the button is the interrupt.  And  if I don't clear the P2IFG BIT1, BIT2 and Button, which has nothing to do with the P1 BIT1, BIT2 and BUTTON I am using in my program, the Port1 ISR will not fire.  I have tried reading the TA1IV, TA0IV and TAIV.  This is supposed to clear the interrupts pending, no change.  When inside the Port 1 ISR  nothing else is happening so the delay that is created by the transfer doesn't really matter.  I have two questions:

1.  Which XXXIV word goes with the TIMER1_A0_VECTOR? TA1IV TA0IV,etc.

2.  Why do I have to clear P2IFG BIT1+BIT2+BUTTON interupts, which I don't use to get the Port 1 ISR to fire?

The statement about setting up the timer in the Port1 ISR, I guess I could use the WD timer as an interval Timer.  I found some examples of this that creates an ISR

that contains the following which turns the interrupt off and then resets it in the WD ISR.  Is this what you were referring to? 

interrupt (PORT1_VECTOR) PORT1_ISR(void)
{   
  BUTTON_IFG = 0;  
  BUTTON_IE &= ~BUTTON;            /* Debounce */
  WDTCTL = WDT_ADLY_250;
  IFG1 &= ~WDTIFG;                 /* clear interrupt flag */
  IE1 |= WDTIE; 

interrupt (WDT_VECTOR) WDT_SIR(void)
{
    IE1 &= ~WDTIE;                   /* disable interrupt */
    IFG1 &= ~WDTIFG;                 /* clear interrupt flag */
    WDTCTL = WDTPW + WDTHOLD;        /* put WDT back in hold state */
    BUTTON_IE |= BUTTON;             /* Debouncing complete */
}

Donald Varela

1.  Which XXXIV word goes with the TIMER1_A0_VECTOR? TA1IV TA0IV,etc.

TIMER1_A0_VECTOR is solely for TA1CCR0. When this vector is called, you knwo that TA1CCR0 has triggered it. No need for an IV register. Also, when this vector is called, TA1CCR0.CCIFG is automatically cleared (saves you a few bytes and clock cycles).

For TIMER1_A1_VECTOR, there is the TA1IV register, covering the timer overflow interrupt TAIFG, as well as the TA1CCR1 to CCRx interrupts.
Similar for Timer A0 (TA0IV) or Timer B (TBIV) etc.
Yes, the naming is a bit confusing. It's so for historical reasons - the first MSPs dodn't have a Timer A1, there was only 'the' Timer A.

Donald Varela

2.  Why do I have to clear P2IFG BIT1+BIT2+BUTTON interupts, which I don't use to get the Port 1 ISR to fire?

You only need to clear the IFG bits where the corresponding IE bits have been set. In the USCI ISR, you set all three IE bits, so all three port pins can (and will) trigger interrupts.

Donald Varela

Is this what you were referring to? 

Almost. The WDT or the delay is fine.
However, inside the WDT ISR, you'll need to clear BUTTON_IFG once more (the bouncing will likely have set it again, even though the IE bit was not set and therefore the ISR wasn't called). Also, check for (BUTTON_IN & BUTTON) to determine whether the button is pressed or released after the delay. Bouncing and therefore interrupts can happen at release as well as on press! A pushbutton is not a clean digital signal. Else you might get a second, false 'press' event on button release, even with debouncing delay.

Michael I can"t get " if (BUTTON_IN & BUTTON) {" to be true.  It is defined as "#define     BUTTON_IN             P1IN".  Is this correct?

I want to thank everyone for their input.  There is something killing my Port 1 interrupt after I do Case a.  It has to do with the Timer ISR and the P2 port which I'm only using P2.0.  Tried every means that I know of to clear the interrupt to no avail.  My intentions on the Case a reset was to reset some memory variables and continue as normal.  Well I found out the easiest way to do this, not the most graceful but it works.  At the end of Case a I replaced break; with main();  I wish I could have figured out why the Port 1 ISR would go dead if I didn't put the P2IFG statements when I'm not using BIT1, BIT2 or BUTTON on port 2.  Maybe someone out there could actually put this on a launchpad and leave off the P2IFG in the Case a to see what I have been up against. The easiest test for this is to put the program on a launchpad, connect to a terminal.  Type "a" and then try to get the button to work.

Thanks again for all your inputs.  I,m going to mark this as answered but really it isn't.

Donald Varela

Michael I can"t get " if (BUTTON_IN & BUTTON) {" to be true.  It is defined as "#define     BUTTON_IN             P1IN".  Is this correct?

Yes, the button is on Port1, so P1IN is the register that shows the momentary input state of Port1. BUTTON_IN & BUTTON returns either zero (false) or BUTTON/BIT7 (true) depending on the button state.
However, it migh tbe that you need to check for (!(BUTTON_IN & BUTTON)), if the button pin is low when the button is pressed.

Donald Varela

There is something killing my Port 1 interrupt after I do Case a.

Port1 interupt has the lowest priority of all (except main). Next higher is Port2 interrupt, then ADC, USCI, Timer0 and Timer1.

As long as a higher priority interrupt i spending and not handled, the lower priority interrupt swon't be called.

However, I just noticed that in case 'a'. you do "P2IE|=(BIT1 + BIT2 + BUTTON);" while the defines tell that BUTTON is on Port 1. So you're enabling an interrutp on P2.7 that is no input signal at all and may trigger interrupts by catching radio waves.

I got the button to work.  Even though I set the IES High to Low the Port fires when I release the button.

What my problem is if I don't put P2IE|=(BIT1 + BIT2 + BUTTON); in the Case a Port 1 will never fire.  I agree that some interrupt is keeping the port 1 from firing because of its priority.  Take the P2IE and P2ifg commands out of the Case statement and you will see that after doing the reset, "Case a" Port1 will not fire.  I have tried clearing the port 2 interrupts that I am using which is P2.0.  //Clear P2 IFG " P2IFG &= ~DAT;".  I even tried clearing all interrupts for port 1 and port 2 

P2IFG &=~0x3F;
P1IFG &=~0xFF;

I think this clears all interrupts.  Then I initialized just the Botton interrupt.

BUTTON_IE |= BUTTON;

I tried stopping the Timer and stopping the Timer interrupts

//turnoff timer 1
TA1CTL = MC_0;

TA1CCTL0=CM_0;

I can't figure out what is keeping it from firing.

I don't know how to check all pending interrupts.  The last interrupt I use is the USCI.  I don't know how to check its interrupt status.

I checked (UCA0STAT) and it was zero.

Nothing seems to work.

I would really like a solution for further programs.  Currently if I call main() at the end of Case a it works fine, but this is a crappy solution.

This code works fine on my launchpad. Just a guess are P2.7 and P1.7  shorted .

Yes it works but if you take out the P2IFG and P2IE commands, which are really erroneous, it doesn't.

I FOUND THE PROBLEM!!!!

If you remove 

P1DIR |= 0x01;
P1OUT = LED1;// Set P1.0 to output direction

everything works fine!!!

I don't know what this has to do with what is happening..