Custom USB PD Implementation on STM32G0

Hello Tim,

As you noticed, X-CUBE-USB-PD package has been designed as an expansion package for STM32F0 serie. Goal of this package was to provide a first implementation of USB PD solution based on existing STM32F0 device + additional HW or external component (as STUSB1602).

Inside this package, you could find inside Middlewares/ST/STM32_USBPD_Library/ directory :

- ST USBPD Core stack library. This part is platform independent from STM32 it is running on, only need to select the proper library version, according to Cortex M version within your device.

- ST USBPD Device component (F0 or STUSB1602 depending of which HW kit you are using). This part is platform dependent.

After this X-CUBE package has been made available, new serie STM32G0 is embedding a USBPD IP. So, with a G0, no more need of complex HW AFE nor external component as STUSB1602.

So to answer your first question : no need for STUSB1602 when using G0.

Some of the basic functions required for USBPD implementation are natively achieved by STM32G0, lightening CPU load :

- Preamble generation/recovery

- EOP detection

– 4b5b encoding/decoding

– BMC (bi-phase mark) coding/decoding

– CRC generation (Tx) and checking (Rx)

- ...

So in STM32G0 Cube Firmware Package (please look for STM32CubeG0 on st.com website, v1.2.0 package now available, 1.3.0 to come), you could also find our USBPD Core stack (up to date version compared to the one delivered in X-Cube package) and G0 dedicated device.

STM32G0 Firmware package also contains some examples of USBPD applications. 2 basic applications (located into Projects\STM32G081B-EVAL\Applications\USB-PD directory) :

- 1 Consumer (Sink, 1 port, built using CubeMx)

- 1 Provider (Source, 1 port, built using CubeMx)

In addition, you could also have a look at the demo project available in Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD directory, which is handling 2 ports (1 DRP + 1 SNK).

All these examples are provided in full source (except the core Stack library) so you could easily update SW on your side for all applicative part.

Regarding your question on authentication, indeed, a Sink, i.e. being charged when connected to a Source, might want to prevent that out of specs charging devices (Source) may be used.

can set a policy in their products requiring that only certified PD products be used for charging.

Authentication procedure allows Sink to authenticate the connected Source entity. When Source is authenticated, Sink could request safely highest offered power.

Among the 2 solutions for authenticating a Source, that you mentioned, 1st one might be easier to implement, but also easier to workaround.

2nd one, consists in implementing method described in the USB Type C Authentication Specification.

From USB-PD stack point of view, implementation of Authentication only requires support of USB Type-C Power Delivery, revision 3.0, with support of Extended messages.

All data exchanged between the 2 ports will be carried through Security messages exchange

Implementation of the authentication mechanism is then done on application side.

What is needed :

- Random numbers generation : used in challenge procedure. Could be achieved using STM32G0 RNG IP.

- X509v3 ASN.1 structure parsing (DER encoding) : used for Certificate format

- ECDSA (NIST P256 secp256r1 curve, uncompressed point) : used for Digital signing of Certificates and Authentication Messages

- SHA256 : used for HASH computations. Not available on G0, but available on STM32 G4 which also embeds same UCPD IP (1 port only).

- Secure storing of Certificates, and especially of Private key on Responder side (the authenticated side).

Hope this helps a little.

Please feel free to raise new questions if needed.

Regards

Guenael