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.

TMP102: I2c reset issue

Part Number: TMP102

Tool/software:

Hi Team

I have ask a question about tmp102 at  TMP102: I2C error reset . In that question, HarryG suggests lowering SCL for more than 30ms to reset the I2C interface of TMP102. We have tried and found that in some scenarios, the I2C interface cannot be reset. We also used sending additional clocks to resolve the I2C deadlock after lowering SCL, but found that SDA continued to send data after sending the clock. At the same time as sending the clock, the host actively raised SDA to simulate NACK, but according to the waveform, TMP102 did not stop sending data after NACK, but continued to send data.

In the datasheet, host should send ack at the end of first byte. I want to know if we send a NACK, will tmp102 release the I2C bus? And why the lowering SCL can't release I2C bus?

  • This is the waveform of the I2C deadllock. The first part is to lower the SCL by 50ms, and the second part is to send 12 clocks to try to resolve the deadlock.

  • Hello Li,

    Could you please provide the full waveform displaying the entire transaction behavior? This will help me understand what the host and target are doing during the transaction.

    Regarding your question about sending a NACK so the TMP102 releases the I2C bus, the host should also issue a STOP condition to the TMP102 to indicate an end to the transaction and should release the bus.

    Regards,

    Harry 

  • Helllo HarryG,

    We forcibly triggered the host MCU restart during the I2C read operation. After the restart, the host first lowered SCL for 50ms, then raised SDA and sent 12 CLK.

    The waveform is a bit difficult to capture,  I will send it If catch it during the test.

    Best regards.