Can a USB PD DRP port be set as Sink by default for USB OTG compatibility?
I am attempting to use X-Nucleo-DRP1M1 + Nucleo-G071RB boards as data communication dock for with following behavior :
- The dock is a sink by default and UFP, so that a non PD capable mobile device can connect and communicate with a USB peripheral using the USB OTG feature (even though the mobile device isnt being charged)
- if a PD capable mobile device is connected, the dock can send a role swap requests so the mobile device is charged and connected to a usb peripheral.
The charging voltage is 5V.
It would be preferable if this behavior occurred reliably even in the case of a power cycling while remaining connected, and after repeated disconnects + reconnects.
I attempted to use a CubeMX project following this guide (https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Getting_started_with_USB-Power_Delivery_Dual_Role), setting the dock’s USB-C port as default Sink and enabled USB some connectivity features to enable connection to a peripheral.
I do not think the behavior i seek should require use of the Toggle feature, yet the RTOS enters an error state and freezes if it not activated, so i continue with the Toggle feature enabled.
With the toggle feature enabled, the following has been observed :
- a non-PD mobile device linked to the dock with a USB-C cable seems to often connect as an UFP sink, wich does not allow connection to a peripheral. Manually Resetting the board seems to activate the non-PD mobile device’s USB OTG feature, allowing connection to a USB Peripheral, but disconnecting and reconnecting the USB-C cable seems to return to the same situation described at first.
- On a PD capable device, the same has been observed, but the role swaps (data and/or power) occur correctly and is able to connect to a usb peripheral with the same USB-C cable without issue.
Is there any way to make the USB type C port a sink by default without risk of the port becoming a source, so as to insure a non-PD mobile device can connect to a peripheral with its USB OTG feature?
(also, i’ll note the following : the libraries and source files provided by STM32CubeMX seem to rely heavily on macros, and a change of project setting in STM32CubeMX does not necessarily update some source files which could have been compiled with outdated macros. A full clean of the project seems necessary after new files are generated by STM32CubeMX)