• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 196 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.

Original question:

TMP103: ACK of Two-Wire Timing Diagram for Read Word Format

TMP103: Random temperature value of 0x00

Edmund de Beer
Prodigy 30 points
Part Number: TMP103

Good morning,

We have a design utilising the TMP103A and in some cases the sensor responds with a value of 0x00. We are requesting the temperature every 150ms on and I2C bus running at 100kHz.

The images below show a valid temperature value being returned and the next read 150ms later shows a temperature value of 0x00. Can you please provide all the conditions under which this sensor will respond with a temperature value of 0x00 so we can try find the cause of this issue.

There is also a little noise on the SDA line but this noise is common to other assemblies that are functioning correctly.

  • 0
    TI__Guru* 91086 points

    Dear Edmund - 

    Welcome to the E2E Forum and thanks for posting!
    The images you posted did not come through - could you please try inserting them again, using the Insert/Edit Media button? 

    Are you doing one-shot conversion every 150mSec, or you have set the part for 8Hz and reading out value every 150mSec? 

    If the latter, each measurement should be ready every 125mSec, so that you are not reading the part in power down. There is a table on page 12 of the TMP103 datasheet - if you could confirm which setting you are using, that would be helpful - or if you are reading in one shot mode, please confirm that. 

  • 0 in reply to Josh Wyatt
    Prodigy 30 points

    Hi Josh,

    Please see the images attached.

    We do not make any configuration changes to the TMP103 when using it. It should therefor be in continuous mode.

    Reading is done by transmitting the address of the sensor with the read bit set high as in the images above.

    The default refresh rate should still be at 0.25Hz.

    I have noticed that touching the ground pin ar moving the cable does make the issue better and worse but in terms of the signal on the scope I cannot see a difference. We have some devices that function perfectly for weeks now without this issue and others where this issue is very common and visible.

  • 0 in reply to Edmund de Beer
    TI__Guru* 91086 points

    Edmund - 

    Thanks! What I see in the first capture is addressed read of I2C address 0xE1, followed by 0x00, 0xFF. I don't see an ACK on the first byte and the second two bytes don't make sense, perhaps because you are not really communicating with the part. Are you 100% positive that you have all -A parts? 

    Would you please try sending 0xE0 to the part and seeing if it ACKs?

  • 0 in reply to Josh Wyatt
    Prodigy 30 points

    Hi Josh,

    The first frame is the address 1110000 with read bit set high resulting in 11100001. The last clock cycle is for the TMP103A to ACK which it does. The second frame is 00111011 which is decimal 59 and corresponds to the correct temperature.

    This is similar to the diagram where the temperature sensor responds with a temperature of 0x00 but the actual temperature is 59 degrees. The last byte the sensor sends is only 0xFF and is always 0xFF regardless of the temperature.

    There is only an MCU and TMP103A on this I2C bus so no other device can ACK.

    I greatly reduced the issue by isolating the chassis from the GND so there might be some external noise coupling to the sensor but we have not been able to measure it. This brings me back to the initial question that if we only read the value from the sensor without first writing the pointer register, under which conditions will it respond with 0x00? Maybe it is indicating an error in the last conversion or an implausible value?

  • 0 in reply to Edmund de Beer
    TI__Guru* 91086 points

    Edmund - 

    I understand the addressing....the 0xE1 is full byte representation of a read on address 0xE0 (which is the full byte write address).

    Neither screen shot shows an ACK to the address, which is a pulse from the part around the 9th clock. 

    I recommend again to send the part a 0xE0 and see if it will ACK.