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.

TLV320AIC3104: accessing i2c fail with tlv3104aic 3104

Part Number: TLV320AIC3104

Hi, 

Our device use 3104 to deal with audio application. each device's audio function is ok before deliver to customer. but we have received any repsonding that audio function is not ok. we check the device and find i2c accessing fail for 3104. Aduio function is ok after replace a new chip. Could you pls review the hardware schematic diagram for us?

many thanks.

wayne.

  • Hello Wayne,

    Thanks for reaching out. In general, the schematic looks good. There are missing pull-up resistors on the SDA and SCL lines which is likely the cause of the failure. We recommend a pull-up resistance of around 4.7kOhms for most applications. You can see how the method for I2C Bus Pull-Up Resistor Calculation here.

    Best,
    Andrew 

  • Hello Andrew Jackiw 

    thank you for your reply.

    about the pullup resistance, I found i lost some info for the schematic above. our sehematic use 2.2KOhms as the pull-up resistance. Is that ok?

    ps: I am  software engeer.

    Regards

    Wayne

  • Hi Wayne,

    A 2.2k Pull-up resistance should be ok. Please check that the Master device is using the correct Slave address for the TLV320AIC3104, and that no other devices are using this address. 

    The TLV320AIC3104 responds to the I2C address of 001 1000 (See section 10.5 "Programming" of the datasheet for more information). 

    How are you receiving the I2C accessing failure error? Also, what does "audio function not ok mean" specifically?

    Best,
    Andrew

  • Hi Andrew

    I am sure master device has used the correct salve address, because we use two 3104 chips for talkback, and before I found the i2c accessing error, the talkback is well, we can hear each other on both sides. when i2c accessing error occours, it can recover after restart the device, but some time it can not recover even we restart the device again and again, except replacing a new chip. so i suspect the chip has been damaged.

    Regards,

    Wayne

  • Hi Wayne,

    Thank you for the description. From my understanding, it sounds like your setup works normally, but sometimes there is an I2C accessing error. When this happens, you reset the device and it comes back. However, sometimes the device does not come back and only replacing the chip fixes the problem.

    1. How are you resetting the device?
      1. Is this a power cycle, and is the device's Reset pin held low for at least 10ns after the power supplies fully come on? (As recommended in 10.3.1 Hardware Reset of the datasheet).
      2. If possible, please try powering on a failing device and hold pin 31 low for a few seconds manually with a short to ground. 
    2. Does "NC" on R431 and R432 mean "No Connect". 
      1. If these resistors are populated, my concern is that there are two outputs driving the same node (HPL and HPR). If the MAX97220A is driving the HPL/HPR node while the AIC3104 is unpowered then it may be damaging the device, or causing an unknown power-up condition. 

    Please let me know the results.

    Best,
    Andrew

  • Hi Andrew,

    1. how to reseting the device?

     power down and then power up .

    2. Does "NC" on R431 and R432 mean "No Connect"?

     yes. Hardware engneer has confirmed these two reststors are not populated on the board that 3104 has been damaged.

    Regards,

    Wayne

  • Hello Wayne,

    1. Resetting the device
      1. Please power on the device. Once all supplies are stable and at their proper values, manually hold the RESET pin held low for at least 10ns after the power supplies fully come on. (As recommended in 10.3.1 Hardware Reset of the datasheet).
      2. If possible, please try powering on a failing device and hold the RESET pin (pin 31) to GND for a few seconds manually with a short to ground.
      3. Remove the short and see if the device comes back ad can be configured.
      4. If the device is configured without proper power sequencing (i.e. while various supply rails are powering on) this can cause the device to behave abnormally.
    2. If R431 and R432 are not populated, then this area is not a concern.

    Please attempt the items in bold and let me know the results.

    Best,
    Andrew

  • Hello Andrew

    About resetting sequencing, we pull down to hold the reset pin low for 1 second, and then pull up it to hold high state in software. So I don't think the issue is caused by it. As the matter of fact, 3104 runs well before it was damaged.

    1. If possible, please try powering on a failing device and hold the RESET pin (pin 31) to GND for a few seconds manually with a short to ground.
    2. Remove the short and see if the device comes back ad can be configured.

           // 3104 can not be recover.

    Regards,

    Wayne

  • Hi Wayne,

    The steps above are to make sure that the device is properly reset after the supply rails are stable and to make sure the CODEC is not being configured during a marginal start-up condition. The schematic you have shared looks good and it sounds like the application is functional when sent to the user. 

    If you have tried the steps above and the device still does not recover, then it looks like the issue is not relate to the information you have provided here (power sequencing, schematic or the CODEC). Please evaluate the possibility of the end user's application causing device damage or let me know if there is a specific event that causes a good device to fail. 

    Best,
    Andrew

  • Hello Andrew

    Thank you for your help.

    The worse thing of this issue is we do not known how it happened.

    We will go on to focus this issue.

    Thanks again.

    Regards,

    wayne

  • Wayne,

    We are happy to help. I will go ahead and close this thread for now. If you find more information in the future, please feel free to open a new thread or return to this one.

    Best,
    Andrew