• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 1379 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.

Linux/TPS40400: How to recover from I2C SDA stuck low on TPS40400?

Daniel Daniel26
Prodigy 20 points
Part Number: TPS40400
Other Parts Discussed in Thread: TMS320DM8168

Tool/software: Linux

Hello,


Background:
On our board we use TPS40400 buck controller as 1.1V source for the TMS320DM8168.
The TMS320DM8168 processor controls TPS40400 via I2C bus (PMBus interface).

Using a dedicated script, I have scheduled a device reset during the time TMS320DM8168 configures the TPS40400.
Means, the device reset comes during an I2C transaction between TMS320DM8168 (master) to TPS40400 (slave).
Occasionally (not always) after this reset, the TMS320DM8168 reports on the following error message describing communication error with TPS40400:

"SCSI subsystem initialized
omap_i2c omap_i2c.1: bus 1 rev4.0 at 100 kHz
omap_i2c omap_i2c.1: timeout waiting for bus ready
set_machine_constraints: failed to enable pmbus_vr
pmbus 1-0012: failed to register pmbus
pmbus: probe of 1-0012 failed with error -110"

Further investigation shows it happens since I2C SDA between TMS320DM8168 to TPS40400 stuck on low because of the reset mentioned above.
Means, at the times the reset comes when SDA='0', the SDA was stuck on this state, the TMS320DM8168 identify the I2C bus as "not ready" and reports the error message.
The TPS40400 I2C transmitter state must return to the idle state, waiting for a new master (TMS320DM8168) command.
(The I2C SCL is high after the reset as expected).
In other words, it was observed that if the board gets reset while I2C transaction between TMS320DM8168 and TPS40400 the SDA line remains stuck low until power cycle.
Unlike TMS320DM8168, the TPS40400 does not have reset input.
How can we to cause TPS40400 to release SDA line to high without power cycle?


I have made also a simple experiment in LAB:
a. I've reproduced the failure.
b. I shorted (momentarily) the SCL to GND (in order to generate a dummy I2C clock, hopefully it will release SDA signal).
c. Thankfully, as an immediate respone, the SDA changed polarity to logic high (the I2C channel is back on "start condition" state - SCL,SDA = high logic).
d. I have scheduled again my device reset.
e. No failure anymore

My questions are:
1. How to recover from I2C SDA stuck low on TMS320DM8168/TPS40400 (PMBus interface between TMS320DM8168 to TPS40400) as a robust and formal solution, without power cycle?
2. Is there a way to reset the I2C bus between TMS320DM8168 to TPS40400 (PMBus interface)? means, to bring it to "start condition" state - SCL,SDA = high logic.
3. In our reset case mentioned above, is there a way to return the TPS40400 I2C transmitter state to the idle state, waiting for a new master command?

Regards,
Daniel Daniel

  • 0
    TI__Expert 5900 points

    Hello Daniel,

    Per the SMBus Spec, a slave device will hold the DAT line low as long as CLK is high.  “DAT low” typically occurs when the Master and Slave devices get out of SYNC, either with the slave device advancing 1 CLK ahead of the Master device or falling 1CLK behind the Master device.  This leaves the slave device holding DAT low because it believes the bus is in the ACK bit of the transaction.

     

    Sending  a single CLK low will typically release the slave, but it may also result in the slave device executing the previously sent transaction with a 1-bit shift somewhere in the transaction, which could cause bad results.  Instead, a safer solution is to send a “BUS RESET” by having the Master device pull CLK low for 35ms.  That should reset every device on the bus and direct every device on the bus to abort an “in progress” transaction.

     Regards,

    Mathew

    This is from the SMBUS spec:

     SMDAT.docx

     

  • 0 in reply to Mathew Jacob1
    Prodigy 80 points
    On behalf of Daniel and myself, thank you Mathew very much.
    We have implemented the solution you've suggested and it works, solving our problem.
    Regards,
    Eyal.
  • 0 in reply to eyal beit-halachmi1
    TI__Expert 5900 points

    closing the thread,,,