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.

TLV320AIC3109-Q1: I2C SDA stuck in low

Part Number: TLV320AIC3109-Q1
Other Parts Discussed in Thread: TAS6424E-Q1, , TAS6424

Tool/software:

Hello TI expert,

We are now having I2C SDA stuck issue on AIC3109. When issue happens, SDA is pulled-low. (SCL is high normally.) In our system, I2C structure is Master (SoC) <-> Slave1: TAS6424E-Q1 + Slave2: TLV320AIC3109-Q1. When we tried to disconnect the SDA between AIC3109 and system, system's SDA back to normal (voltage high). The SDA of AIC3109 is still short to GND. (pull-low by AIC3109 itself.) 

Q1: According to measurement below, if SoC start to send I2C register to TAS6424 before AIC3019's reset is pull-high, will it make AIC3109's I2C SDA stuck? Should SoC start to send I2C "after" AIC3109's reset is pull-high?

(CB means AIC3109, AMP means TAS6424. I2C starts to have transmission in D6, D7 before D3 AIC3109 reset pull-high.)

Q2: According to datasheet "7.3.1 Hardware Reset", if we keep RESET low before all power supplies are stable (measurement below), then pull-high the RESET, does it meet the requirement of 7.3.1?

Q3: Is AIC3109 SDA stuck heard before from other TI's customer?

Thank you.

  • Hi,

    Q1: 

    I2C bus should be able to drive at least 2mA in the low level state and 20mA in the high state.

    Here is what is considered high to the device for AIC3109. This value is given under digital input/output of TAS6424E-Q1 datasheet as well.

    That being said what is the voltage measured at the pin and IOVDD when SDA is stuck. Also what is the resistor value?

    Q2:

    Correct

    Regards,

  • Hello Daveon,

    Thank you to your timely reply. We had found the I2C stuck issue is relative to pull-high timing of AIC3109 RESET pin. Please help to find more information below.

    Figure1: When D3:AIC3109 RESET pull-high, D7:SDA stuck, caused by AIC3109. (possibility: around 200 cycles will get one times.)

    Figure2: Zoom-in to AIC3109 RESET pull-high. The RESET pull-high timing exactly overlaps to I2C register which sent by SoC to AMP IC. Then, SDA is pull-low by AIC3109. I2C SDA stuck.

    Figure3: After tuning the RESET timing to have no overlap to I2C, it has no more SDA stuck issue after 2200 cycle test.

    Q1: Why does AIC3109 has possibility to have SDA stuck if RESET timing has overlapping to I2C bus?

    Q2: Could TI reproduce the same fail mode on your side?

    Q3: If this issue could be reproduce by TI, does TI have plan to update the sequence requirement in datasheet?

  • Hi Jheng,

    I'm glad your issue is resolved. 

    Additionally, it is shown in section 7.2 block diagram that the RESET pin drives the i2c control bus. It is also stated in 7.3 that Reset must be pulled low for 10ns at power up and after this sequence read and writes can properly occur.

  • Hello Daveon,

    Thanks to your reply.

    First of all, in my previous question about 7.3.1, the RESET timing meets datasheet requirement.

    Second, in our measurement, that I2C register's address which has overlapping to RESET is belong to TAS6424(0xD4), but not AIC3109 (0x18).

    Please let me sharpen my question: Does AIC3109's RESET pull-high timing also need to avoid any I2C data transmission even not sent to AIC3109?

    Thank you.

  • Unfortunately yes, the toggle of SDA from the Master during RESET can impact read/writability. If there is no overlapping in the sequence I2C transmission to other devices should not impact AIC3109.

  • Hello Daveon,

    Got it. Could you please kindly help to provide the criteria of timing between AIC3109 RESET and I2C transmission like picture below? Thank you.

  • Hi Jheng, 

    10ms is sufficient time between reset toggle and i2c data transmission to avoid any error.

  • Hello Daveon,

    Thanks to your reply. According to datasheet Rev.A, it seems that this timing requirement is not list in datasheet, which means we have no idea it should be followed until we met this issue and ask TI for help in our project. Please kindly help to find my questions below, thank you.

    Q1: Does TI have plan to update this timing requirement in next revision of datasheet?

    Q2: Are there any other hidden conditions like this one that we need to be aware of when using this codec?

  • Hi Jheng,

    Unfortunately due to the age of the part we are limited to the existing datasheet and collateral, and there will be no future revisions to the datasheet. I2C protocol is standard however, the timing between i2c write and is unique to the device. The datasheet instructs a 10ns pull low of reset before I2C writes.