Hey all, this has been troubling me for quite a while now.

My msp430f2272 is talking to an eeprom through i2c and also to another
device through uart(9600).

Each work great separately, but when I initialize both of them, the
UART cannot receive any data.

Here's how i'm doing things:

1. Initialize UART


2. Initialize I2C to check if slave is present

The slave appears fine, and i can continue to transmit on UART, but
after that, i can not receive any UART data.

Any ideas?

Thanks! Start a New Thread

ahhhh i found the problem.

my last line in the i2c initialization was:
IE2 = UCB0TXIE; // Enable TX ready interrupt

that needs to be:
IE2 |= UCB0TXIE; // Enable TX ready interrupt

otherwise it overwrites the serial settings.

Thank you anyway! Start a New Thread

your interrupt routines would be helpful.. Start a New Thread

Darn, the problem is back.

Here's the issue. I have a computer talking to the msp through USCIA
(uart). Inside that interrupt function, it waits for the character 'i'. If
it's pressed, the msp then reads a specific section of eeprom via USCIB
(i2c). Right here is where the msp freezes (the i2c busy flag is held high)

The problem i believe i'm seeing is that the both the uart and i2c
interrupts are the same


so therefore the uart interrupts first, and during that, the i2c interrupts.

Does this make any sense? I'd be happy to post more code if you feel it is
necessary to explain this in further detail.

-Jonathan Start a New Thread

shred444 wrote on 24/01/08 03:29 MET:
> Darn, the problem is back.
>
> Here's the issue. I have a computer talking to the msp through USCIA
> (uart). Inside that interrupt function, it waits for the character 'i'. If
> it's pressed, the msp then reads a specific section of eeprom via USCIB
> (i2c). Right here is where the msp freezes (the i2c busy flag is held high)
>
> The problem i believe i'm seeing is that the both the uart and i2c
> interrupts are the same

If I understand you correctly you are sending I2C commands out of interrupt
context, right? If so try to create a "main" routine which is basically an
endless loop which queries a flag set by the UartA receive routine to
initiate the I2C transfer. The I2C ISR then posts the result in another
variable and then the main routine intiates the serial send.

--
MfG / Regards
Friedrich Lobenstock Start a New Thread

Friedrich Lobenstock-2 wrote:
> If I understand you correctly you are sending I2C commands out of
> interrupt
> context, right? If so try to create a "main" routine which is basically an
> endless loop which queries a flag set by the UartA receive routine to
> initiate the I2C transfer. The I2C ISR then posts the result in another
> variable and then the main routine intiates the serial send.
>
> --
> MfG / Regards
> Friedrich Lobenstock

that's a great idea. I will try that tomorrow and let you know how it works
out. Just to clarify... by main routine, you mean... a looping timer that
occurs...lets say every 100ms that's constantly checking for that uartrx
flag? Thanks again Start a New Thread

shred444 wrote on 24/01/08 05:21 MET:
> Friedrich Lobenstock wrote:
>>
>> If I understand you correctly you are sending I2C commands out of
>> interrupt
>> context, right? If so try to create a "main" routine which is basically an
>> endless loop which queries a flag set by the UartA receive routine to
>> initiate the I2C transfer. The I2C ISR then posts the result in another
>> variable and then the main routine intiates the serial send.
>
> that's a great idea. I will try that tomorrow and let you know how it works
> out. Just to clarify... by main routine, you mean... a looping timer that
> occurs...lets say every 100ms that's constantly checking for that uartrx
> flag? Thanks again

No, I meant a real endless loop, like depicted below.


This is known as a Foreground-Background system.
A bit priecy but very much worth reading, gives a very good background in
realtime systems design:
Real-Time Systems Design and Analysis (Hardcover)
by Phillip A. Laplante <http://www.amazon.com/dp/0471228559/>

What I could find via Google
<http://www.google.com/search?q=realtime+systems+foreground+loop&hl=en>

[PDF] Review notes for single task and foreground-background systems
<http://www.informatics.bangor.ac.uk/~dewi/modules/rts/ICP3021_for_back.pdf>

--
MfG / Regards
Friedrich Lobenstock Start a New Thread

Sharing the interrupts should not be a problem.. The interrupt routine is supposed to determine which port is causing the interrupt..
howvere you normally cannot start another interrupt until the previous one is completed..

I would make sure that you are not trying to do the i2c read from the previous interrupt..

The way I would do it is.. process the uart interrupt.. set a global flag if it matches.. The main routine checks the flag then iniates an i2c read (this could be interrupt based), set a flag when the data buffer is full.. the main routine it can check this flag and send data out the uart as necessary..

your receive/transmit interrupt routines have to be able to determine which port the interrupt came from

the receive interrupts are shared between Axand Bx as well as the TX interrups sharing Ax and Bx Start a New Thread

I think your problem may be much more basic.
You are using the same USART hardware for both UART and I2C
interfaces. As far as I know, only one of those can be used at any
time. I don't know if you have realized this and if you are taking the
necessary precautions (both hardware and software) when changing
between modes, but it doesn't seam you are.
For example, you activate an Rx interrupt for UART, but your I2C init
activates an TX interrupt, without deactivating the RX interrupt set
by the UART init.
I couldn't find you interrupt routines on this thread.

Best Regards,
Michael K. Start a New Thread

He is using A0 for the uart and B0 for the I2c.. This is ok as long as its handled properly.. Start a New Thread