STUSB1600 (USB Type-C) and USB OTG

[arturo182]

I'm trying to understand how I can use a USB Type-C connector together with the STM32MP1 USB OTG peripheral.

So obviously I want to use the port in dual role configuration. I want to use the STUSB1600 for that because it takes care of the power source/sink control for me. But I do wonder how should I connect the OTG_ID pin (if at all) in the STM32MP1, should it be to the ATTACH pin of the STUSB1600? The eval and DK only use the micro connectors for OTG.

I have found AN4775 and figure 9 (attached) explains how to use Type-C with OTG, but I'm not sure if that applies with the STUSB1600 because it takes care of the CC pins for me.

So if someone could please help with figuring out dual role with Type-C connector, please.

[arturo182]

To add to the confusion, I noticed in CubeMX there are 2 options for setting up the OTG peripheral and the one that says "Type C" disables the ID pin :persevering_face:

[PatrickF]

By USB standard, OTG protocols are not supported over USB Type-C connector, so STM32MP1 ID pin is useless and VBUS pin management is handled by STUSB1600.

Type-C DRD (Dual Role Data) could be stated as the OTG equivalence when using Type-C connector. See usb.org or wikipedia for some general information.

Please have a look to STM32MP157C-DK2 board schematics (page 6) for an example of connection of STM32MP1 OTG IP with STUSB1600 supporting DRD/DRP (although power sink is open in that example as we supply the board 5V from another connector).

[arturo182]

I see, I was wondering how does the kernel know which role the peripheral should be used in if there is no ID pin but I think I understand now, I looked at the documentation for the chip in the kernel https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/Documentation/devicetree/bindings/usb/st%2Ctypec-stusb.txt and the driver will read the current role from the chip over I2C and adjust based on that, making the ID redundant.

Do I understand correctly?

[PatrickF]

I have not a good view of related SW aspects, but from HW perspective, the CC lines levels are used to determine if the connected USB peripheral is an host (source) or a device (sink) or else (e.g. charger).

To support DRP in automated way (i.e. allowing to connect an host or a device), I assume that the STUSB1600 should toggle regularly (e.g. few times per seconds) to present itself (on CC lines) as host or device (don't know if the sequence is managed inside STUSB1600 or by SW controls) until CC lines level change is detected.

Then as you see, the role is read by the SW over I2C, and the driver will setup the OTG IP to the right mode to start enumeration.

[AmelieD · Accepted solution]

STUSB1600 Linux driver is being written. For the moment, it is really basic and allows to configure STUSB1600 (power role, power operation mode). And Type-C connector is forced to Peripheral role on DK, Host role use cases can be done with Type-A connectors.

Interrupt support is under development: STUSB1600 raises an interrupt on attach/detach and knows the current role. With 4.19 Linux kernel, it can use extcon to send attach/detach events with current role. USB role switch class with notifier could be used with next Linux kernel version.

OTG driver has to register to these notifications to switch role (as if it was receiving a pin ID change interrupt).

All these developments are in progress.

[Gregory Go.]

The USB OTG is being replaced by USB Type-C Dual-Role capability.

• The ID pin (on the USB Micro-B connector) doesn’t exist on the USB Type-C connector, so the ID pin cannot be used to select the USB OTG as UFP or DFP.
• It is now the CC pin which determine the Power Role and the initial Data Role.

Pull-up resistor on CC pin --> The application is Power Source & Data Host (DFP).

Pull-down resistor on CC pin --> The application is Power Sink & Data Device (UFP).

[Gregory Go.]

A short doc is attached.