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.

omap_i2c omap_i2c.1: controller timed out

Other Parts Discussed in Thread: AM3703

I am plagued with this error every single day.

omap_i2c omap_i2c.1: controller timed out

When the i2c bus transactions do not complete fully (I have to talk to some flaky/temperamental devices) then the OMAP i2c driver appears to get itself in a huge mess... once this error has appeared on the console, the only way to resolve it is to physically disconnect the i2c bus from the Sitara and reconnect it.   Sometimes it seems that forcing a blind busmastered write from another i2c host on the same bus will also clear the error.

I've spent some time examining the OMAP i2c driver, and applying upstream patches from the 3.3 kernel, in hope that something would fix this error, but no joy.

The Sitara appears to hold SCL low, and refuses to clear it.   This is ridiculous.

I'm primarily using a DM814x EVM board for proof, with TI814X-LINUX-PSP-04.01.00.07

I would really appreciate some support on this problem as our product release date is fast approaching and this issue is really causing us a problem.

  • Hi Jeffray,

    I'm also facing the same problem!

    Through i2c communication trying to interface with battery ltc4155 but timeout error is coming!

    But the thing is when i searched,  I got to know that this error will occur when a slave device doesn't acknowledge our read and write addresses!

    Any improvment in this issue update in this thread!!!

    By the by i'm using AM3703 for battery LTC4155 interface!

    Regards,

    santosh vastrad

  • It's possible that an insane slave device is not releasing the bus, SCL or SDA. On rare occasions, I've had devices get into that sort of state. Hopefully you can disconnect the device from the bus or reset the device.

  • The problem is that it seems to be the Sitara that's not releasing the bus as far as I can see.  It just gets "stuck" and can't seem to sort itself out by prodding from the driver.

  • Just to confirm. The bus stays stuck even after you remove the bad slave device?

  • Yes, the bus stays stuck with SCL asserted low.

    An easy way to cause this to happen is to peform an i2c read for N+1 bytes when the slave device responds with just N bytes.  Any device, any command.  The OMAP i2c host just screws up at this point.

  • That is a puzzle. In the case of read N+1 but slave returns N, the host should not even notice the slave did not respond. On the N+1 byte, the host would read in 0xFF (idle bus) for data, intentionally not ACK, and issue a STOP. The slave could have stretched the clock after sending the Nth byte and then went insane. That would leave SCL held low. Removing the slave would remove the hold down. The host should recover. I guess it doesn't. No way to reset the i2c controller via the driver? Maybe a special ioctl() message?

  • Completely agree with what you're saying Norman... this sort of thing really should not be a problem at all, but it is.   There is no ioctl/etc to reset the device... hence why I have been digging around in the omap i2c driver code ... and even there, the code already calls its own "init" routine when this problem happens, but that does not clear the problem.   There is a comment in the code at this point saying that it should be "revisited". :-(

  • Hi Norman and Jeffray:

    According your suggestions I tried!

    I 've connected to scl and sda in oscilloscope for writing and address!

    passed address 0x09 but receiving something 0x08 !!!!!!!!!!!

    with controller timeout error!

    But when i disconnected the sda connection to my ltc4155 ic chip that time i'm getting correct address on osciloscope!

    and also no timeout controller error!

    so clear from my point of view that slave device is not acknowledging!

    I did as suggested by norman to check by disconnecting the slave device!

    Regards,

    santosh vastrad

  • Initially when we check , SCL and SDA will be high!

    But once running my program!

    The clock will be continuous , what might be reason?

    Now i'm trying with other method of interface by using GPIO pins for I2C3 interface!

    Regards,

    santosh vastrad