• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1808 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem with USCIAB0RX ISR

inakizi
Prodigy 250 points

Other Parts Discussed in Thread: MSP430F2272

I'm seeing somehting very weird. I'm using both USCIA (as UART) and USCIB as (I2C), basically my problem is that the program enters the IRQ and never leaves! even with all the interrupts serviced!.

This is basically my interrupt code:

 

 

#pragma vector=USCIAB0RX_VECTOR

__interrupt void USCI0RX_ISR(void)

{

 

    if (IFG2 & UCA0RXIFG) {

        // Asynch Receive char    

        char rx = UCA0RXBUF;

        switch (gSerialRxState) {

                  // Lots of stuff here

        }

    } else {

        if (IFG2 & UCB0RXIFG) {

            USCIAB0RX_ISR();   

        }

    }

}

Now the problem is that when I check the registers with my debugger this is the state of the special registers:

IE2

     UCA0RXIE = 1

     UCA0TXIE = 0

     UCB0RXIE = 1

     UCB0TXIE = 0

IFG2

     UCA0RXIFG = 0

     UCA0TXIFG = 1

     UCB0RXIFG = 0

     UCB0TXIFG = 0

 

So the interrupt flags are not set (probably because they were cleared the first time the interrupt code was executed), but the interrupt keeps entering inmeadiatly after it exeits, locking up the whole program.

Any help would be appreciatted.

Thanks,

 

 

 

 

 

  • 0
    TI__Expert 7845 points

    I am not sure what device you are using, but I would suggest the following:
    1. Create a new project with just the UART code and ISR using the code example (msp430x261x_uscia0_uart_04.c) in the following zip file:
    http://www.ti.com/lit/zip/slac151

    2. I am not sure if the MSP430 I2C is a slave or master and TX or RX, but separately, use the code example (msp430x261x_uscib0_i2c_05.c) in the same zip file.

    Please test these code examples individually to see if the problem appears. If not, then combine the code examples to duplicate the issue.
    You may have to choose a different code example depending on the following factors: device, I2C Master or slave andTX or RX
    You will also need a hyperterminal or another MSP430 (for UART test) and another MSP430 (for I2C test).

    The code examples for all device families are available at:
    www.ti.com/msp430codeexamples

    Please also note that:
    The USCIAB0RX_VECTOR handles only Start and stop conidtion flags (UCSTPIFG and UCSTTIFG). All in all TX and RX are both handled in the USCIAB0TX interrupt, while I2C state changes are handled in the USCIAB0RX interrupt.

    From page 17-24 of the 2xx User's Guide. USCI_Ax and USCI_Bx share the same interrupt vectors. In I2C mode the state change interrupt flags UCSTTIFG, UCSTPIFG, UCIFG, UCALIFG from USCI_Bx and UCAxRXIFG from USCI_Ax are routed to one interrupt vector. [USCIAB0RX] 

  • 0 in reply to Harman
    Prodigy 250 points

    Sorry I forgot to put more info. I'm using the MSP430F2272.

    I am connecting the serial port to a PC (trough a bluetooth radio but it is transparent) and I have three devices conected to the I2C bus. All these devices are slaves.

    I was originally using only serial and it was working fine. Then I added the I2C interrupt based no DMA library that I downloaded from the TI website and it was working fine first whith my first approach that was constantly reading the I2C and used the shared IRQ. Later I scheduled the I2C to be read every minute and from there things started failing. The cause for the first failure is that the I2C library from TI made in the code:

    IE2 = UCB0RXIE;

    and that was disabling my serial interrupt. Of course it will work fine with continuous reads because I was sharing the interrupt so it will service my serial port everytime that it was servicing the I2C. So I changed that instruction to be:

    IE2 |= UCB0RXIE;

    and now things started working a little bit better, but after a couple seconds the interrupt routine gets called constantly locking up the whole program. I single stepped in assembly and everything looks fine, when it reaches the RETI it goes back and starts running again, like if the interrupt condition is not being cleared in the IRQ. Now I think that only the UCA0RXIFG and UCB0RXIFG  signals can cause that interrupt to happen. Is possible that there is another reason for this interrupt to happen?

    I'm going to try your suggestion later today.

     

  • 0 in reply to inakizi
    Prodigy 250 points

    I think I fixed the issue, basically I should call the I2C interrupt handler even if the flag is not set. 

     

    /*------------------------------------------------------------------------------

    * USCIA and USCIB shared interrupt service routine

    * This ISR is used for both asynch serial reception and I2C TX/RX 

    ------------------------------------------------------------------------------*/

    #pragma vector=USCIAB0RX_VECTOR

    __interrupt void USCI0RX_ISR(void)

    {

     

        if (IFG2 & UCA0RXIFG) {

            // Asynch Receive char    

            char rx = UCA0RXBUF;

            switch (gSerialRxState) {

                    // Protocol handling

            }

        } else {

            USCIAB0RX_ISR();   

        }

    }

     

**Attention** This is a public forum