I2cdetect -y 1 shows device address 0x48 but not on trace

Logic 2 Software
1

Running Logic8Pro firmware version 2.3.51 with SparkFun TMP102 board. The trace shows addresses are written then read up to 0x3F and then no addresses until 0x60. The TMP102 addr pin is grounded so it is address 0x48. Why are the Logic trace writes and reads from 0x40 to 0x5F not showing up ?

root@fido1:~# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – 48 – – – – – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
root@fido1:~#

2

@dyen Based on the limited information provided, I’m not quite sure what could be causing this issue. I’d be happy to help if you can provide more information.

  • Can you share your capture file? (.sal file format)
  • In case relevant, what low level analyzers and extensions are you using?
  • When sharing your capture file, and in case it’s not obvious, can you provide a description of where we can find the error?
3

Hi Tim R., There is a TMP102 i2c device whose address is 0x48 and that is shown by: i2cdetect -y 1
However on the .sal trace linked here, you see address writes and reads up to and including 0x3F and then writes begin again at 0x60
but I would expect to see writes from 0x40 to 0x5f and the corresponding read for 0x48.

I’m using i2c analyzer with SCL on red, channel 2 and SDA on orange, channel 3, their black ground lines are grounded. Channel 0 black and Channel 1 brown are not used.

4

Hi Tim R. Here is the drive link to .sal in case it wasn’t in previous email. Thanks, Doreen

SessionTMPonly.sal

5

A wild guess, but something that is always worth doing with I2C: ensure the logic analyzer’s glitch filter is turned on for the clock line. 100ns or there abouts should be about right.

6

@dyen Thanks! I’ve sent a request to access the file.

In the meantime, @P.Jaquiery brings up a great point. I’ve provided a support article below that shares more details about this (under the section " Common Issus with Noise Around Clock EdgesCommon Issus with Noise Around Clock Edges").

7

@dyen I had a look at your capture file. There were a few glitches / pulses in your CLK line (~4ns long on average) that was interfering with the decoding process. @P.Jaquiery 's suggestion of implementing a 100ns glitch filter on the CLK line should do the trick.

8

Hi Tim and P. Jaquiery, Many thanks for the i2c glitch filter 100ns worked. I can now see all the i2cdetect -y 1 and also could see the trace for reading TMP102, # Remember to give the argument number of loop iterations for $1
for ((i=1; i<$1; i++))
do
echo “Index is” $i
i2cget -y 1 0x48 0x00 w
sleep 1
done

1 Like