I2C port name and i2cbus number

From this it seems that I’m doing things right, except that I should be using i2cdetect -y 1, instead of 2.

However, I am using the stock kernel, not Grinch. L4T 21.4

I also tried using gen1_i2c using a bi-directional level converter (1.8 to 3.3V). I see the stock behaviour when using i2cdetect -y 0, without my slave device :(

Have I missed a step like having to activate the expansion header or something?

Try:

$ i2cdetect -y -r 0

Yes, I’ve tried that as well.

I’ve tested a second i2c slave device. I had no problem using it on the Raspberry Pi, but with the Jetson I still get no response.

I’m going to reflash to an older OS version and maybe try the Grinch.

Which pins are the device connected to, and does the device work with the Gen2 I2C output? What type of device are you trying to use?

Hi Kangalow.

Here’s where I’m at:

With a known working device (7 segment display Adafruit 0.56 4-Digit 7-Segment Display w/ I2C Backpack - Blue [STEMMA QT / qwiic] : ID 881 : $11.95 : Adafruit Industries, Unique & fun DIY electronics and kits) I have succeeded in getting it to work on i2c0 (J3A1: SCL on pin 21, SDA on pin 23, J3A2: SCL on pin 56, SDA on pin 59) and i2c4 (J3A2: SCL on pin 50, SDA on pin 53) with (i2cdetect -y -r 0, i2cdetect -y -r 4), both at 1.8V and also with a logic level converter (https://www.sparkfun.com/products/12009) to put the slave at 3.3V.

Now using i2c4 with the logic level converter, I have tried to connect to the i2c port on a GoPiGo robot board (GoPiGo3 is a Raspberry Pi Robot Car for Learning Coding). Pinging it with i2cdetect produces no response. I have verified that I can get a response on i2c from the GoPiGo when using a Raspberry Pi. Is there potentially a speed issue here? Do I need to set a bus speed somehow?

Further, I have not been able to get either of the 3.3 V busses (Gen2, J3A1: SCL 18, SDA 20, or Cam, J3A2: SCL 11, SDA 8) on the Jetson to communicate with any device, either with or without the level converter (would use 3.3 V on both sides of the converter).

Ok, a little bit more info. It turns out that the GoPiGo can’t operate at 400 kbit/s it needs 100 kbit/s. I’ve had a look at my device tree and I see that i2c1 (Gen 2) should be operating at 100 kbit/s and 3.3V… exactly what I need.

And yet this bus does not respond to either of my devices.

Throwing a scope on the bus I see a nice clear clock signal, and only noise on the data line. I have made no changes to the device tree or added any resistors or anything. This is pretty much a stock flash of R 21.4

The wired connections are super simple, just 3 lines. J3A1:18 SCL to the device SCL line, J3A1:20 SDA to the device SDA and a ground connection from J3A1:2.

Where is the device being powered from? On most of the devices I’ve used, they require power and common ground.

The 7 segment display responds to i2cdetect without a power connection. But I tried adding a 3.3 V power line from J3A1:16 and no it still doesn’t work.

So I’ve been successful with the 1.8 V busses, but not with either of the 3.3 V busses. This makes me think that either there’s some configuration setting I need to play with or there’s a hardware problem.

i2cdetect in i2c3 does not return the same thing listed on the eLinux i2c page: https://devtalk.nvidia.com/default/topic/887209/dead-devices-on-i2c3-/#4702236

Maybe that’s related?

What version of L4T are you running, and are you using the Grinch kernel?

I’m running R21.4. No Grinch.

I tried Grinch on R21.3, but that didn’t help.

I think I may not be the only one with an issue: https://devtalk.nvidia.com/default/topic/811893/tegra-i2c-pin-is-not-detecting-my-slave-device-/#4702231

Procoller simply gave up an used a different bus.

On the Jetson TK1 I’m looking at, i2c bus 3 is not the same as described on the eLinux page either. However, the Gen2 I2C on pins J3A1:18 and J3A1:20 are on a different bus all together, I2C Bus #1, i.e.

$ sudo i2cdetect -y -r 1

should display the address of a device connected through those pins.
Analagously, J3A2:8 & J3A2:11 are on I2C Bus #2:

$ sudo i2cdetect -y -r 2

The -r flag tells i2cdetect to use a smbus command to read, so it does a little more work to try to get a connected device to respond.

If you are using a Gen2 with 3.3V logic signal from the Jetson, you do not need a level converter to interface with another 3.3V signal level device. Note that the signal level can be different from the voltage that actually powers the device itself. As an example, a LidarLite uses 3.3V signals for I2C but requires 5V to drive the unit.

Yes, I understand all of that.

I cannot get a device connected to either the Gen2 or CAM busses.

I had just thought that maybe if there was a problem on i2c3, then that might indicate other problems that could be affecting Gen2 and CAM.

Hmm, I’m out of ideas. I’ll get one of those displays and see if I can get it to work on the 3.3V I2C signals.

Ok, I’ve gotten the devices working with the CAM line, although I was disappointed to discover that it’s only a 1.8 V line, not 3.3 V as some documents suggest. I know that the line can take 3.3 V, but if I understand it correctly I would literally have to desolder the pullup resistors and add new external pullups to the 3.3 V line. Is that correct?

From what I can see my Gen2 line must be either: damaged, faulty, or misconfigured.

If I put a scope on the CAM lines (no devices connected) and do a i2cdetect -y -r 2 I see clear waveforms on both the SDA and SCL lines.

On the other hand if I put a scope on the Gen2 lines, again with no devices connected, and do a i2cdetect -y -r 1 I see a clear clock signal on SCL, but nothing on SDA.

SDA seems non-functional.

So I have a solution for my issues, but just not by using the Gen2 bus.

I just received the Adafruit display (https://www.adafruit.com/products/880) and soldered it together according to the Adafruit instructions (https://learn.adafruit.com/adafruit-led-backpack/0-dot-56-seven-segment-backpack).

I did a fresh install of L4T 21.4.

I then wired the Adafruit I2C backpack (HT16K33) to the Jetson as follows:

Jetson J3A1:14 → HT16K33 GND
Jetson J3A1:16 → HT16K33 VCC
Jetson J3A1:18 → HT16K33 SCL
Jetson J3A1:20 → HT16K33 SDA

As noted in a previous entry on this thread, VCC is not required to simply test for the presence of the I2C connection.

I installed the i2c tools:

$ sudo apt-get install libi2c-dev i2c-tools

and then ran i2cdetect

ubuntu@tegra-ubuntu:~$ sudo i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: 70 -- -- -- -- -- -- --

The 0x70 entry is the I2C backpack for the 4 digit LED display.

I need to write a little library to actually drive the LED display.

Unfortunately the only information that this imparts is that the Gen2 I2C port appears to work on the machine I am working on.

As promised, a little library along with a video and article about hooking up the 4 digit 7 segment display. The video shows connection of both Gen2 and Gen1 I2C ports.

[url]http://jetsonhacks.com/2015/10/25/4-character-7-segment-led-over-i2c-nvidia-jetson-tk1/[/url]

This demonstration is shown directly after flashing L4T 21.4 using JetPack. This doesn’t answer why +csherstan was having issues with their Gen2 I2C port, but shows that it is possible on a properly running system.

Well, thanks for trying. All I can figure is that my Gen2 bus is dead :P

Hello!

We are using ADV7611 and ADV7340 chips on tx2 interface board.but we are not getting any acknowledgement from adv7611 chip address 0x98 or 0x4c (7 bit address) while writing and reading from i2c device using i2cset and i2cget tools. I am getting “read/write failed” error no matter what register address is specified. besides the device is not getting detected with i2cdetect tool.

we also probed it with oscilloscope. are there any recommended settings before using i2c tools?

additional info:

I2C is running at 100 kHz

any help is much appreciated.

Thanks and regards,

Shivlal