TMP112 Conversion

Hi Bobby,

We received your question. Will review and get back to you.

Mayrim

Hi team,

We are discussing this issue via email.

Mayrim

Hi Bobby,

The conversion time is a constant 26mSec but the delay between conversions can be changed.  When a command is sent to change the conversion time (the delay between the 26mSec conversions) a new conversion is started.  We verified this be setting a long delay between conversions then setting the delay shorter in the middle of the conversion.

May I ask what your application is?  It sounds like you are trying to sync the temperature up with some event.

Regards,

Jamieson Wardall

Sensing Aplications

Thanks for your quick response. We are currently using your TMP112 on several products and on a very, very rare occasion  (1 in a million+ and not repeatable), the TMP112 conversion did not end. I issue a one-shot conversion command and put my processor to sleep for about 500 msec to conserve battery. At the end of the 500 msec nap, I check the OS bit being set before reading the temperature data. In that particular device the OS bit remained low.  What I wanted to do, if this issue happens again, is to issue a general reset to the TMP112, wait a few milliseconds and start another one-shot conversion as quickly as I can.  I was not sure how long I have to wait  from general reset before issuing another one-shot conversion. Do you have another suggestion on what I should do if the OS bit gets stuck?

Hi Bobby,

What about putting the device is SD (shut down) and using the the OS(one-shot)?  This will complete one conversion then put the part back into SD.  I think this will achieve what you want.

Regards,

Jamieson Wardall

I set the SD bit everytime I do a one-shot conversion so that the TMP112 shuts down at the end of each conversion. In that very rare occasion, the OS bit remained low even after a few retries. When something like this happens, I do up to 5 retries i.e. I issue another one-shot conversion command, wait another 500 msec and check the OS bit again to see if it gets set. If the issue remains after 5 retries, an error flag is set in the firmware and the temperature data is set to an invalid value. All other samples (about 2000) were all OK and the problem occured after the device had already taken about 700 samples. I don't know what caused it and I can't reproduce it. Is it possible that somehow the internal register got stuck in a weird state? This is why I wanted to do a general reset when some issue occurs to get the intenal registers back to a known state. Do you have any other suggestion(s)? Again this is very rare but enough to cause some worries within the company. Collectively, we must have done over a million samples and I only saw this sample problem 3 times.

Hello Bobby,

I can't think of anything that would cause this.  Is it possible that the command wasn't received by the device correctly?  For the devices that this happened to what did you do to resolve the issue? 

Can you send me a schematic and configuration of the TMP112? Are you running in high-speed mode?

We can take this offline in email.  jw@ti.com

Regards,

Jamieson Wardall

The TMP112 is running at 4Hz (default). When I issue a one-shot conversion command, I set byte 1 of the configuration register to "0xE1" and byte 2 to "0xA0". I then check for the OS bit to be set before reading the temperature data. I did not get any I2C error and the OS bit was "low" which indicated that the conversion started so I am assuming that the device received the command correctly. I still have not resolve this issue because I cannot reproduce the problem so I am looking for explanations or other ideas to prevent this from happening. I will send you the schematic. Thanks for your reply.

Hi Abhi,

In that particular sampling case, the OS bit remained low throughout the 5 consecutive retries. After the firmware had flagged the error and stored an invalid temperture value, our device waits for the next sampling interval (30 seconds) before issuing another conversion command. During that next sampling and all other samplings, the TMP112 OS bit worked as expected. Our SCL clock frequency is about 38 kHz.

Bobby

Hi Abhi,

You are correct. Our sampling interval is programmable. When the issue happened the device was programmed to take a temperature sample every 30 seconds. If an error occurs, the firmware will do up to 5 retries with 500 msec delays in between. If the error persists after 5 retries, then the firmware will not read the temperature value from the TMP112 and will store a  -199.0 deg F value into the buffer (which is beyond the temperature ranges that we are measuring) so that after downloading the samples to our PC application, we can easily see on our temperature plot where and when the error occured.

Bobby

Hi Mayrim, Jamieson and Abhi,

Thank you all for your responses. We have not seen that problem again but I will continue to investigate and will let you know if I find any explanation on why that condition occured.  

Bobby