• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 270 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.

MSP430F5358: Handling multiple IIC bus request-

Shubhanshu Rastogi
Prodigy 80 points
Part Number: MSP430F5358


HI Team,

We are using IIC communication between processor and controller. We are having multiple sensor monitoring data and some memory write and read operations on controller, where these operations need to be done by processor.  For this communication architecture we have designed in the interrupt based and it is working fine when only 1 read/write request is being accessed.

Problem comes when processor gives two request of read/write and thus IIC bus get held up. And processor stop detecting slave while doing IIC scan or any new request given.

Q1. What will be the optimal way to handle this multiple request and how we can achieve this?

  • 0
    Guru 100405 points

    I'm supposing that your controller is the MSP430, and it is acting as the I2C slave. 

    The Slave has very little control over an I2C transaction; its only real recourse is to stretch the clock (hold SCL low), which stalls the bus. The slave must work within the flow-control: (a) every TXIFG must be matched with a write to TXBUF and (b) every RXIFG must be matched with a read from RXBUF. If it "forgets", the bus is stalled forever.

    I'm guessing that your first transaction requests a "long"-running operation in your Slave, and the Slave is pending (or "forgetting") to respond while the operation is in progress. I can see 3x strategies, depending on how long "long" is:

    1) Short (say, a few milliseconds or less): just let the clock stretch. You need to keep track of the fact that the IFG arrived (since it has been cleared by reading the IV).

    2) Medium (say < 100 milliseconds): respond with dummy data that somehow tells the Master that the Slave is "busy".

    3) Long (seconds or minutes): Take the Slave off the bus by e.g. setting its I2COA=0. This is fairly drastic, though I recall an EEPROM which did this during its write cycle (I think they called it "NACK-Waiting").

    A parallel strategy would be to run these operations periodically without being requested, then giving the Master the results of the latest run when asked.

    If you can explain what you're doing in a bit more detail, someone might be able to give a better answer.

**Attention** This is a public forum