Other Parts Discussed in Thread: TMP117
Hi,
We are using tmp 117 to sample temperature data.
It reads data rightly, but sometimes it will read wired data like the capture below.
we did not change ambient temperature.

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.
Other Parts Discussed in Thread: TMP117
Hi,
We are using tmp 117 to sample temperature data.
It reads data rightly, but sometimes it will read wired data like the capture below.
we did not change ambient temperature.

Hi mingzhao ma,
Could you please show us the I2C transactions on oscilloscope?
thanks,
ren
I could not provide the capture on oscilloscope for the time being. I'll upload it when it is ready.
but our hardware engineer have had a test on Electrical characteristics and they are inline with datasheet.
I will attach the test data.
On software side, we use One-shot mode, and wait for 18ms for reading data after send a read request.
Best
Hi mingzhao ma,
Are you using AVG=00? By default, AVG=01 which corresponds to 125ms conversion time.
I look forward to seeing the oscilloscope pictures.
thanks,
ren
let's check software firstly.
At the beginning of communication, MCU send 0x0C04 to 0x01(Configuration Register)
and then wait for 18ms to read TMP 117 data.
so I think
MOD is one-shot mode, 11
AVG is No averaging 00.
CONV is 000.
and the conversion time is 15.5ms according to "Table7.ConversionCycleTimein CCMode".
any other points I should pay attention to?
Hi mingzhao ma,
Yes, I agree that 0x0C04 configuration corresponds to One-Shot conversion with 15.5ms conversion time. You should be able to fetch the temperature result after your 18ms wait.
thanks,
ren
Hi, Schackmann
we thought of another probable reason of this issue. that is TMP 117 is accessed while a previous temperature reading function is executing.
what do you think of it?
best
mingzhao
Hi Mingzhao,
TMP117 is not susceptible to this problem that you've described. TMP117 will always report the latest contents of the temperature register. Our competitors have products with the problem you describe, because they refuse to respond at all when they are busy.
thanks,
ren
Hi,
I think application layer should use mutex to prevent this issue.
as our log shows, the error occur when 2 or more procedure is call at the same time.
OK case, read one by one:
=====address read before 541190088 541190089
====buffer address 541190088
====buffer value 12
====buffer address 541190089
====buffer value 175
=====address read after 541190088 541190089
=====gs_uc_temp_data_rx 12 175
=====read_temp 3247
=====ret 0
25.367188
=====address read before 541190088 541190089
====buffer address 541190088
====buffer value 12
====buffer address 541190089
====buffer value 175
=====address read after 541190088 541190089
=====gs_uc_temp_data_rx 12 175
=====read_temp 3247
=====ret 0
25.367188
Failed Case, read at the same time:
=====address read before 541190088 541190089 -》 first read start
=====address read before 541190088 541190089 -》 second read start
====buffer address 541190088
====buffer value 12
====buffer address 541190089
====buffer value 175
=====address read after 541190088 541190089 -》 first read done
=====gs_uc_temp_data_rx 12 175
=====read_temp 3247
=====ret 0
25.367188
=====address read before 541190088 541190089 -》 third read start
====buffer address 541190088
====buffer value 12
====buffer address 541190089
====buffer value 175
=====address read after 541190088 541190089 -》 second read done
=====gs_uc_temp_data_rx 12 175
=====read_temp 3247
=====ret 0
====buffer address 541190088
====buffer value 255
====buffer address 541190089
====buffer value 12
=====address read after 541190088 541190089 -》 third read done error
=====gs_uc_temp_data_rx 255 12
=====read_temp -244
=====ret 0
-1.906250
Hi Mingzhao,
It seems you have resolved your problem on your end. If you need further support for this issue, I would need to see the I2C bus activity during the failure case.
thanks,
ren