Page 13-24 of the MSP430x2xx User guide shows example code, which if
written in C would look like this for USCIA0 and USCIB0

//----------------------------------
// USCIA0_TX USCIB0_I2C_DATA_ISR
//----------------------------------
#pragma vector = USCIAB0TX_VECTOR
__interrupt void UART0TX_isr (void)
{
if( IFG2 & UCA0TXIFG )
{
// do the UART transmit processing
// Write UCA0TXBUF ... − clears UCA0TXIFG
}
else // do the I2C data processing
{
if(IFG2 & UCB0RXIFG)
{
// Read UCB0RXBUF... − clears UCB0RXIFG
}
else
{
// Write UCA0TXBUF ... − clears UCA0TXIFG
}
}
}

The trouble I am finding is that UCA0TXIFG is set most of the time
so If an interrupt occurs for USCIB0 - for an I2C operation the
processor goes and executes the code for UCA0 instead!!!!
I find this occurs even if UCA0TXIE = 0, am I missing something?

In my application I need I2C and the UART operating without having to
disable one or the other, has anyone managaged to acheive this?

Is anyone aware of any appnotes or examples from TI that show I2C and
the UART operating concurrently ? These types of examples are not
present in the 241x,261x so far as I am aware.

Start a New Thread

> The trouble I am finding is that UCA0TXIFG is set most of the time
> so If an interrupt occurs for USCIB0 - for an I2C operation the
> processor goes and executes the code for UCA0 instead!!!!
> I find this occurs even if UCA0TXIE = 0, am I missing something?
Remember, IFGs are set by hardware independently of their respective
IE bit. The IE bit only enables the IFG to generate an interrupt (and
be included in the interrupt vector generator of pripherals that have
it), nothing more.

It seems your UART rate is too fast for your MLCK. In consecuence,
between entering, processing, and exiting the ISR you have consumed
too much MCLK clocks, which sets another of the UART's IFGs very soon
(or even before) exiting the ISR.

> #pragma vector = USCIAB0TX_VECTOR
> __interrupt void UART0TX_isr (void)
> {
> if( IFG2 & UCA0TXIFG )
> {
> // do the UART transmit processing
> // Write UCA0TXBUF ... − clears UCA0TXIFG
> }
> else // do the I2C data processing
> {
> if(IFG2 & UCB0RXIFG)
> {
> // Read UCB0RXBUF... − clears UCB0RXIFG
> }
> else
> {
> // Write UCA0TXBUF ... − clears UCA0TXIFG
> }
> }
> }
You are only enabling one interrupt flag to be attended each time you
enter the ISR. Ditch all the else(), only use if()and only for the
enabled interrupts.

Also keep in mind that the IFGs will only be cleared if their
associated shift register is empty. This means that if you enabled the
interrupts without data on the 3 shift registers and buffers, the ISR
will be called 6 times in a row, by which time the first byte your ISR
wrote to UCA0TXBUF might already have been transmitted and the ISR
will be called a 7th time in a row.

Hope this gave you some insights.

Regards,
Michael K.

--- In m..., "apcjw" wrote:
> Page 13-24 of the MSP430x2xx User guide shows example code, which if
> written in C would look like this for USCIA0 and USCIB0
>
> //----------------------------------
> // USCIA0_TX USCIB0_I2C_DATA_ISR
> //----------------------------------
> #pragma vector = USCIAB0TX_VECTOR
> __interrupt void UART0TX_isr (void)
> {
> if( IFG2 & UCA0TXIFG )
> {
> // do the UART transmit processing
> // Write UCA0TXBUF ... − clears UCA0TXIFG
> }
> else // do the I2C data processing
> {
> if(IFG2 & UCB0RXIFG)
> {
> // Read UCB0RXBUF... − clears UCB0RXIFG
> }
> else
> {
> // Write UCA0TXBUF ... − clears UCA0TXIFG
> }
> }
> }
>
> The trouble I am finding is that UCA0TXIFG is set most of the time
> so If an interrupt occurs for USCIB0 - for an I2C operation the
> processor goes and executes the code for UCA0 instead!!!!
> I find this occurs even if UCA0TXIE = 0, am I missing something?
>
> In my application I need I2C and the UART operating without having to
> disable one or the other, has anyone managaged to acheive this?
>
> Is anyone aware of any appnotes or examples from TI that show I2C and
> the UART operating concurrently ? These types of examples are not
> present in the 241x,261x so far as I am aware.
>

Start a New Thread