# No Acknowledgement from slave device

I am using a FTDI's UM232H usb-i2c adapter to communicate with MAX6615 temperature monitor device and DLVR pressure sensor. I developed a I2C routine to talk to these above mentioned devices. I can able to communicate successfully with max6615 device. But i couldn't be able to communicate with DLVR sensor. The DLVR sensor doesn't acknowledge. I also tried different clock speed. But no luck. Surprising part is , i can able to communicate with the same DLVR sensor using Aardvark adapter. Now i am confused , if it is a SW or HW issue. The code that i developed works with other i2c device but not with DLVR sensor(which proves the code is good).On the other hand, I can able to read from DLVR sensor through aardvark. (so i guess HW is good too).
The slave address i used is 0x28 as mentioned in the data sheet.

Any idea how to debug this issue?

• use a logic scope, or an oscilloscope .... one puzzling thing though ... you said that the device does not acknowledge, that it returns 1 ... does that mean that it does return something? Dec 3 '17 at 23:32
• It returned 1 Because , a slave is required to pull the data line LOW to acknowledge receipt of the data. But it didn't pull the acknowledge line to low . So it returned 1. Dec 3 '17 at 23:58
• your answer is not clear. just because the the data line stays high, it does not mean that the device is functioning ... then a statement returns 1 is made, it means to me that it actually returned a data byte that had a value of 1 ... if there was no actual data byte returned, then you should say that the device did not acknowledge and do not mention any numeric value. Dec 4 '17 at 0:10
• Yea i got what you are saying . modified the question. Dec 4 '17 at 0:15
• i wonder if the aardvark adapter adds something to the data stream. maybe if you forget to set something, it does it automatically. ... if your code is different between the aardvark and FTDI, maybe you used hex with one and decimal with the other. .... what is the slave address of the MAX6615 ? Dec 4 '17 at 0:40

The code that i developed works with other i2c device but not with DLVR sensor(which proves the code is good)

[My emphasis above.]

FYI the emphasised statement above is not true. This is a common troubleshooting fallacy, because it assumes all I²C devices behave in the same way.

Some I²C slaves are more, or less, tolerant to the exact behaviour of an I²C master. It is possible to have software (or hardware) bugs / limitations which only affect some devices, or which require specific I²C master programming. Therefore your statement that your code has been proved good because one type of I²C device works, is false. (Of course your code might, indeed, be suitable for both of your devices - but your test doesn't prove that.)

Any idea how to debug this issue?

There are many possible techniques, depending on your available equipment, skills, experience, time, money etc.

Assuming that you have suitable test equipment, then using a simplified Kepner-Tregoe ATS (Analytical Trouble Shooting) approach, you have a very nice "IS" (i.e. problem) / "IS NOT" (i.e. no problem) pair of equivalent tests:

IS (i.e. test case shows the problem)

using a FTDI's UM232H usb-i2c adapter [...] i couldn't be able to communicate with DLVR sensor.

IS NOT (i.e. test case shows no problem)

i can able to communicate with the same DLVR sensor using Aardvark adapter.

[The ATS methodology, while too complex to explain in full here, includes comparing pairs of "IS" (i.e. is showing a deviation from correct behaviour = problem) vs. "IS NOT" (i.e. is not showing a deviation from correct behaviour = no problem) among other things.]

So gather oscilloscope traces (ideally), or logic analyser traces (if an oscilloscope is not available) from the "IS" (i.e. problem) and the "IS NOT" (i.e. no problem) test cases and compare the traces. That is a starting point.

Since one test works and the other doesn't work, then there must be one or more differences in what happens on the I²C bus, between the two test cases.

Find the difference(s)!

The next steps depend on what you find...

Note that logic analyser traces can't show some electrical problems, and this can mislead you in some situations. At least starting with a 'scope will allow you to confirm and validate the I²C waveform shape (rise/fall times), voltage levels (i.e. pull-ups to correct voltage for the devices on that bus) etc. If all of that is confirmed correct, and the problem is definitely at an I²C protocol level, rather than electrical level, then a logic analyser might be good enough for further troubleshooting.