Argon ONE UP i2c bus timeout when USB is attached

ONE UP
1

Hi All,
When I use one of the dual purpose USB-C/GPIO ports as a USB 2 data port, I start seeing this message repeated every view seconds in dmesg, or into the syslog:

i2c_designware 1f00074000.i2c: controller timed out

Certain other things stop working too such as polling for battery status and fan control.

“i2cdetect -y 1” works, but is very very slow compared to 13 or 14.

It’s almost as though using USB in one of the GPIO ports is breaking i2c somehow.

Is there something I need to do to properly enable the port for USB instead of GPIO?

2

Keep in mind that:

  • only the port closer to the screen has USB2 wired in, the one further away has only GPIO pins.
  • only +5V and GND (on both port), and USB2 D+ and USB2 D- (on the port closer to the screen) match the regular USB-C pinout. Everything else is non-standard.
  • among other, the pins normally used by CC1/CC2 (configuration) or Vconn (power for the electronics chip inside the cable) and SBU1/SBU2 (side-band) are mapped to GPIO pins according to the wiki – ID_SC (clock used by HAT configuration), GPIO4 (1-wire), GPIO9 (SPI) and GPIO12 (PWM).
  • according to the same diagram, pins that would be normally used for USB3, for alt-mod Display-port, etc. all map to various GPIO pins.

If you connect a pure USB2.0 device that only relies on the usual 4 USB pins (+5V, GND, D+ and D-), it should be mostly okay.
But if your device tries to do anything on the other pins, stuff could break.

I have a Yubikey and a Solokey that work on that without problem (they are pure USB2 devices, just ones with USB-C plug soldered on it instead of old school USB-A).

I also have a “dock” hub with USB-C plug that supports USB3.0, USB PD, and converts alt-mode Display-port to HDMI. When plugged, the lines that would normally be used for USB3 and Display-Port, pins TX1+ and TX2+, ends-up connected to the GPIO2 and GPIO3 which are I2C (SDA1 and SCL1 according to the wiki’s diagram) and I get the same error messages are you.

Yes, if your device tries to do anything beyond USB2 (beyond interacting with +5V, GND, D+ and D-), it can disrupt stuff. Your device tries to do stuff with the USB3 / alt-mode lanes and this throws off the I2C

There’s nothing you can configure, the GPIO lanes are directly wired to the port’s pins

(e.g. There’s no MUX chip that could connect/disconnect them, unlike the audio which has a MUX that can reroute audio to either the speaker or to the earphone jack depending on the status of the jack’s “plug detection” signal).

Those GPIO are always exposed there.

If you want to use that specific device, you might want to try plugging a pure USB2 hub and using one of those (USB2-only) USB-C to USB-A plug adapter. Or re-solder a USB-C connector to a USB2 hub with only the USB2 lanes to a hub (don’t even bother with the resistor for charging, ONE UP’s +5V is always present). Or put back-to-back a (USB2-only) USB-C to USB-A and any USB-A to USB-C adapters, so only the USB2 lanes are connected between your device and the laptop.