Using the 2nd I2C bus on the 2B v1.1

Just to be clear, this is not about being right or not. I'm just trying to explain how someone like me can use google and then not know about the camera i2c link on those pins, and think it's only for EEPROM.

How this happens.. as I stated in my opening post, the normal i2c port on my pi is fried. No idea why, no 5v has been applied to it, but I must have done something wrong somewhere, as the SCL port is always low (0v). It might be that just the pullup is blown, or something else, fact is it's always low, even if I use it as GPIO output and set it to high. SDA does still work normally, when I configure that pin as normal GPIO, i can switch it between high/low.

Since I'm working on an embedded project which requires i2c, I was looking for a way to accomplish that, even thouhgh the i2c port was broken. The first thing I investigated, was to use the i2c ports I know are available on the camera and display ports, however, google didn't yield me results soon enough for that, so I took another look at the pinout. After some searching, I found the second i2c port on the 40 pin port. Then I googled on how to activate it. Found a lot of wrong answers, untill I finally found the answer I posted about here. So I googled a lot on camera and i2c and googled a lot on second i2c bus and stuff like that, and NOWHERE did I find that the camera uses that port. I wat totally ignorant to that, untill you posted it here.

So I can't really tell you exactly where to document it. All I can say, from a user perspective, that if you're googling to enable the 2nd I2C port, all you will find is the EEPROM story. Mostly because of this:
https://github.com/raspberrypi/hats/blo ... gnguide.md

Within the set of pins available on the J8 GPIO header, ID_SC and ID_SD (GPIO0/SCL and GPIO1/SDA) are reserved for board detection / identification. The only allowed connections to the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect anything else to these pins!

Which led me to believe that it's only used for an EEPROM. The other stuff (GPU) is not mentioned there.

I understand where you are coming from. You know the documents and know it's in there multiple times. All I'm saying is that if someone who's not intimately familiair with all the documents, and who's just googling for an answer, won't find this information.

Hi all
Im trying to use the second i2c bus also, and have successfully done it in past versions. But Ive got a new pi2 & the latest OS, and now Im having trouble seeing the i2c0 channel. Heres my config.txt
hdmi_force_hotplug=1
dtparam=spi=on
device_tree=
dtparam=i2c_arm=on
dtparam=i2c_vc=on
dtparam=i2c_arm_baudrate=1500000
dtparam=i2c_vc_baudrate=1500000
I can see i2c1 and i2cdetect shows my devices, but I cant get to i2c0. Is there something more I need to set?
i2cdetect 0 gives me an error - could not open /dev/i2c-o
I used gpio load i2c 1500 to initialize

Hi all
Im trying to use the second i2c bus also, and have successfully done it in past versions. But Ive got a new pi2 & the latest OS, and now Im having trouble seeing the i2c0 channel. Heres my config.txt

Code: Select all

hdmi_force_hotplug=1
dtparam=spi=on
device_tree=
dtparam=i2c_arm=on
dtparam=i2c_vc=on
dtparam=i2c_arm_baudrate=1500000
dtparam=i2c_vc_baudrate=1500000


I can see i2c1 and i2cdetect shows my devices, but I cant get to i2c0. Is there something more I need to set?
i2cdetect 0 gives me an error - could not open /dev/i2c-o
I used gpio load i2c 1500 to initialize

Having "device_tree=" in there disables device tree completely (At present. That may change). That means all of those dtparam= options will be ignored.

It should not be empty, but you can leave it out all together (device tree).

Here is my current config.txt (working i2c0)

Code: Select all

dtparam=i2c_vc=on
dtparam=audio=on
dtparam=spi=on
start_x=1
gpu_mem=1
dtoverlay=dualpitft
dtoverlay=i2c-rtc-overlay,ds1307


Note that a lot of code (like that ds1307) assumes i2c1 on a B. So you might need to do some tweaking/hacking here and there.

Also note the start_x in there, and the dual TFT. (someone stated earlier that wouldn't work. Well... it does).

I've got to update myself from https://www.raspberrypi.org/forums/view ... 48#p917132 based on an email exchange that I've just had with Pi Towers.

On Pi2 rev 1.0 (*) and Pi3 there is no 100% safe way of accessing i2c-0. The GPU uses it to talk to a GPIO expander and SMPS, and there is no option for disabling those as that functionality is not optional.
I'll start the conversation with a couple more people at Pi Towers, but I suspect that the i2c_vc may need to be removed from the Pi3 device tree. It may be possible to implement a virtual I2C interface to it via the GPU, but one doesn't exist at the moment.

For all the good it'll do, I'll write up a documentation page to be added to https://www.raspberrypi.org/documentati ... /README.md. We can't make that be the first hit in Google, but at least it'll be there.

(*) Most Pi2's will be rev 1.1, but that is not guaranteed.

Well, on my pi it works flawlessly (Rasberri Pi 2, Model B, v1.1).

I'm using 3 sensors with it, a RTC, a 3 axis gyro/accel and a 3 axis compass. Without any issues besides the one I develop myself

Just for the sake of it; would it be possible to do something to the hardware to make it work on rev 1? like cut a PCB trace somewhere?

I have updated the startpost to reflect this new information.