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.
Part Number: LM73
As the title suggests, I am seeing abnormal temperature readings with the LM73:
- The abnormal readings are not directly after power-on, but after a certain amount of time of valid readings. I have 10 different units and they all exhibit the failure within about 2 hours of run time, but the exact time varies.
- The abnormal readings of the Temperature Data Register are usually around the same value: 0xF5XX or 0xF6XX, which corresponds with a negative temperature (around -20 degrees C). The temperature readings before the incorrect ones were around 35 degrees C. Once an incorrect value is read from the LM73, the temperature readings return to the valid range (~35degC) again.
- The problem is not I2C noise, because the microcontroller is interfacing with other I2C peripherals on the same I2C lines with no corrupted data at all. Any I2C noise would be expected to affect all devices on the same bus. The microcontroller is not seeing any problems with the I2C protocol itself (misplaced start/stop conditions, bus arbitration or NACKs).
- The VDD ramp rate is faster than the minimum of 0.7V/ms specified in Section 9 of the LM73 datasheet. The VDD takes about 400us to rise from 0V to 3V3, corresponding to a ramp rate of about 8V/ms. The microcontroller software is also performing the software reset sequence in Section 9 of the datasheet, to prevent any problems with corrupted data due to POR ramp-rate.
This problem appears to be very similar to that experienced by others on this forum, however I've not been able to find a definitive answer in those posts as to why the LM73 behaves in this way.
In reply to TomW:
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Amit Ashara:
But surely, polling the data register at any periodic rate is eventually going to align with when the sensor is performing the temperature conversion, because the host software's clock and the LM73 clock are not synchronized. So I don't understand why the 2x polling rate would prevent this from happening?
I will see if we can return a sensor that is exhibiting the fault to you, so you can do some more diagnostics.
Right, in that case I think I misunderstood the whole idea. You're saying that the 225ms poll rate doesn't prevent me from getting a corrupted reading in the first place, it just means that after a single bad reading I can guarantee that the next reading is a good one, correct?
So could you confirm, when you said you ran it on your end with a 225ms poll rate over the weekend and saw no errors - did you see *any* corrupted readings, or did you mean that you did see single occurrences of bad readings, but they were corrected upon the next read?
On my end, I am definitely still seeing single occurrences of corrupted readings with a 225ms poll rate.
TomWRight, in that case I think I misunderstood the whole idea. You're saying that the 225ms poll rate doesn't prevent me from getting a corrupted reading in the first place, it just means that after a single bad reading I can guarantee that the next reading is a good one, correct?
No. What I am saying is when a read corrupts the conversion data, the corrupted value gets loaded into the temperature register for the next read cycle. Howvever when the next conversion happens the corrupted value gets "corrected", subsequently to which the read is always correct.
Yes, I can confirm that the reads were no longer corrupted with ~225 ms of read interval.
On your side, is there any timing variation you see on the 225 ms? I.e. it is sometimes 224 and sometimes 226 ms?
Yes, I did manage to test with a longer interval between polling. Due to the design of my scheduler, the easiest for me is to pick multiples of 6.25ms, so I tried both 231.25ms and 237.5ms. I saw occasional invalid readings with both of them, so no difference from the 100ms default rate.
However, since then I have managed to implement a software workaround where I store the previously known good reading, and if the new reading differs by more than 0.5 degrees C from the previous reading, I reject the new reading and use the old one instead. I do this a maximum of 3 times and then I flag a downstream fault. This appears to work perfectly in "riding through" these occasional bad readings from the sensor. Since we know that under normal operating conditions, the PCB temperature can never change by more than 0.5 degC within 100ms, we are satisfied that this solution will work for our needs.
I think we can go ahead and close this thread. Many thanks for your time and effort in trying to debug this.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.