RPI 3 problems with i2c0

[JoKo]

Good Morning

what is the difference between pi2 and pi3 regarding i2c

at my Pi2 i use i2c0 and i2c1 together without Problems
now with the Pi3 i get following Errors:

Code: Select all

Mar  6 09:57:47 RASP kernel: [   68.628527] i2c i2c-0: transfer timed out
Mar  6 09:57:51 RASP kernel: [   72.558611] i2c i2c-0: transfer timed out
Mar  6 09:57:52 RASP kernel: [   73.568630] i2c i2c-0: transfer timed out

after a few minutes (checking sensors in the background) the PI3 freezes ...

if i check at the same time with >> i2cdetect -y 0
i get a very slow Response or shows nothing
with >> i2cdetect -y 1 (same script running in background) i dont get this error

Code: Select all

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

cheers JoKo

[saper_2]

Read about interface usage on RPi3 , and for RPi2 too. I2C0 is used for internal stuff (like for/by GPU, CSI & DSI, HATs) , I think I saw somewhere that the I2C0 is also hooked to BT+WIFI chip . BUT I'm not sure about this....

I just remembered, I saw a not too long ago a topic with question how to disable for GPU access to i2c0 and get a 2nd I2C bus on I think RPi2 .

[6by9]

i2c-0 is NOT available for use from the ARM on Pi3. Bad things will happen if you try.
It is used for a GPIO expander and SMPS control, as well as the previous uses for HATs, display, and camera. When you want extra pins for BT and Wifi, then other things have to move.

I'm in the process of writing up a documentation page for I2C which will include that information. It was also brought up on viewforum.php?f=44&start=25

[joan]

I sniffed I2C bus 0 to see if I could pick up any traffic.

It seems to be spitting out regular start 86 repeated start 87 stops.

Code: Select all

[86-[87-]
[86-[87-]
[86-[87-]
[86-[87-]
[86-[87-]
[86-[87-]
[86-[87-]

i2c-0-86-87.png (41.2 KiB) Viewed 22613 times

[6by9]

As with all the hardware blocks that you can pin mux to multiple pins, transmit will be fine, but all the receive lines get logical or'ed together.
By enabling i2c-0 you've now or'ed GPIOs 0&1 with the actual lines going to the GPIO expander, and so the GPU will no longer be seeing ack's from that Add in that there are also then multiple processors trying to handle the interrupts, and generally you'll not be in a good place.

Yes, the expander is on I2C address 0x43, so addresses 0x86 and 0x87 are correct.

[joan]

As with all the hardware blocks that you can pin mux to multiple pins, transmit will be fine, but all the receive lines get logical or'ed together.
By enabling i2c-0 you've now or'ed GPIOs 0&1 with the actual lines going to the GPIO expander, and so the GPU will no longer be seeing ack's from that Add in that there are also then multiple processors trying to handle the interrupts, and generally you'll not be in a good place.

Yes, the expander is on I2C address 0x43, so addresses 0x86 and 0x87 are correct.

Not sure why the acks wouldn't be seen. The data line is getting pulled up and down by the master (as is the clock) so why can't the GPIO expander pull the data line down?

[6by9]

Not sure why the acks wouldn't be seen. The data line is getting pulled up and down by the master (as is the clock) so why can't the GPIO expander pull the data line down?

As I said, if you pin mux the same signal (eg SDA0) to multiple GPIOs, the input signal the peripheral on the other side of the mux sees is the logical OR of those pins.
This scenario, GPIO 0 pulled high, GPIO 28 (or whichever) pulled low with an ACK. 1 OR 0 = 1, so no ACK seen.

Try it (on a Pi1 or 2 if using i2c0). Set GPIO 28&29 to ALT0 (SDA0/SCL0) and see if you can talk to a device using i2c0 on 0&1. Or using i2c1, set 45&46 to ALT2 and try talking to a device on 2&3.

[joan]

...
Try it (on a Pi1 or 2 if using i2c0). Set GPIO 28&29 to ALT0 (SDA0/SCL0) and see if you can talk to a device using i2c0 on 0&1. Or using i2c1, set 45&46 to ALT2 and try talking to a device on 2&3.

Well.

I connected a PCF8591 to pins 3/5 (GPIO 2/3) of a Pi2 and ran a script which displayed the ADC and varied the DAC.

I checked GPIO 44/45 and both were ALT0. I set them to ALT2 and my Pi seemingly hung. In fact the network had stopped but I2C was still working (I could see the LED on the sensor cycling brighter and dimmer). I guess switching GPIO 44 out of clock mode was a mistake.

For the next test I just switched GPIO 45 to ALT2 (SCL1). That had no affect on I2C operation.

[gregeric]

Given what 6by9 has said about muxing the same peripheral io's to multiple pins, & your discovery that i2c continued to run, must imply that GPIO44 is being pulled low - it's still physically connected to the clock input of the LAN9514, might that pull it down? Might be worth pulling it high & seeing if that stops your LED dimming...

[6by9]

I connected a PCF8591 to pins 3/5 (GPIO 2/3) of a Pi2 and ran a script which displayed the ADC and varied the DAC.

I checked GPIO 44/45 and both were ALT0. I set them to ALT2 and my Pi seemingly hung. In fact the network had stopped but I2C was still working (I could see the LED on the sensor cycling brighter and dimmer). I guess switching GPIO 44 out of clock mode was a mistake.

For the next test I just switched GPIO 45 to ALT2 (SCL1). That had no affect on I2C operation.

Groan, I shouldn't just write stuff.
Pi2 uses GPIO 44 for 25MHz clock to ethernet. Mess with that and you'll have fun. It's also set with a pull down. GPIO45 is used for the left audio channel.
If you've just switched GPIO45, then clock stretching won't work, but it never did very well.

If you're on a Pi2 try it with i2c0, or just accept it.
As another example: viewtopic.php?f=107&t=127292 and commit https://github.com/Hexxeh/rpi-firmware/ ... 0b4e3de04d switched Pins 28&29 from alt0 to input for Pi Zero.
The same happened with Pi2 rev1.1 in March 2015 - viewtopic.php?f=44&t=102130&p=711450#p709850 Do you believe PhilE any more than me?

[joan]

...
If you're on a Pi2 try it with i2c0, or just accept it.
As another example: viewtopic.php?f=107&t=127292 and commit https://github.com/Hexxeh/rpi-firmware/ ... 0b4e3de04d switched Pins 28&29 from alt0 to input for Pi Zero.
The same happened with Pi2 rev1.1 in March 2015 - viewtopic.php?f=44&t=102130&p=711450#p709850 Do you believe PhilE any more than me?

It's not a case of trust. People make mistakes. If it takes me 5 minutes to test a claim then I'll spend that 5 minutes.

[joan]

...
It's not a case of trust. People make mistakes. If it takes me 5 minutes to test a claim then I'll spend that 5 minutes.

Well I took my 5 minutes and I2C operation on 0/1 does fail if you switch 28/29 into I2C mode.

i2c-0-on-0-1-28-29.png (45.72 KiB) Viewed 22361 times

On 0/1 the 9th bit is the device acknowledgement (pulled low). On 28/29 there is no device connected to acknowledge so the bit stays high. The Broadcom I2C peripheral presumably doesn't see the acknowledgement so fails the transaction.

[6by9]

It's not a case of trust. People make mistakes. If it takes me 5 minutes to test a claim then I'll spend that 5 minutes.

Well I took my 5 minutes and I2C operation on 0/1 does fail if you switch 28/29 into I2C mode.

24 minutes since your last post

On 0/1 the 9th bit is the device acknowledgement (pulled low). On 28/29 there is no device connected to acknowledge so the bit stays high. The Broadcom I2C peripheral presumably doesn't see the acknowledgement so fails the transaction.

I've heard that somewhere, let me think where it was ....
Been there, done that, got the t-shirt.

When things have calmed down a bit then I may talk to Pi Towers about a virtual I2C driver to i2c0, but I suspect at the moment things are a tad busy.
For the camera stuff I'm playing with I don't think it'll matter (use i2c-1 on 44&45 instead), but others may want it (eg programming HAT EEPROMs is going to be a pain otherwise).

[Jaked]

Hi

I need to use I2C bus 0 (I know you're not supposed to!) but I can't use it because of the 0x43 being constantly transmitted, which I understand to be looking for a GPIO expander?

Is there any way I can turn this feature off, so I can use it as a normal I2C bus?

Thanks

Jason

[6by9]

I need to use I2C bus 0 (I know you're not supposed to!) but I can't use it because of the 0x43 being constantly transmitted, which I understand to be looking for a GPIO expander?

Is there any way I can turn this feature off, so I can use it as a normal I2C bus?

As stated in just the previous post to yours, no, there is no way to free up i2c-0 for general use on a Pi3.

What do you need this extra I2C bus for? There is now kernel support and an overlay for driving I2C muxes, so if it is to just avoid an address clash then that is the easy solution - see viewtopic.php?f=44&t=141517
If you're genuinely multithreaded and need the extra bandwidth, then at the moment you're stuck, or use i2c-gpio to bit bang an I2C port.
AFAIK Pi Towers have been too busy to look into a virtual I2C interface across to the GPU to allow for use by both ARM and GPU safely.

[Jaked]

Appreciate the speedy reply.
Based on what you said, I think I am going to bit bang the GPIO's as a way of solving this particular issue.

Thanks again.

[Stiller]

just to clarify,
for a Pi 2 (ARM7) physical pins 27 + 28 are for i2c-0 (SDA0+SCL0), is that still true ?
(at least I once tested it many months ago, and it worked.)
for what purpose are physical pins 27 + 28 then on the Pi 3 if not for i2c-0, too?
Given that HAT EPROM has to be addressed by i2c-0 on a Pi 2, how is that addressed then on a Pi3 instead?

[6by9]

just to clarify,
for a Pi 2 (ARM7) physical pins 27 + 28 are for i2c-0 (SDA0+SCL0), is that still true ?
(at least I once tested it many months ago, and it worked.)

Correct for all Pi versions with a 40 pin GPIO header.

for what purpose are physical pins 27 + 28 then on the Pi 3 if not for i2c-0, too?
Given that HAT EPROM has to be addressed by i2c-0 on a Pi 2, how is that addressed then on a Pi3 instead?

The HAT EEPROM is read by the firmware before Linux has started - that functionality is still there. The GPU code dynamically switches the pin muxing for i2c-0 between the valid pairs of GPIOs as required.
The issue was that the firmware and Linux would be "fighting" over who was controlling the I2C hardware block and to which pins it was muxed.

As it happens, things have changed and the firmware is adopting a different approach, therefore i2c-0 can now be used from Linux on a Pi3 with recent firmware.

[Stiller]

As it happens, things have changed and the firmware is adopting a different approach, therefore i2c-0 can now be used from Linux on a Pi3 with recent firmware.

that is very good to know, thank you very much for clarifying!

BTW, about this former statement - this is not true, is it?

I think I saw somewhere that the I2C0 is also hooked to BT+WIFI chip ....

not that it is expected to completely mess up the i2c-0 port in case it had been done that way, but IIRC, BT is connected to UART and WiFi to USB, is that correct?

[6by9]

BTW, about this former statement - this is not true, is it?

I think I saw somewhere that the I2C0 is also hooked to BT+WIFI chip ....

not that it is expected to completely mess up the i2c-0 port in case it had been done that way, but IIRC, BT is connected to UART and WiFi to USB, is that correct?

You're correct the former statement isn't true. You're half correct on the connections.
The Wifi+BT chip is linked to SDIO for Wifi and UART for BT. It also has a couple of control GPIOs off the GPIO expander for reset/enable lines.
i2c-0 was being used for the GPIO expander and SMPS control via GPIOs 46&47, but that is now being bit-bashed by the GPU to release the i2c-0 block for other purposes.

[Stiller]

thank you very much for clarifying that, too!

[Stiller]

I just read another post about i2c-0 usage which was supposed to cause troubles also to the Pi Cam and the PI TFT (screen header, not HDMI) - are those issues meanwhile also outdated?

[6by9]

I just read another post about i2c-0 usage which was supposed to cause troubles also to the Pi Cam and the PI TFT (screen header, not HDMI) - are those issues meanwhile also outdated?

If you use a HAT with EEPROM, the Pi Camera, or Official 7" Pi display, then i2c-0 is not available to be used from Linux. That won't change as the GPU has to be able to communicate with those peripherals somehow.

[Stiller]

ok, thanks, I see. I thought that communication to HAT EEPROM, Pi Screen and Pi Cam through these 2 GPIO i2c-0 pins would be established just like to normal i2c devices, by a unique i2c device address and also by the normal i2c protocol, so that additional i2c devices wouldn't matter (by different dev addr).

[6by9]

ok, thanks, I see. I thought that communication to HAT EEPROM, Pi Screen and Pi Cam through these 2 GPIO i2c-0 pins would be established just like to normal i2c devices, by a unique i2c device address and also by the normal i2c protocol, so that additional i2c devices wouldn't matter (by different dev addr).

Yes, you need to avoid address collisions, but the bigger issue is that you have two independent PROCESSORS trying to talk to one hardware block.

When an interrupt occurs which processor services it first? Was it the one that requested the transfer? If not then the transfer on the other will timeout or otherwise misbehave. There is no inter-processor arbitration (and adding it would be entertaining), which is why i2c-0 is normally designated as for use by the GPU unless you are sure you are not using any of the functions that the GPU uses it for.