• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 32 subscribers
  • Views 1805 views
  • Users 0 members are here
Support feedback
Options
Options

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.

TMP112: 16-bit Register Read without I2C burst read

Ittiam Hardware
Prodigy 10 points
Part Number: TMP112

Hi,

We are using TMP112AIDRLT device in our design and we need to read the temperature register 0x00, which is a 16-bit register. As per datasheet, we see that we need to perform 2 burst reads to read the 16-bit register. However, we are using a custom I2C IP and it doesn't support burst read (only one byte read per transaction. Is there a way to read the 16-bit register with 2 separate I2C reads each with its own Start and Stop conditions.

Regards,

Raja

  • 0
    TI__Mastermind 42305 points
    Hi Raja,

    No, there isn't another way to read the additional bits. The device offers 1C resolution without the second byte of data.

    Ren
  • 0 in reply to Ren Schackmann
    Intellectual 430 points

    Hi Ren,

    Thanks for the response. As per your reply, I understand that if I perform a single 8-bit I2C read transaction, I will always get the MSB 8-bits i.e. Byte1 of temperature register. Please confirm.

    For your reference, the I2C Master does following operations.

    Start->7-bit Salve address->W Bit->ACK->Pointer Register->ACK->Repeated Start->7-bit Salve address->R Bit->ACK->8-bit Read Data->NACK->Stop.

    Do you see any isssue with above scheme for reading the Byte1 of temperature register?

    Thanks

    Raja

  • 0 in reply to Raja Ashutosh Kedia
    TI__Mastermind 42305 points
    Yes, you will always receive the most-significant byte. Confirmed.

    Overall, the scheme is correct. It is not necessary to perform Repeated Start, because our Pointer Register is retained until power down. It shouldn't be harmful if your I2C IP is implemented correctly.

    Ren
  • 0 in reply to Ren Schackmann
    Intellectual 430 points

    Dear Ren,

    As per above scheme, we are not able to read any data. I captured the waveform at scope and I see that TMP112 doesn't drive SDA low (ACK) after the 7-bit slave address and R/W bit is issued and hence I2C transaction fails.

    We have connected the ADD0 pin to ground, which sets the 7-bit I2C address to 0x48. We have connected supply to 1.8V and the I2C lines are also pulled up to 1.8V via 10K resistors. Please confirm if this is fine.

    As per datasheet, we have connected the Alert pin to 1.8V via 4.99K resistor. However, the datasheet also mentions that the input current to any pin should not exceed 3mA. With 4.99K resistor and 1.8V supply, the Alert pin may sink up to 3.6mA current. Do you think that this may create any issue? If yes, should we replace the pull up resistor to 10K?

    We have seen this issue in 2 boards and it is unlikely that device can be faulty on both the boards. Can you please suggest us steps to debug this further?

    Regards,

    Raja

  • 0 in reply to Raja Ashutosh Kedia
    TI__Mastermind 42305 points
    Hi Raja,

    Please share your waveform.

    Address, 1.8V, 10k resistors, all confirmed fine.

    4.99k should be acceptable but you may use 10k if you prefer. Alert pin could not cause this NO ACK issue.

    Ren
  • 0 in reply to Ren Schackmann
    Intellectual 430 points

    Hi Ren,

    I have attached the waveform below.

    Regards,

    Raja

  • 0 in reply to Raja Ashutosh Kedia
    TI__Mastermind 42305 points
    The device is trying to pull down for ACK, but is not able to. The voltage level is stuck at mid-supply when the master generates the rising edge of the 9th clock (ACK clock.)
    1. Your pull-up might be less than 1kohm instead of the 10kohm you've indicated.
    2. You may have added series resistance to the SDA pin greater than a hundred ohms.
    3. Your I2C Master (or some other device?) could be driving the SDA line high. (This is unlikely as I2C is defined as Open-Drain.)
    4. You may have previously damaged the output driver of TMP112 SDA pin.

    Ren