• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 1189 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:

TMP116: Polling the data ready flag seems to clear it inadvertently

TMP117: Polling the data ready flag seems to clear it inadvertently (when using 1-shot mode)

Patrick Klos49
Prodigy 60 points
Part Number: TMP117
Other Parts Discussed in Thread: TMP116,

Similar to the previous post titled "TMP116: Polling the data ready flag seems to clear it inadvertently", I too am not getting a Data Ready for each 1-shot request I submit.

If I set the TMP117 up to perform 1-shot requests once per second, about 16% of the time, the Data Ready bit does not get set and I time out (regardless of if the timeout is 200 ms or 5 seconds!).

If I set the TMP117 to Continuous Capture mode and poll the Data Ready bit every second, I get no timeouts whatsoever.

It's as if either (a) the 1-shot request is not seen or (b) the Data Ready bit is somehow cleared without me seeing it.

I am doing no other operations to the device.

Has anyone else seen a similar behavior from the TMP117?

  • 0
    TI__Mastermind 43755 points

    Hi Patrick,

    I'm not sure that any more can be said than what was covered in the referenced post. These devices share much of their design, so it's no surprise they both exhibit this phenomenon. 

    I would suggest using shutdown mode and one-shot conversions. This actually offers the lowest power consumption, and on-demand temperature measurements that track your polling rate. You're guaranteed to not miss a conversion.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 60 points

    Hi Ren,

    I tried using shutdown mode and one-shot conversions like you suggested, but that didn't really make a difference. The Data Ready is still quite unreliable.

    (If I don't use Continuous Conversion,) I found I can eliminate the missed Data Ready situation if I write the one-shot request to the config register, wait (at least) 100 milliseconds, then poll the config register with 4 millisecond delays between each poll.  I tried a bunch of other combinations, but this was the combination of smallest delays that worked.  If the first delay is 50 milliseconds (or less) or the delay between polls is 2 milliseconds (or less), I still see failures.  I haven't tried a lot of other combinations, but since the [default] conversion takes 124 milliseconds, the initial delay seemed like a reasonable thing to do.

    I'll leave my test setup running in a tight loop over the weekend to verify that it works as expected like this.

    Thanks for your feedback!

    Patrick

  • 0 in reply to Patrick Klos49
    TI__Mastermind 43755 points

    Hi Patrick,

    I recommend sending the one shot command, waiting longer than conversion time, and then reading the temperature data. It isn't necessary to check data ready first. If you feel like you need a very low latency temperature reading, change the averaging mode to 1 instead of 8. This will reduce conversion time to 15.5ms typical. Disabling averaging adds only a couple LSB (8mC each) of noise (Figure 6.)

    Let us know what you decide to do, or if we can be of further assistance.

    thanks,

    ren

  • 0 in reply to Patrick Klos49
    Prodigy 60 points

    Test results from the weekend:

    Of the 2 TMP117s on my I2C bus, I had no timeout (missing Data Ready) errors for at least 52 hours.

    At some point after that, only one of the TMP117s exhibited some Data Ready failures.  Out of the 4.7 million poll requests, 1417 timed out.  I guess 0.03 % failure rate isn't terrible, but it's important to know it's there and needs to be accounted for.

  • 0 in reply to Patrick Klos49
    TI__Mastermind 43755 points

    Hi Patrick,

    If you'd like to investigate this further, I'd setup your microcontroller to trigger an oscilloscope or logic analyzer when it observes a time-out. It would enable us to see what actually happened on the bus at the time of the fault. 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 60 points

    Thanks for the suggestion Ren.  If it really becomes an issue, I'll have to find the logic analyzer and try what you suggest.

    In the mean time, I've been running a test continuously for 168 hours.  I have 2 TMP117 devices on the I2C bus.  Whenever I want to read the temperature, I send the one-shot command, wait 100 milliseconds, then poll the status register for data ready every 4 milliseconds.  When the data ready flag is set, I read the temperature register, then send the shutdown command.

    Each device has performed 1.95 million conversions.  Each device has cycled through over 13.8 million read operations (a bunch of polls followed by a read of the temperature).  That averages about 6 polls and 1 read per conversion.  In all that time, there were 689 "timeouts", but only on one device.  The other device has ZERO timeouts.  (I find that a bit strange and wonder if there's something about the circuit?)

    I'm gonna call this RESOLVED as I think I've characterized the device as well as I can.  My code is prepared to handle retries the very few times it needs to.

    Thanks again for your help.  I hope sharing this on the forum will help others that might run across similar behaviors.

    Patrick