2024-04-03 06:57 AM
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!
2024-04-05 07:04 AM
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
2024-04-05 08:00 AM
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
2024-04-15 12:39 AM
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