TMP102: Stops responding part way through returning data

Hi Roger,

Can you get me a zoomed-in image which measures Hold Time? See red highlight in reference image.

Thanks,

Ren

First clock cycle after start, master writing address to TMP102.

Cursors from end of SCL falling edge to SDA falling edge shown at 350ns.

Subsequent clock cycles during master writing address to TMP102

Cursors show delta 420ns.

Hi Roger,

Thanks for the thorough explanation and analysis. I'll need to ask for your patience while I try to re-create your issue on my bench. Please allow me a couple business days to get back to you.

In the meantime, I do have one side comment which may not be related to your issue. It's standard practice in an I2C write transaction for the master to provide an acknowledge following each 8 bit byte. However, during an I2C read transaction, the master should provide a not-acknowledge (NACK) after the last byte it wishes to receive. If an ACK is provided in this instance, the slave device may pull down on the bus in preparation for the next byte.

Thanks,
Ren

Thanks Ren,

It is an odd one. I've been using I2C for 30 years and I've not come across this behaviour before.

I take your point about the NACK at the end, hadn't spotted that one. Wouldn't have thought that it could be having an effect on this particular problem as the start condition should reset everything. What do you think?

The strange thing is that the TMP102 just seems to stop responding. Sometimes this will be when it's part way through sending a byte of data, not necessarily at the byte boundary. It's not doing it on all devices, only on a few boards (maybe 10%). Not seen any which do it at room temperature, only as the temperature rises (but for some this can be from around 30°C, on others it's higher).

A few more traces to look at. In this one the data should be 0x25 0x60. Part way through returning the first byte the TMP102 apparently stops responding and the data line goes high (which the master interprets as all 1's). After the master sends a few addresses with no response, the TMP starts responding again (see zoomed out view at the top).

Zoomed in further showing the point when it stops responding:

FYI, setup is with 1.5GHz active probes, 1GHz 'scope, sampling at 1GS/s, channels set to full bandwidth.

Have done a firmware change to the master to give NACK (rather than ACK) at the end of the cycle.

Still have the same problem.

First image is for the good cycle (showing the NACK):

Second image shows the failure still occurring. Data should be 0x25 0x00:

Hi Roger,

Sorry for the delay getting back to you. Is it possible for you to reduce your update rate? Please note that, by default, TMP102 makes a temperature measurement every 250ms. It can be configured to measure temperature every 125ms. There isn't any value in polling it at fast as you are.

Thanks,
Ren

Hi Ren,

I've tried 2 things:
1. Slowing down the clock rate from 200kHz to 125kHz.
2. Insert a delay of 100us between the end of one cycle and the start of the next.

Both of these appear to work independently, and together.
With both of these in place there have been no more reports of problems in instrument.

I appreciate that continuous polling is unnecessary as the data changes at a much slower rate, however what I don't understand is why I'm getting problems (on some devices at temperatures above 30°C and getting worse as the temperature increases) when, so far as I can tell, I've got everything well within spec.
I'd really like to get to the root cause of the problem, then I can be confident that what I've got in place has really fixed it, not just decreased the likelihood of the problem occurring. I don't want this to come back and bite me with reliability issues in the field in a couple of years.

By continuously polling I appreciate that there are many reads before the data gets updated, however it means that I don't have to put a big counter into the FPGA master as this takes up gates unnecessarily.
If I have to do it then I will, but should it be necessary?

Thanks Ren,
I'll run it at reduced polling rate and monitor for any errors.
This certainly does appear to be a stable work around.
Regards,
Roger