• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 670 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.

HDC1010: I2C communication failing on many parts

Gavin Macpherson
Prodigy 100 points
Part Number: HDC1010

Hi, I have a system where 3 HDC1010 sensors share one I2C bus. They are hardwired to addresses 0x64, 0x65 and 0x66. On multiple boards one or more of these parts fail ACK when I try and communicate with them. We have also had parts that would ACK to begin with fail after repeatedly being polled which is frustrating. Most boards have at least one in 3 not working and some have none working. Often when we replace the sensor with a new one they will work

Here are the details:

  • VDD = 5V
  • Clock rate is 100kHz
  • There are pullups resistors beside each device on the SCL and SDA lines
  • SCL and SDA are carried over a long coaxial cable from the master but I have checked that the signal at the sensors still looks good

What we have tried:

  • Changing the pullup resistors from 1kohm to 4.7kohm
    • Tried with only one set of pullups as well
  • Shortening the cable
  • Running at 400kHz

But only replacing the sensor seems to fix the problem.

Attached a PPT with oscilloscope captures and the schematicSensor Debug.pptx

  • 0
    Prodigy 100 points
    Sorry meant to say the addresses are 1000000, 1000001 and 1000010
  • 0 in reply to Gavin Macpherson
    TI__Genius 9675 points
    Hi Gavin,

    Looking at the powerpoint you provided. It seems that the logic levels on your SDA look off.

    Do you have any series resistance on that line? If so, can you remove it?

    Jalen
  • 0 in reply to Jalen Tate89
    Prodigy 100 points

    Hi Jalen,

    No series resistance except long tracking and cables that may add some, but as I said, shorter cable doesn't help.

    I see what you mean though, the logic level starts to droop, but it is still high enough to be read as a logic high (4.3V). I could maybe try changing the bulk decoupling capacitance on the supply line to see if I can reduce the droop which is transient.

  • 0 in reply to Gavin Macpherson
    TI__Guru* 91206 points
    Gavin -
    Jumping in here - so the way you have this arranged - with 1k Ohm pullups on all three parts, you have effectively 333 Ohms and with 4.7k Ohm pullups on all three parts, you have effectively 1.56k Ohms....since those combinations result in the pullup being fairly strong - perhaps try just one set of pullup resistors for the bus.

    you can reference this application note on the topic as well, in case you want to calculate it, based on your board. www.ti.com/.../slva689.pdf
  • 0 in reply to Josh Wyatt
    TI__Guru* 91206 points
    Gavin -
    Since you have indicated none of this has solved your issue - can you provide your schematic and layout?
  • 0 in reply to Josh Wyatt
    Prodigy 100 points
    Hi Josh, we are still debugging, I probably won't be able to look at it again until later next week. The single 4.7kohm pull up didn't work when I tried it. I have sensitive information on my schematic so I can't share it on this forum, although I can send it to you if you keep it private.

    Thanks
    Gavin
  • 0 in reply to Gavin Macpherson
    TI__Guru* 91206 points
    ok - understood and accepted. You can send it to: josh.wyatt@ti.com
  • 0 in reply to Josh Wyatt
    TI__Guru* 91206 points
    Gavin -
    in case you sent the drawings via email, I did not receive them yet - we do want to make sure we help all we can to get this resolved with you.
  • 0 in reply to Josh Wyatt
    Prodigy 100 points

    Hey I managed to fix the problem by using a different I2C master. I needed to shift the SCL waveform by a 1/4 wavelength though to get all of the sensors working, not sure if that is explained well in the datasheet.

  • 0 in reply to Gavin Macpherson
    TI__Guru* 91206 points
    Gavin -
    sounds great - i wonder if your cable length had anything to do with that. The I2C communications are industry standard based - if you had a capture of exactly what you had before and after it might help explain what you ended up having to do.
  • 0 in reply to Gavin Macpherson
    Intellectual 440 points

    Hi Gavin,

    Good job with the fix but you might just have been lucky.

    I looked at your oscilloscope captures but there is not enough detail on timing, location of probes, etc to really dive in to finding a suggestion for

    1. knowing exactly what the problem is and

    2. defining a permanent solution to the unknown problem that won't haunt your project down the road.

    Now that you have a working system and a broken system to compare, you might consider investing in a logic analyzer to sniff around on the sensors and main uC lines. Then, you can break the system and fix it again but in a different way, and reliably predict future failures should you get really tight on headroom in your design but lose the option of choosing a unused peripheral as an option again.

    Nice sensor btw, one of my favorites.

    Good luck w/ your humidity project!

    patrick

    Attachement: logic analyzer screen shot

    Here you will find specific timing of waveform and data packets. Knowing these values will help make the transition into different frequencies on the bus. 1/4 wavelength on one frequency will change the data packet timing to another. Using an oscilloscope to debug data lines  reminds me of my old Tektronix 2467 analog scope and HP 546 Logic Analyzer ... (painful). The USB logic analyzers today are amazing.

  • 0 in reply to Patrick Blanchard
    Prodigy 100 points

    Thanks Patrick,

    For anyone who is curious, below is a capture of the "configure" write from the master's digital scope. Unfortunately not looking at the sensors at the end of a length of cable and a lot of tracking, measured value in yellow, expected value in blue. In order to get all the sensors to ACK, instead of the data transitioning on the rising edge of the SCL as we had in the previous master (unable to configure) I shifted the rising edge of SCL back by a 1/4 period but kept the same duty cycle.

    Fairly confident it isn't just luck, I used "burst pattern until fail" at 25°C and -20°C and the communication didn't fail. I could check more sensors but I am confident the communication is much more stable than it used to be and one of the reasons we use three is for redundancy even if one did fail.

    Cheers,

    Gavin

  • 0 in reply to Gavin Macpherson
    Intellectual 440 points

    Nice work Gavin! For some reason I can't view the image mentioned regarding your capture. when you have time would you mind posting a png version on the forum or sending me a copy to patrick@iphysi.com ? It would help me better understand your conclusions. -patrick