• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 251 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMP117: TMP117/ TMP117EVM connection timeouts at 60 or 90° process temperatures

TMP117: Crashing the I2C bus when temperature rises

Adrien Veau
Prodigy 10 points
Part Number: TMP117
Other Parts Discussed in Thread: TCA4307

Tool/software:

Hi all and thanks in advance.

I am using a TMP117 sensor on an aluminum core PCB to monitor its temperature as it also carries high-power LEDs.

At ambient temperature, the sensor can seemingly be read indefinitely, but as the temperature rises (sometimes as low as ~33°C or as high as around 65°C), it eventually disconnects and takes the entire bus down with it, with SCL stuck high and SDA low. The microcontroller interfacing with it is an STM32G0B0 through dedicated I2C pins.

Wires to the sensor are quite short (~30cm) and I have seen this behaviour consistently, first thinking that it may be due to poor soldering and thermal expansion, but it persists after resoldering it carefully, which would have me eliminate this option, perhaps prematurely. The sensor always seems to recover after a system reset, even when the sensor is still at "high" temperature.

It is probably a good application for a TCA4307 to help with the stuck bus, but this issue is really bugging me as it is intermittent and seems to be dependent on the temperature. This sensor is used as a safety feature so I must be able to trust it.

Does this speak to someone's intuition ?

Many thanks in advance !

Adrien

  • 0
    TI__Mastermind 43785 points

    Hi Adrien,

    It's unlikely that the TMP117 itself is disrupting the bus. Please check the SCL/SDA under the stuck condition and see if either signal is low. The I2C bus should idle high. You will likely need to use a logic analyzer or oscilloscope to capture the bus activity when the fault happens to successfully root cause the issue. Please share any captures you can get.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 10 points

    Hi Ren, thanks a lot for taking your time with this topic ! Measuring the lines in the stuck state, SCL is high and SDA is stuck low. There is only one other device on the bus (Vishay VCNL3040) which has been stable in my experience. I will try to capture the lines using my oscilloscope, need to figure out an option to capture the right moment !

    Best regards,

    Adrien

  • 0 in reply to Adrien Veau
    TI__Mastermind 43785 points

    The TMP117 would not hold SDA indefinitely; it has the SMBus Timeout feature. It will abandon a transaction that takes longer than about 30ms. You normally wouldn't be able to observe this timeout behavior. If you began a transaction where TMP117 was addressed, such that it ACK'd, and then stopped providing clocks during the ACK pulse, you could see the TMP117 release SDA after 30ms.

    A strict I2C device supports an infinitely low clock rate, and could hold SDA forever if the transaction were stopped at the right moment. I don't see mention of the SMBus Timeout feature in the VCNL3040 datasheet, so it likely behaves this way. For an I2C device without timeout, the only way to get out of this SDA low condition is to send 9 clock pulses or reset/power-cycle. The nine clock pulses are mentioned in the official I2C spec under a section titled Bus clear.

    thanks,

    ren