STM32G0B1KBU USB-C CC2

[XD]

Im looking to use the STM32G0B1KBU processor including the USB-C interface.
I only want to use it as a UPF with VCP and update the firmware, no advanced PD or role switching. 

The issue is that UCPD1_CC2 is not routed to a pin on the processor.

Is it possible to substitute the UCPD1_CC2 function with the "Dead battery pulldowns" UCPD1_DBCC2?
Will it work with the bootloader after the "dead battery" has been programmed/configured?

 

I could place the CC1 & CC2 pulldowns discreetly on the board but i am space constrained.
I could also switch to the N variant of the processor that seems to have the UCPD1_CC2 pin broken out. I Already have several of the GP variants laying around from a previous project and want to reuse them if possible.

Thanks for any input!

[waclawek.jan]

> Is it possible to substitute the UCPD1_CC2 function with the "Dead battery pulldowns" UCPD1_DBCC2?

No. UCPDx_DBCCx basically just controls a transistor, which switches the pulldown to the respective UCPDx_CCx pin.

JW

[XD]

Isn't that the main function of the CC pins when using USB-3/C in a "fixed mode" ie not DRD or PD.

As far as i can remember, placing 5.1k resistors between ground and the respective CC-pin is all that is required to signal the DFP that a device/UFP is connected and needs power.

Why wouldn't the UCPDx_DBCCx work for this?
They are just internal resistors controlled by a transistor.
I get that they might not be fast enough for negotiation but that isn't needed.

[waclawek.jan]

Your question was, whether the missing UCPD1_CC2 can be substituted by UCPD1_DBCC2.

My answer is that no; and the reason is, that UCPD1_DBCC2 does not have the functionality of UCPD1_CC2; its functionality is limited to controlling the 5k1 resistor - but that resistor is connected to the UCPD1_CC2 pin which is not brought out in the GP package.

JW

[FBL]

Hi @XD 

You are not implementing full stack of USB PD just type C only, as you mentioned you just need to tie CC lines to a pull down resistor and you can use DBCC pins as general purpose. Just be careful they have some specific behavior at boot. Refer to the IO structure and notes.
Honestly in your case, I would recommend using different package to adhere to the guidelines. Since on your package, CC2 are not exposed.

 

[XD]

Curiosity got the better of me, so I tried it out.
It does not seem to work, honestly a bit surprised.

Below is an image of a USB-C analyzer.
CC1 is inactive due to cable orientation.

The spikes indicate when the STM32G0 is connected, first in the orientation without CC1 then unplugged, flipped and connected with CC2. Third spike is back in the CC1 orientation.

I’ll switch over to the N variant, but does anyone know why it didn't work. I'm curious....