USB Type-C IC suggestion

[alorenzato]

Hi,

I'm looking for some suggestions for the implementation of a self-powered and DRD (Dual Role Data) system provided with USB Type-C connector, but without PD support.

I found two different solutions:

1) Using a configuration channels protection IC (TCPP02-M18 or TCPP03-M20 in which the sink path is left unconnected) to be used with any STM32 provided with USB and UCPD interfaces, e.g.STM32G0B1, and with X-CUBE-TCPP expansion support.

2) Using a configuration channels controller IC (STUSB1600 in which the sink path is left unconnected) with any STM32 provided with USB only, without the UCPD constraint.

I have two questions:

1) Do you have some suggestion on which can be the preferred solution, also in terms of IC longevity? (TCPP are in the 10 years longevity program, the STUSB1600 isn't). Can both the TCPP be used for this application? I guess TCPP can be the preferred one since I can use it also for future developments with PD support.

2) Using solution 1, in the project creation using CubeMX is it possible to configure the UCPD as Dual Role, but using the "Type C only" stack configuration of the USBPD middleware, without using the "full stack" configuration (thus simulating the STUSB1600 behaviour)? I don't need to implement PD on this project, so this could help to reduce the memory occupation and to easy the management.

Thanks for the support!

[Nicolas P.]

Dear @alorenzato 

"self-powered and DRD (Dual Role Data) system provided with USB Type-C connector, but without PD support."

you request doesn't start well... :grimacing_face:

To be able to have any role change (data, power...), you will need the USB power delivery protocol.

Also because the default USB role depends on the power role defined on the attached. (See wiki)

So if the default USB data role doesn't match you need, you need the USB power delivery protocol to swap.

When you say you are self powered, you mean you are source (=provider) ?

So default USB role will be DFP (= host), but you want to be UFP (=device) ?

Regards,

Nicolas

[alorenzato]

Hi @Nicolas P. 

thanks for the answer.

What I meant with that sentence is that the system is able to toggle between source and sink before the attach (DRP, maybe with optional support of Try.SRC or Try.SNK to set a preferred role) in order to be able to become a source/host/DFP in case of an attached device, or a sink/device/UFP in case of an attached host (but without sinking power from the source attached, and that's why I wouldn't connect the sink path of the IC).

This should be the behaviour of STUSB1600 if I'm not wrong.

I don't need to swap roles after the attach, so I shouldn't need PD.

Basically I'm asking if with an STM32 with internal UCPD it's possible to reproduce the STUSB1600 behaviour using the TCPP as the protection device and X-CUBE-TCPP package, but without enabling the full stack configuration needed for PD. 

Hope I have explained it better :smiling_face_with_smiling_eyes:

Regards,

Alessandro

[Estelle ASTAR]

For  sure  having a  10 year commitment  for  industrial in an advantage as  industrial projects have  generally long life time.

Technically the  approach is  also different :

1/ The  STUSB1600 is  a  USB controller with VBUs  limited to 5 V however it can survive a 20 V connection. It  can be  sink, source  or  DRP. Datasheet  shows it  has to be  connected to µC although they mention stand alone  project. It embeds  a  P-MOS driver and  CC lines  must be  externally protected.

2/ The  TCPP series covers : TCPP01 for  sink, TCPP02 for  source and  TCPP03 for  DRP. The  3 devices are  compliant  with USB type-C Power Delivery standard up to 20 V. this  means  whatever you connect the  TCPP will adapt to  the  best voltage/current  profile for  5 V to 20 V.

3/ TCPP series  have  been developed with our  STM32 team to optimize the  sharing : roughly the  STM32 embed the digital low  voltage circuitry (UCPD) while the  TCPP embeds  the  high voltage  circuitry (up to 20 V, ) with integrated over voltage / over current  protection and  a  N-MOS  driver). This sharing leads to a  more  cost-effective  solution