Since my previous post on they issues with the pi I have been doing some more experimenting with the USB-C port on the pi as a Linux gadget interface. As the pi4 has both host and client USB simultaneously (unlike previous versions) it makes it much easier alter the gadget code between tests. In doing so I discovered that my laptop wont enumerate the gadget in some situations due to more spec in-compliance.
A note on the pi’s “OTG” interface: An OTG USB interface supports both host and client modes, the newer term used for a Type C interface with this capability is a dual role device. While the pi’s SOC’S inbuilt USB interface supports both host and client mode the USB-C connector interface on the pi is only designed to support client mode (UFP in type C terminology).
This new issue occurs when the pi is powered over the 5V gpio pins as these are directly linked to the USB-C power pins, this causes the pi to emit power from the USB-C port (the USB-C spec prohibits this for clients (section 4.5.2.2.3.1 of the spec for anyone interested)). This causes some USB-C hosts to not enumerate the gadget when used with a C-C cable as it detects Vbus and fails to enter host mode. If the pi is powered by the USB host it will detect as there is no reverse Vbus to cause confusion during the port configuration phase.
Testing on some more devices my phone and the 3.0 USB-C port on my laptop detect the pi, these ports just use the CC resistors and ignore the presence of Vbus. The USB 3.1 on my laptop however doesn’t. As a test I also tried using some USB-A adaptors to rule out any CC issues, I Used a USB A-C cable attached to the pi and either a USB C-A adaptor or a USB hub with a C connector to the laptop and A ports at the laptop end. With this setup the order that things are plugged in generates different results, if the pi is plugged in first it wont detect but if the laptop is plugged in first it will. This makes logical sense as if the laptop is plugged in first it goes into host mode before it sees the Vbus from the pi. The oddest combination is to plug the C-A-C cable adaptor in with the pi being the host and the laptop as the client as the laptop enumerates the pi as a client in this configuration, the fact that this works is partly the fault of the laptop as it connects up its USB host pins in when connected in either host or client configuration.
There are some workarounds to this issue if you are encountering it. The first is to try a different USB-C port on the device you are connecting with as they might behave differently, alternatively a USB-A port with an A-C cable. Using a C-A then an A-C cable will also work if you plug the non pi end in first. in the longer term hopefully this will be fixed when the CC resistor issue is fixed.
Thanks for the great articles, Tyler.
I’m trying to figure out a way to connect a pi4 to my iPad Pro via usb-c for DATA, but not for power, because I am powering the pi from an 18650 powered UPS board.
Is there such a thing as a “data only” usb-c cable that will work? Or am I barking up the wrong tree?
Thanks in advance,
George
Hi George
I havent come across a data only cable for USB-C atall, there is also no part of the spec that would cover such a cable. If you are having trouble getting the ipad do detect the pi you might have some success by using a USB-C to USB-A female adapter then a usb-A to usb-C cable to connect to the pi (plug the adapter in to the host device before connecting to the pi) as this works arround the port on the non pi end failing to enter client mode by making it do so before connecting the pi, Im not sure how the ipad will handle recieving voltage through its USB port when in client mode however. The other option is to modify a cable yourself to cut the vcc line.
Thanks
Tyler
Pingback: Pi 4 with partial USB Type-C fixes – The blog of Tyler Ward (aka scorpia)
Let me get this straight whilst I rant a bit:
There are apparently two or more versions of the RPi4b board due to RPi.org screwing up the design and creating a defective product. V1.0-1 boards have a forbidden Vbus voltage-OUT on USB-C client mode when RPi4 powered by GPIO 5v and V1.0 boards are missing a required resistor on USB-C CC1&2 device detection pins.
RPi.org went cheap and tried to use 1 resistor to pull up CC1 & CC2 pins. Certain chargers and systems that follow the USB-C spec correctly think it’s an audio device and won’t provide any Vbus so the RPi4b gets no power.
The misnamed ’emarked’ cables are cables that follow USB-C spec correctly. Cheap retarded USB-C charging cables that only use one of CC1 or CC2 don’t have the problem but they may also be missing the data wires so no ppp link possible via RPi4B USB-C client mode.
I wish people would stop using the misnomer of ’emarked’ cables. It’s wrong. The misnomer of ’emarked’ cables is because people are retards and actually
think a cable that has all the wires connected is somehow not normal. There is nothing special about USB-C cables that have all the wires connected. What is special and retarded is USB-C cables that do NOT have all wires connected. However, non-retarded cables cost more because of more wires and testing, so you have to be careful that the USB-C cables you buy are fit for the purpose, or always buy USB-C cables that have all the wires connected to avoid issues. Spend more and have your USB-C always work or go cheap and take your chances.
In the case of the broken and retarded RPi4b, it’s simply just broken if it doesn’t work correctly with a normal, non-retarded, all pins connected, USB-C cable. The people at RPi.org need to fix their broken and retarded design. There is absolutely no reason why you should be forced to have two or more kinds of variously retarded USB-C cables to plug in a charger, a PC or a cellphone, and a different retarded USB-C cable if you power RPi4b from the GPIO 5v pins. It’s like having one car that requires 3 different kinds of petrol depending on the kind of road that the car is using. Tyres might be a better analogy for this but it’s still a ridiculous situation for those RPi4b owners who are unfortunate enough to have received a defective device.
Finally, to add insult to injury, RPi.org isn’t indicating on RPi4b silkscreen the version number of the board so you have absolutely no idea if you’re getting a working design or one of the boards with the defective design.
Does that about sum it up?