One simple theory that can account for the observation is this: the host-side USB type-C controller doesn't like seeing a voltage on VBUS. Whether such a thing is in the USB specs, I dunno, I have only seriously read the USB 1.1 specs years and years ago. Maybe it is a safety lockout or something, in case there are non-conforming cables.
VBUS host-side paranoia would account for the test on Pico, reproducing the no-go case when VBUS GPIO is set to high. Host sees a voltage on VBUS, holds back.
So, it is possible that when the cable is plugged into the host first, the host sees zero on VBUS and initiates CC checks etc. But when the cable is plugged into the host last, there may be some voltage on VBUS in the cable, due to nanoamp-level leakage from the GPIO, and that may be enough to charge the capacitance on VBUS in the cable, maybe tens of pF. That may be enough to get host side to throw up its arms.
So, to mitigate this issue, in theory we can still hold the GPIO low most of the time, then occasionally switch to input and check it. Enabling a pull-down I think will reduce the divided VBUS voltage at the pin, something that gives me the jeebies.
VBUS host-side paranoia would account for the test on Pico, reproducing the no-go case when VBUS GPIO is set to high. Host sees a voltage on VBUS, holds back.
So, it is possible that when the cable is plugged into the host first, the host sees zero on VBUS and initiates CC checks etc. But when the cable is plugged into the host last, there may be some voltage on VBUS in the cable, due to nanoamp-level leakage from the GPIO, and that may be enough to charge the capacitance on VBUS in the cable, maybe tens of pF. That may be enough to get host side to throw up its arms.
So, to mitigate this issue, in theory we can still hold the GPIO low most of the time, then occasionally switch to input and check it. Enabling a pull-down I think will reduce the divided VBUS voltage at the pin, something that gives me the jeebies.
Statistics: Posted by katak255 — Wed May 08, 2024 8:07 am