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.

TDA4VM: I2C abnormality occurs during use of TDA4VM

Part Number: TDA4VM

Tool/software:

I am designing a display screen. During the low temperature experiment, the TDA4VM host had an I2C abnormality.
His environment is as follows:

I used I2C-5 on MAIN_R5F. After a while of experimenting, Board_i2c8BitRegRd kept returning non-zero values,

so I stopped accessing I2C-5 on MAIN_R5F and tried from MAIN_A72 (sending i2ctransfer -y -f 5 w1@0x18 0x0c r1).

It returned an exception log (log file). I sent it again and it returned:

/cfs-file/__key/communityserver-discussions-components-files/791/First-abnormality.txt

[190111.881831] omap_i2c 2020000.i2c: controller timed out
Error: Sending messages failed: Connection timed out

I tried sending i2ctransfer -y -f 4 w1@0x16 0x0c r1 on I2C-4, and it returned correctly.

I also saved the dmesg log. Please help analyze what caused this issue.

/cfs-file/__key/communityserver-discussions-components-files/791/6332.dmesg_5F00_log.txt

The SDK version used is 08_00_00_37.

  • Hi,

    I used I2C-5 on MAIN_R5F. After a while of experimenting, Board_i2c8BitRegRd kept returning non-zero values,

    Can you test communicating on I2C5 bus using the probe function?

    tried from MAIN_A72 (sending i2ctransfer -y -f 5 w1@0x18 0x0c r1).

    Have you also used the I2C detect function as a test?

    Thanks,

    Neehar

  • I did not use the I2C detect function test because it has been running normally for a long time. It returns to normal after I restart the master.
    Do you need the return from the I2C detect function to confirm the issue? I can capture it the next time it occurs, but it is not easy to reproduce. It requires long-term low-temperature testing.

  • Hi,

    I used I2C-5 on MAIN_R5F. After a while of experimenting, Board_i2c8BitRegRd kept returning non-zero values,

    To confirm, you have no issues with the I2C5 bus and are seeing this issue after long time of testing at low-temperatures?

    You do not see the issue testing I2C4 bus at low-temperatures? Or is this environment testing not required for devices on I2C4 bus? 

    Thanks,

    Neehar

  • Yes, my access to I2C-5 in a low temperature environment is normal. Generally, this state will occur after dozens of hours of low temperature testing.

    The serial port on the I2C-4 is not connected to the display, so it has been in a normal temperature environment and there is no problem.

    I also need to mention that the TDA4VM and the two serializers are at room temperature, while the deserializer and the display on I2C-5 are at low temperature.

    I think the problem should be with the display, but I don't understand why the I2C-5 driver of TDA4VM crashes.

  • I learned from my colleague that during the experiment, they do not turn off the power of the TDA4VM, but they do turn off the power of the display, which is off for 23 hours and on for 1 hour. When the display is powered on, it initializes the I2C as a master to configure the deserializer, and then reinitializes as a slave. Could it be that during the configuration, the TDA4VM sends I2C data, causing two masters to appear on the I2C-5 bus, leading to an I2C crash? Is there a way to prevent this crash?

    Is there any way to detect or reinitialize after a crash without having to power cycle the TDA4VM?

  • Hi,

    Thanks for this information, I will review it and get back to you tomorrow. 
    Thanks,

    Neehar

  • Hi,

    Sorry for the long delay on this.

    Is there any way to detect or reinitialize after a crash without having to power cycle the TDA4VM?

    Have you tested resetting the I2C controller?

    Thanks,

    Neehar