• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 803 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.

TMP102 Issues

Charlie39929
Prodigy 20 points
Other Parts Discussed in Thread: TMP102, TMP75

Hi,

          I'm trying to integrate the TMP 102 sensor with my Wiring microcontroller.  So far I have been able to write to the senor however I am having issues when reading.  For instance when I attempt to read from the temperature register:  I send a start condition, write to the slave address with the RW bit low, get the proper ACK, write the pointer for the temperature address, get the proper ack, send stop condition.  Then for the second transmission I send the start condition, send the slave address with the RW bit high and then the trouble comes when trying to read the ACK and data that follows.  For the 9th clock pulse, when the clock goes high, the SDA reads low, but when the clock goes low after that and for all remaining clock pulses the SDA reads high.  Am I doing something wrong? Timing? 3.3v versus a wiring 5v? 

Regards,

Charlie

  • 0
    TI__Mastermind 43835 points

    Can you give some more details on your "3.3v versus a wiring 5v?" comment?

     

    As far as timing goes, there are the upper limits of 400khz and 3.4mhz in high speed mode. The lower limit is set by the 30ms bus timeout. Make sure you are not generating an unintentional start or stop condition with your edges.

  • 0
    TI__Expert 7185 points

    Charlie,

     

    Communication with temp sensors is one of the most common of the problems that users encounter.  And yes, my first guess is that it would be faulty timing.  If you post scope photos of the clock and data lines during this erroneous transmission we might be able to make a more specific recommendation on how to fix this problem.

    Matt

  • 0 in reply to Ren Schackmann
    Prodigy 20 points

    Ren,

          Well I'm not exactly sure whether I'm hiting either the upper or lower limits.  I apologize, I'm new to programming with microcontrollers but am a seasoned verteran of java and have some c under my belt too.  First of all if you're interested this is the board I'm using it to communicate with: http://www.wiring.org.co/hardware/ and it describes that hardware details better than I could.  As far as the 3.3 vs 5v comment I made, the main microcontroller board takes power in via usb and then has broken out pins where it outputs 5 volts.  I took that output and put a 3.3 voltage regulator between it and the sensor.  I only mentioned it though because it probably operates on two different logic levels of what each considers high versus low.

    I am puzzled though on how I could be writing fine and it acknoledges but when it comes to reading, after the 3rd frame when the 9th high clock pulse goes low everything on the sda line is high, which indicates to me an idle bus.

    I don't have an o-scope available to provide what the data flow actually is? Is there some way I could assist you in providing more information?

    Regards,

    Charlie (P.S.  I complement you all on the respose time, it was fantastic)

  • 0 in reply to Charlie39929
    TI__Mastermind 43835 points

    I understand now what you're trying to do with the supply voltage. This is a weird setup that should be avoided, but I can't say I feel qualified to tell you definitively that it will or will not work. Is there a reason why you have to use TMP102? We have similar devices which can tolerate 5V, such as TMP75.

     

    I am puzzled though on how I could be writing fine and it acknoledges but when it comes to reading, after the 3rd frame when the 9th high clock pulse goes low everything on the sda line is high, which indicates to me an idle bus.

    The ACK could be bogus. There's no error checking to I2C; it just means the data line was low during that clock cycle. Without an o-scope, it's impossible to know what's really going on.