3
\$\begingroup\$

I'm currently designing a device, which consists of a STM32 microcontroller with USB 2.0 support, USB 2.0 hub and few dimmable leds.

STM is connected to the hub, along with few other devices. Hub is then connected to a smartphone via a USB-C connector. The device has two modes of operation:

  • When connected to external power source it has to operate as upstream facing device (UFP, USB hub is connected to smartphone), and power SOURCE.

  • When external power is disconnected, it should switch to power SINK, while maintaining it's data role (UFP, all devices still connected to hub should be visible to smartphone). The device has a microcontroller, which can send power role swap to the smartphone.

I'm not sure if I'm understanding the standard correctly, but: STUSB1600A is only a controller, without Fast Role Swap while TPS65987D I think is an overkill for the task (or maybe I'm wrong?) Could You please advise some sensible solution?

\$\endgroup\$
  • \$\begingroup\$ Finally got along with TPS65981. Using any kind of USB PD Controller as TPS6598x is in my opinion the best solution. Thanks for reply! \$\endgroup\$ – Mateusz Kowalik Mar 16 at 8:39
5
\$\begingroup\$

The STUSB1600A is only a controller that follows now obsolete management of power roles using pull-up/pull-down combinations on CC lines. It doesn't have any PD capabilities. It is very unlikely that it will ever work for your purpose.

The TPS65987D, however, is a PD controller, which can exchange PD serial communication over CC channels. The thing is that by recent PD specifications the only legal way to change power role of a port is using PD communication, so called "Structured VDM", Vendor Defined Messages. By default, power role of a port is in strict relation with data role: UFP is a sink, and DFP is a source. To swap power roles without swapping data roles you need to engage both ends of the Type-C link in PD negotiations.

The thing is that TPS65987 chip is essentially a PD PHY, it can mostly receive and transmit PD messages. The content and interpretation of these messages must be crafted in firmware of some other MCU via I2C ports, although it does look like the TPS65987 has some local messaging capabilities which must be programmed in.

Also be aware that having Type-C connector doesn't automatically imply that the device supports all these fancy PD and power-swap modes, so your target "a smartphone" may not be designed for up to date PD protocol, so expect that the power-up "accessory mode" won't work with all "a smartphones".

All can I say, "good luck".

\$\endgroup\$
  • \$\begingroup\$ Considering problem size, it's possible, to change functionality, so the device is always a SOURCE, while being UFP. I thought that try.SRC might be a solution, but I can't make it work on STUST1600A eval. \$\endgroup\$ – Mateusz Kowalik Mar 6 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.