• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 103 subscribers
  • Views 2653 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Working of I2C_Transfer function of TI-RTOS in blocking mode

Soumyajit Das
Genius 3340 points
Other Parts Discussed in Thread: EK-TM4C1294XL

MCU: TM4C1294NCPDT

TI-RTOS: v2.01.00.03

CCS: v6.0.1.0040

I2C_device used: M41T62 from St Microelectronics

Hello,

QUERY 1:

    I am using the function I2C_Transfer (in blocking mode) in my code. I want to know whether the CPU will be released or not while the function is blocking the execution of the task from where it is called. What I mean is that, if I2C_Transfer function is waiting for an ongoing transaction to complete, higher priority tasks can pre-empt the currently running task, but while I2C_Transfer function is waiting for some I2C communication to complete, will lower priority tasks be able to run?

QUERY 2:

    Also, I am noticing that when I am connecting my I2C device to the Tiva MCU using two hook up wires (power supply permanently connected to the I2C device from EK-TM4C1294XL board, but SCL & SDA lines are detachable) two phenomena are being noticed:

Case 1:

    The SCL & SDA wires are connected & the I2C_Transfer function is returning FALSE (here I have set a wrong device address/ID for test perposes).

Case 2:

    The SCL & SDA wires are left unconnected & the I2C_Transfer function is getting blocked and never returns until I connect the SCL & SDA wires.

    My query is how will the Tiva MCU know whether there was a I2C device ID mismatch or whether the I2C device is not present on the I2C bus? All I can re-collect is that the ACK & NACK (9th bit of a I2C communication byte) is used to detect presence of a correctly addressed I2C device. According to me, whether we connect an I2C device to the bus with a wrong device ID or we don't connect the device at all, both are going to give NACK result to the Tiva MCU. So, how is the difference occuring that is making I2C_Transfer function to decide whether to wait indefinitely or return FALSE?

Thanks 

Regards

Soumyajit

  • 0
    TI__Mastermind 26780 points

    Soumyajit,

    For query #1: Yes, other tasks will be able to run if they are ready.

    For query #2: What you describe is the expected behavior - the transfer function returns false if the device address is incorrect, but keeps waiting if there is nothing on the bus.  

    I don’t know all the details of the implementation… but in the case of an incorrect address, the ISR will be triggered, and the internal state machine will know to exit the transfer function.  If the lines are unconnected, the state machine gets stuck waiting for bus activity.  One can argue that having the SCL and SDA lines unconnected is an “invalid bus configuration”.  

    There is some work in progress to add a timeout mechanism to avoid getting stuck like this.  But I don’t know when that will be available.

    If this is a big issue, one thing you might do to avoid getting stuck would be to not use blocking mode, but use callbacks instead, and detect a timeout in your own code.  Not the best solution, but maybe a possibility.

    Regards,
    Scott

  • 0 in reply to ScottG
    Prodigy 150 points

    Hi.

    I have a different version of query #1:

    2 tasks with same priority, each using different I2C channel in blocking mode.

    Task #1 calls  I2C_Transfer and blocks.

    What happens when task #2 calls I2C_Transfer? Does it wait for task #1 to complete the transfer, or these two calls are run simultaneously, because 2 different I2C channels are used?

    Thanks.

  • 0 in reply to Michael Vinokur
    TI__Expert 8175 points
    Hi Michael,
    Since its different I2C controllers and 2 different I2C driver instances both will run completely independent on each other. Task 2 will not wait for Task 1 to be done.

    Moses