TUSB320: General USB C design questions - feedback welcome

Hi Niclas,

To address your specific TUSB320 first:

1. I do not see a issue as long as the MCU GPIO in input "mode" does not drastically change the loading on PORT or ADDR. In some cases when GPIO is configured as a input, an internal pull-down resistor is enabled (and remains enabled) which affects the state of PORT or ADDR but this depends on the specific MCU application. 

2.ADDR will also be sampled when EN/EN_N is asserted sot he ADDR state must be set beforehand. 

I suggest creating a separate thread to find the correct TI equivalent to PI3USB9201 however TPS2546 maybe a good place to start.

Audio Accessories typically only "consume" audio signals with +/-3V swing (i.e. headphones). 

Please let me know if any more questions or if I missed anything. 

Hi Malik and thank you,

Does this mean that there is never a need to power cycle the TUSB320HAI? If you e.g. want to go from I2C control to pin control you deassert EN/EN_N, reconfigure ADDR & PORT, and finally assert EN/EN_N? (Or the other direction.)

It might seem like a strange question, but I haven't yet decided on I2C control vs. pin control, so I'm designing HW to support both. For this to be guaranteed to work I must know whether I must also power cycle the TUSB320HAI. The PI5USB30216C/D requires power cycling for this.)

-

Regarding Audio Accessory: You write "typically only 'consume' audio signal". I came to that conclusion myself (mostly by reasoning), but:

- Do you know if Audio Accessories may only consume (or is it just the common case)?

- How can we know that it won't suddenly be added to the USB C specification?

when learning about USB I have on several occasions realized that either I had just missed something or suddenly the team behind the USB specifications decided to add some feature that has great impact on what you need to incorporate in your design.

One such example is added backward compatibility to USB C chargers so that they also must do BC1.2 current advertisement. Many USB C controller datasheets / application notes don't mention BC1.2, when it really should have been part of the datasheet reference design. It must be a nightmare to develop and maintain ICs for USB.

I am getting a similar feeling as with Bluetooth - they never seem to mature and stabilize. Every now and then some company comes up with a 'bright' idea for using or misusing USB and either gets it into the USB specification or goes into production with a proprietary solution. I am not the only one with these sentiments:

https://www.androidauthority.com/state-of-usb-c-870996/

-

Could you please comment on the design choices in my original posting? The Audio (Accessory) switch might be superfluous, but am I missing something? Is there a better combination of ICs that do what I want? (Not in BGA chip.)

Is it practically possible to be idle in Try.SNK and then let the product configure USB HW and SW upon attachment? Are there timing aspects that makes this fail? Or would we end up with a mismatch between USB C role 'selection' and BC1.2 detection? An obvious case is if the user plugs in an A->C cable with (and also without) pull-up resistor.

In other words: is the only practical SW design either a device/SNK or host/SRC before attachment occurs?

-

The TPS2546 is only a host-side BCD? I need dual role capability, but thank you for the suggestion.

-

Best regards

Niclas

Hi Niclas,

Correct, TUSB320LAI should resample the ADDR and PORT pins when EN is asserted without power cycle. Be sure that EN is dessaerted for 50 ms after ADDR and PORT pin status change.  

This is the most common use case for devices that present Ra to the CC pins to "consume" audio signals. I am not aware of any future change to the USB-C spec to include Audio adapters that can source audio signals.  If you want to define your device to support Audio Accessories that support charge through then the USB-C spec says:

"The system shall connect A6/B6, A7/B7, A8 and B8 to an appropriate audio codec upon
entry into the Audio Adapter Accessory Mode. The connections for A8 (SBU1) and B8
(SBU2) pins are dependent on the adapter’s orientation. Depending on the orientation, the
microphone and analog ground pins may be swapped." - Apendix A :Audio Adapter Accessory Mode

From this perspective you will need an audio codec in your system (assuming your MCU does not have such function).  

Your device selection look good from my view but you may want to look at our USB Type-C Audio Adapter Accessory Mode Reference Design for more info on design supporting audio accessories.

There is nothing wrong with having your port stay in Try.SNK, in fact port should be configured for DRP Try.SNk before connection. If no CC termination is detect then there is no connection from a Type-C perspective and system will have to understand what is connected based on DP/DM and/or Vbus. USB-C negotiations happen before BC 1.2.

Thanks again Malik,

Much appreciated.

Thank you for the hint about tidub66.pdf. I have already looked at it but I couldn't find a suitable Mic/GND - GND/Mic switch. Could you recommend one?

-

There is a problem with Try.SNK and TUSB320; It's not available when under pin control:
"When operating in GPIO mode, the TUSB320 will always operate as a standard DRP." (HAI datasheet p11)

(This is actually one of the upsides to the PI5USB30216C/D. In pin control mode it powers up as Try.SNK. On the other hand, it must be power cycled for role change and when attached as default current SNK in pin control mode both OUT1 and OUT2 are hi-Z, so you must monitor VBUS too.)

-

Thank you also for confirming my suspicions regarding USB C and BC1.2. However, I fear that the real-world is not so clean-cut. When looking for A->C cables with pull-up resistor, I came across a few that don't incorporate one. (Qualtek 3021090-01M and 3023048-01M do for example.) In other words, in great many cases the USB C controller won't detect attachment, so the USB C controller cannot be relied upon for role determination. This means that the BC1.2 BCD should already have been configured for the expected role, so Try.SNK won't work in some use cases. (We don't have the Mini or Micro ID signal.) This isn't a very big problem for our product. It is a device by default and only in a few specific cases it is a host.

One of my tasks ahead is to draw a flow chart of how to determine role and current based on information from TUSB320HAI, PI3USB9201, and bq25896. (The latter will detect external VBUS even if advertisement is missing from both the other ICs, which I suspect might be the case when connecting our product to a PC via an A->C cable that doesn't have a pull-up resistor.)

Regardless, the A->C adapter cable pull-up resistor really only results in USB C SRC role for the power source (that might be a PC or a charger) and SNK role for the device. If there is BC1.2 BCD current advertisement it is probably more reliable than the USB C advertisement. If both USB C and BC1.2 BCD says 'default current', we don't know if it's 500mA or 900mA (or much more because the 5V power source (typically PC port) is designed to supply much more e.g. per port pair).

As I said, USB is a downright mess. There is an abundance of specifications but you cannot rely on anything so you still have to design for 'anything goes'. Hopefully the bq25896 automatic input current limiting will detect overcurrent before the power source is permanently damaged...

-

Could you point me to one, comprehensive, application note that explains all this and presents a proper solution?

Best regards
Niclas

Hi Nicals.

TS3A227E can be used to automatically resolve MIC/GND orientation. 

Correct, TUSB320LAI Try.SRC and Try.SNK options are only though I2C. I recommend using I2C mode if possible in your system to get the most flexibility out of TUSB320LAI. 

From my view these cables to do not follow the USB-C spec and should not be accounted for. The USB-C spec mentions that USB-C to USB-A cables should have Rp on A5 pin (CC) for both USB 3 and USB 2 cable assemblies. You can refer to Table 3-12 USB Type-C to USB 3.1 Standard-A Cable Assembly Wiring and Table 3-13 USB Type-C to USB 2.0 Standard-A Cable Assembly Wiring. I do understand that in the real world that there can be non-compliant cables but without CC termination it will be difficult to determine solely based on Vbus (Always present at the Type-A port). One potential way to detect such a non-compliant cable is to detect VBUS and poll TUSB320HAI I2C registers to understand CC pin state. If CC pins are read a unconnected and VBUS is present then you may be able to assume such a non-compliant cable is connected. This would only work assuming that Vbus is not provided by your system and system always starts as a UFP/sink, not a DFP/source. 

500mA/900mA default current values are defined for USB2 or USB 3 applications. In your case if default current is detected then you should always follow 500mA max to be USB compliant. Current consumption based on interface can be monitor by PC USB port and overcurrent condition reported to the USB Host. 

The USB-C Spec does have some guidelines on how a USB-C port responds to a legacy Host port, 4.5.3.2.2 Legacy Host Port to Sink Behavior. Table 4-17 Precedence of power source usage form the USB-C spec also describes the order in which your system should configure it power consumption (USB-C current mode supersede BC 1.2). We do not have applications note on system design for cables that do not follow the Type-C spec. However the paper below may help shed some light on proper design with USB-C. 

https://www.ti.com/lit/wp/slyy109a/slyy109a.pdf 

Thanks again for a very good answer.

Isn't the TS3A227E only for the 'audio jack to USB C adapter' or simply 'audio jack decoding'? It incorporates switches for Mic/GND but as I understand it they exist because there are two different standards for where Mic and GND are located on the 3.5 mm plug? They make sure that the Mic pin on the TS3A227E has the correct polarity? But, don't you also (inside the handheld) need to account for the rotation of the USB C connector?

I really sympathize with your point on out-of-spec USB C cables, but I fear that it is impractical from a real-world product support perspective. If we only support in-spec USB C cables we will have dissatisfied customers and a need to spend time on support cases that could have been avoided.

It's a bit like designing for VBUS never exceeding some 5.x V without PD, because the specification doesn't allow it. I don't remember where, but I have come across technical documentation from some of the reputable IC manufacturers (perhaps TI or ST) that warn about rogue USB C chargers that provide 20 V without PD negotiation.

Thank you for referring me to '4.5.3.2.2 Legacy Host Port to Sink Behavior':
"The value of Rp shall indicate an advertisement of Default USB Power (See Table 4-24), even though the cable itself can carry 3 A. This is because the cable has no knowledge of the capabilities of the power source, and any higher current is negotiated via USB BC 1.2." I hadn't realized that this is actually part of the specification.

I had already read slyy109a.pdf. It is indeed one of the best design documents, but it doesn't mention BC1.2 (which is no worse than the competition, but still not sufficient).

I have looked at www.ti.com/.../products.html but the closest I come to what I am looking for is the TPS65987D. I haven't scrutinized its datasheet, but I would welcome something similar without support for PD. It would have to be possible to configure it so that it accepts out of spec USB C cables. And it should interface nicely to e.g. bq25896. There must be a huge market for MCU USB2.0-only USB C products that can take both SNK and SRC role.

-

The design I'm working on will have two main purposes; a test platform for dual-role USB2.0 USB C BC1.2 that can also be used as a development board for the actual future products. As such I am making the TUSB320HAI configurable both for I2C and pin control and I am incorporating diode OR-ing for its VDD so that you power it from 3.12V (bq25896 VSYS and LDO from LiIon battery) when VBUS is not present but jack VDD up to above 3.5V when acting as SRC and advertising 3.0A. From this design I can then remove bells and whistles when transferring the proven design to the actual product.

I'll also include the TS5USBA224 and add a pin header for ASEL, USB C connector rotation/polarity, and audio signals so that support for Audio Accessory can be added with a breakout board.

In summary: The best solution I have found is TUSB320HAI/LAI, PI3USB9201, and bq25896. This means three fairly separate interrupt sources that all need to be queried and reacted to. The PI3USB9201 should probably be disabled until either TUSB320HAI or bq25896 says that 'it seems we have become attached'. Running TUSB320HAI in pin control (and listening to the bq25896 PG# pin) should improve 'response time' at attachment as a device/SNK. This is why TUSB320 pin control mode is potentially very interesting, despite its limitations.

In our case, we will have a menu option through which the user can select to change to host/SRC for a limited period of time (15 seconds?). The HW and SW are reconfigured for host/SRC and current is advertised both via CC and BC1.2. We might include a menu option to provide VBUS 'legacy style', so that it will be possible to violate USB C specs but at least it has to be an active choice. If attachment is not done in this limited time frame, the product reconfigures itself to idle device/SNK.

Best regards

Niclas

Hi Niclas,

Niclas Arndt said:

Isn't the TS3A227E only for the 'audio jack to USB C adapter' or simply 'audio jack decoding'? It incorporates switches for Mic/GND but as I understand it they exist because there are two different standards for where Mic and GND are located on the 3.5 mm plug? They make sure that the Mic pin on the TS3A227E has the correct polarity? But, don't you also (inside the handheld) need to account for the rotation of the USB C connector?

TS3A227E can automatically determine the MIC and GND connection from SBU1/2 as well and routes the signals appropriately to the internal destination. It is not necessarily just for audio jack decoding on 3.5mm plug. The external adapter would have the USB-c plug goin into you receptacle.   

Niclas Arndt said:

I have looked at www.ti.com/.../products.html but the closest I come to what I am looking for is the TPS65987D. I haven't scrutinized its datasheet, but I would welcome something similar without support for PD. It would have to be possible to configure it so that it accepts out of spec USB C cables. And it should interface nicely to e.g. bq25896. There must be a huge market for MCU USB2.0-only USB C products that can take both SNK and SRC role.

Unfortunately I am not an expert on TPS65987D. I would recommend posting questions for this device to understand if this is possible. 

Niclas Arndt said:

n our case, we will have a menu option through which the user can select to change to host/SRC for a limited period of time (15 seconds?). The HW and SW are reconfigured for host/SRC and current is advertised both via CC and BC1.2. We might include a menu option to provide VBUS 'legacy style', so that it will be possible to violate USB C specs but at least it has to be an active choice. If attachment is not done in this limited time frame, the product reconfigures itself to idle device/SNK.

I think requiring user action when using this type of cable is a good solution given the circumstances. This will ensure that the "non-complaint" behavior does not occur on it own and quarantined to the specific cables.  

Hope my comment were helpful!