cancel
Showing results for 
Search instead for 
Did you mean: 

How do you detect USB Type-C cable attach/detach events in both cable orientations?

ardnew
Associate III

After getting help setting up a basic USB-C sink application in this thread, I can successfully detect cable attach/detach events through the relevant callbacks installed via ST USBPD API -- but only for a single cable orientation. The UCPD1 interrupt is not ever being triggered when reversing the Type-C plug.

To verify this is not an issue related to (all of) my USB-C cables or Type-C breakout interface, I've swapped the CC1/CC2 wires connecting the Type-C female receptacle to the MCU's CC1/CC2 GPIO pins. This ensures both CC1 and CC2 on the Type-C breakout can both be shown to function correctly. Therefore, I believe the issue must be isolated to just one of the CC GPIO interfaces on the MCU. I've drawn a diagram to clarify:

0690X00000AsAltQAF.png

So when the CC wire in the USB-C cable is attached to the UCPD_CC2 GPIO pin, regardless of which CC wire was used on the Type-C breakout, the system fails to detect a connection.

Where should I look to figure out why only one orientation is being detected?

1 ACCEPTED SOLUTION

Accepted Solutions
Nicolas P.
ST Employee

Hello Andrew,

I think this is a known issue : the GPIO corresponding to the CC2 line has to be set into analog mode.

Can you check the file usbpd_cad_hw_if.c ?

Replace :

#if defined(MB1397) /* in case of eval G4 */
  /* Not needed on MB1397 */
#elif defined (USE_UNIBOARD) || defined(MB1428) || defined(MB1367) /* in case of Nucleo G4 */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG); /* PB4 mode = GP analog => CC2 */
#else
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_OUTPUT); /* PB4 mode = GP output => CC2 */
#endif

by :

/* Set by default UCPD1_CC1 & UCPD1_CC2 in analog mode */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_6, LL_GPIO_MODE_ANALOG); /* PB6 mode = GP analog => CC1 */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG); /* PB4 mode = GP analog => CC2 */
 
  LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_6, LL_GPIO_PULL_NO);

This correction will be delivered officially next March.

View solution in original post

4 REPLIES 4
Nicolas P.
ST Employee

Hello Andrew,

I think this is a known issue : the GPIO corresponding to the CC2 line has to be set into analog mode.

Can you check the file usbpd_cad_hw_if.c ?

Replace :

#if defined(MB1397) /* in case of eval G4 */
  /* Not needed on MB1397 */
#elif defined (USE_UNIBOARD) || defined(MB1428) || defined(MB1367) /* in case of Nucleo G4 */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG); /* PB4 mode = GP analog => CC2 */
#else
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_OUTPUT); /* PB4 mode = GP output => CC2 */
#endif

by :

/* Set by default UCPD1_CC1 & UCPD1_CC2 in analog mode */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_6, LL_GPIO_MODE_ANALOG); /* PB6 mode = GP analog => CC1 */
  LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG); /* PB4 mode = GP analog => CC2 */
 
  LL_GPIO_SetPinPull(GPIOB, LL_GPIO_PIN_6, LL_GPIO_PULL_NO);

This correction will be delivered officially next March.

Great, worked like a charm, thanks!

You state a correction will be delivered in March -- do I also need to wait until then for that Application Note you mentioned in my previous thread? I'm very anxious to learn what the App Note is going to detail (and if there are any offers for new ST MCU products targeting USB-C and/or USB-PD).

-- side note, personal rambling follows --

I have been completely dumbstruck by the lack of adoption to USB-C / USB-PD in the microcontroller world, every major vendor is still exclusively legacy USB, and if they happen to support USB-C, they only support the USB 2.0 data lines (e.g. the new Adafruit STM32F4 Feather).

I'm stuck hand soldering my own prototype boards using various components just to get basic Type-C + USB-PD + USB 3.2/3.1 SuperSpeed data. Your teams' STM32G0 and G4 (and L5 hopefully??) boards are far and away the leader in bringing these standards to the free world, albeit quite the learning curve (having only experience with Arduino, personally, been very enlightening!).

If only there was a small-footprint MCU (like Arduino Nano and Nucleo-32) designed specifically for USB Type-C applications (Power Delivery, USB 3.2/3.1 SuperSpeed data, ..or both), with a native Type-C interface... that would be a miracle. And if you wanted to throw in options for this board -- how about 1.) an integrated SuperSpeed Mux/Demux on-board, and breaks out the SS lines on the GPIO pins; or 2) an integrated MOSFET switch for sourcing external fixed-voltage DC loads.

Anyway, thanks for letting me rant. And thanks even more for the help. And thanks yet even more for your attention to my questions regarding the App Note above.

10/10 will recommend ST above all others, you guys have been tremendous

DSERG.1
Associate

This correction will be delivered officially next March.

When will the update be?