8
\$\begingroup\$

I want to make a device which can be connected either to a PC with an USB 2.0 connection or to another identical device and have a serial connection. This should be detected acutomatically and I want it to have a single connector. It seems that the USB-C is a good candidate. I can use the USB 2.0 signals when connected to a PC and the SuperSpeed signals when connected to the device.

Is this a proper way to use the USB 3.0 alternate modes? I have seen examples of using it as displayport or PCIe but never as a low speed serial port. This mode would never be used when connected with the computer but of course shouldn't damage or cause problems with the PC.

As these signals are differential, even if I'm working at the typical 115.2kbps I suppose I would need a transceiver to convert them to LVDS and use the TX+/TX- and RX+/RX- pairs, right? Or could I get away with using the signals SBU1 and SBU2 with no transceiver? I haven't seen any usage example of these two signals.

Using the LVDS transceiver seems to be the right thing to do, but maybe overkill, the distance between devices is short and the speed slow. It's for a low quantity prototype so cost is not an issue, but seems the circuit gets quite complicated with the transceivers, switches and ESD protection.

If I go with the LVDS transceiver, I have seen that the TX pair should have AC coupling capacitors, whould this also be necessary for low speed?

The device doesn't have USB-host capabilities, this is why I want to communicate by UART between devices, it's already implemented and the firmware won't need mayor changes.

Thanks!

\$\endgroup\$
5
  • \$\begingroup\$ You say that the two devices are identical - so why not use USB protocol to communicate between them? Can you explain what is the reasoning for which you would like to use a serial connection? \$\endgroup\$
    – Vladimir Cravero
    Commented Oct 1, 2018 at 13:33
  • \$\begingroup\$ For that I would have to implement USB-host and modify the firmware quite a bit... I want to modifiy it as little as possible so it can remain compatible with other hardware versions \$\endgroup\$
    – ballanux
    Commented Oct 1, 2018 at 14:41
  • \$\begingroup\$ That's good feedback - please add it in the body of your question so that people does not propose this as an alternative. \$\endgroup\$
    – Vladimir Cravero
    Commented Oct 1, 2018 at 16:22
  • \$\begingroup\$ did you ever complete the project? My research agrees with @ale..chenski that 5.1k on CC's to ground means it'll configure the device as an upward facing device (consumer of power, target device for a host to connect to) when connected to a smart endpoint such as a provisioning laptop. IE allaboutcircuits.com/technical-articles/… For two identical devices, the SBU1/SBU2 ports seem perfect for serial TX/RX as flipped they'll maintain their positioning. Your devices don't need to care about up/down facing, with delayed \$\endgroup\$
    – MarkT
    Commented May 28, 2020 at 6:13
  • \$\begingroup\$ For example, on the PTN5100DBSMP USB-c PHY IC, upon negotiation of "debug mode", the pin "CC_CTRL1" is asserted on the target side. This can be used to provide any trace multiplexing functionality that the debug mode may require. \$\endgroup\$
    – flukee
    Commented Jun 8, 2022 at 4:06

1 Answer 1

Reset to default
5
\$\begingroup\$

USB Type-C connector specification does define a "Debug Accessory Mode", DAM. If both CC lines are pulled down with 5.1k resistors, a USB Type-C device must enter "debug" mode. See Apendix B to USB Type-C specifications.

The standard defines all power and orientation protocols on entry into DAM, but leaves the transport level up to designers, so you can use the other available wires as you wish, UART, LVDS, whatever, proprietary.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ This seems like an interesting solution. But since all devices pull down both CC lines anyway, and don't provide power on VBUS, how could the device eventually detect that it is correctly connected to another similar device (and activate the proprietary DAM features), vs connected to another unrelated USB device (because the user made a mistake, or was trying dumb things)? And for that matter, how could he even detect that that it is actually connected to something? I am genuinely interested in any viable solution. \$\endgroup\$
    – dim
    Commented Oct 28, 2020 at 12:02
  • \$\begingroup\$ @dim, all answers are in Appendix B of the USB Type-C specifications. \$\endgroup\$
    – Ale..chenski
    Commented Sep 22, 2021 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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