• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 47 subscribers
  • Views 1397 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.

TLA2024: I2C communication is failed

Nariaki Ogasawara
Intellectual 1215 points
Part Number: TLA2024
Other Parts Discussed in Thread: TCA9548A, TCA6424A, , TPS2024, ADS1015, ADS1115, ADS7823, ADS7142, ADS7924

Hi team,

 The customer has connected three devices on I2C, but TLA2024 was I2C communication failed, The other devices, which are TCA6424A and TCA9548A, don't have communication failed.

 I2C configuration is below.
 Sleve Addr : 48h (ADDR Pin : GND)
 Vdd : 3.3V
 I2C BUS Pull-up Resistor : 2.4K Ohm

 I attached the waveform, please check this.
 I have some questions.
 1. The 9th clock looks too slow. 
     Is cause of the I2C communication error TLA2024 time out?
 2.  Do you have anything other than this?
 3. How to fixed this issue?
 4. If TLA2024 is difficult to fix this issue, is there any other candidate device? 

Regard,
Ogasawara

Hi team,

 The customer has connected three devices on I2C, but TPS2024 was I2C communication failed, The other devices, which are TCA6424A and TCA9548A, don't have communication failed.

 I2C configuration is below.
 Sleve Addr : 48h (ADDR Pin : GND)
 Vdd : 3.3V
 I2C BUS Pull-up Resistor : 2.4K Ohm

 I attached the waveform, please check this.
 I have some questions.
 1. I2C ACK response looks too slow.
     Is this cause of I2C communication failure?
 2. Can you think of anything other than this?
 3. How to fixed this issue?
 4. If this problem is in TPS2024, is there any other device? 

  • 0
    TI__Guru* 92655 points

    Ogasawara-san,


    I'm not sure what the problem is in communication, but it looks more like a problem with the master. There are several things that I see that don't make sense to me in the communication.

    1. The 9th bit (should be a TLA2024 ACK) occurs 50ms after the address byte. Is there a reason that this is so late? I don't think there is a timeout on the I2C of the device, but it seems unusual to wait so long after the address to try to send the 9th bit.

    Have they tried to communicate with the TLA2024 without such a large delay for the 9th bit? I'll check with the designer on the I2C timeout.

    2. Another thing that I noticed is that the 9th SCL pulse looks different than the other 8 pulses. For the I2C communication, the master controls the SCL and it's timing. For the plots, they look different in shape, as if SCL is controlled differently for the 9th pulse compared to the other 8. Note that for the first 8 SCL pulses are about 5us wide. For the 8th SCL pulse, it is about 1us wide.

    3. Have them check the ADDR pin, but it looks like the TLA2024 never ACKs the I2C communication. Note that on the 9th SCL pulse, SDA isn't pulled low. SDA does go low, but 6us after the pulse. SDA is pulled down and then released 11us later. It may be the master that does this, but there are no SCL going to the TLA2024 at that time to pull down and release the SDA line.

    First check to see if they can get a normal I2C communication to the TLA2024, with out such a large delay between the 8th and 9th pulses. If that doesn't work, we can try something else for the debug.


    Joseph Wu

  • 0 in reply to Joseph Wu
    TI__Guru* 92655 points
    Ogasawara-san,


    I checked with the designer and he says there is a timeout built into the digital section of the device. The timeout should be about 28 ms. This should account for the missing ACK after the long delay between the 8th and 9th bit transmission.


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Intellectual 1215 points

    Hi Wu,

     Thank you for your response.
     It is difficult to improve the customer application.
     The customer is looking for the device that do not time out, because TCA6424A and TCA9548A are communicating.
     But we can not find time out of ACK in any devices datasheet.
     Can you tell me the devices that do not time out with the same performance as TL2024?

    Regards,
    Ogasawara

  • 0 in reply to Nariaki Ogasawara
    TI__Guru* 92655 points
    Ogasawara-san,


    I'm sorry that the timeout doesn't work for the customer. I don't think the timeout was listed in the datasheet. However, in the timing requirements, the minimum SCL clock frequency is listed as 10kHz. This implies that the max clock period would be 100us.

    The ADS1015 and the ADS1115 are similar devices, but will also have this timeout.

    For a replacement, what features are your customer looking for. Do they need 2 differential channels or 3 single ended channels? Do they need the internal voltage reference and PGA gain? I'll need more information to help select a device.


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 20 points

    Joseph Wu-san

    thank you for your answer.
    I need a single end of 2 channels or more. Although it is better to have an internal reference, the PGA gain is unnecessary.
    I am considering using ADS 7142 or ADS 7823 instead of TLA 2024. Are there timeouts for these?

    Yoshiaki Ukiya

  • 0 in reply to Yoshiaki Ukiya
    TI__Mastermind 24940 points

    Hello,
    I am confirming with the design time regarding a timeout not being present in the ADS7142 or ADS7823.

    Have you also looked at ADS7924, this is a 4 channel mux SAR ADC; or the ADS7828, this an 8 channel variant of the the ADS7823.

    Regards
    Cynthia

  • 0 in reply to Cynthia
    TI__Mastermind 24940 points

    Hello,

    I have confirmed that the AD7142 does not have a timeout feature. I suspect that all the mentioned devices, ADS7823/8, and ADS7924 do not have it either.

    Regards

    Cynthia

  • 0 in reply to Cynthia
    Prodigy 20 points
    Hello
    I confirmed the operation with ADS7823 - 28EVM. The result was no problem. Thank you very much.