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.
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:
In reply to TomW:
Oops, forgot to attach the file. Here it is...
I have now obtained a trace of the I2C transaction. See below - this corresponds to a valid temperature reading of 0x0CF4 (25.9 degC). I have now set up my scope to trigger when a negative temperature reading occurs (data byte 1 = 0x0F) to verify that it's not I2C noise, and I'm waiting for the issue to occur.
Regarding your comment "I would suggest modifying the ramp rate to match the specification using additional bulk capacitors" - we have a 100nF bypass capacitor on the VDD signal, which is what Figure 14 in the datasheet specifies. The minimum ramp rate is specified in Section 9 of the datasheet as 0.7V/ms. Is there also a maximum ramp rate?
Here is a snippet from our schematic (there are 4K7 pull-ups on the I2C lines, not shown here):
Also what do you mean by "I am suspecting it has to do something with the read of the temp sensor and the conversion cycle occurring at the same time.". In Section 6.5 of the datasheet it says:
"(3) This specification is provided only to indicate how often temperature data is updated. The LM73 can be read at any time without regard to conversion state (and will yield last conversion result)"
Surely I can read the Temperature Data Register at any time??
I have tried slowing down the polling to once every 225ms as suggested, but the error still occurs. Just for investigation, I also tried a shorter polling periods of 50ms and 25ms, and the error is there. I have managed to capture an I2C trace when the incorrect reading is read:
As you can see, the reading is 0xF5C4, which corresponds to -20.375 degrees C. It's clearly not I2C noise causing this.
At this point I'm not sure what I can do. Seems like the LM73 is intent on giving me incorrect readings occasionally, and I will have to do something clever in software to get around the issue, like disregarding a reading if it is outside a certain 'valid' range and just use the previous reading to "ride through" these incorrect ones.
I've tried it once more with the 225ms polling rate on the 10 devices we have here, and the problem still occurs. I can't explain why you're not seeing it too. Are you sure the issue doesn't occur at all, or it just takes longer to occur? For me the issue can take up to a few hours to occur normally (i.e. with 100ms polling period), so I would expect that with 225ms period the issue would still occur but might just take longer, because there is a lower chance of reading the Data Register at the wrong moment. I had to leave the 10 devices running overnight to see the failure on them with a 225ms polling period.
Sadly returning the part to TI is not something we can easily do as they are surface mounted to our devices. Unless we can find a cause for this, I think I am just going to have to 'ride through' the issue in software. I can detect when the temperature reading is outside of an expected range and ignore the reading (use the last known good reading instead), until the LM73 starts giving me good readings again.
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.