Introduction to USB Power Delivery with STM32

This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

On this page, you will find application examples, documents, tips, and tricks related to STM32 USB Type-C™ Power Delivery.

1 What is USB Power Delivery

The USB Type-C™ Power Delivery technology coming with the new reversible USB Type-C™ connector simplifies the consumers' daily life. The technology offers a single platform connector carrying all the necessary lines: USB 2.0, USB 3.x, and power.

The USB Type-C™ connector provides a native support of up to 15 W (5 V @ 3 A), extendable to 100 W (up to 20 V @ 5 A) with the optional USB Power Delivery feature.

Using the power delivery protocol allows negotiation of up to 100 W power delivery to supply or charge equipment connected to a USB port, the objective being to have fewer cables and connectors, as well as universal chargers.

The power delivery part extends the previous power specifications (USB 2.0, BC 1.2...) as detailed below :

USB 2.0	5 V	500 mA	Default Current, based on definitions in the base specifications
USB 3.1	5 V	900 mA	Default Current, based on definitions in the base specifications
USB BC 1.2	5 V	Up to 1.5 A	Legacy charging
USB Type-C™ @ 1.5 A	5 V	1.5 A	Supports high power devices
USB Type-C™ @ 3.0 A	5 V	3 A	Supports higher power devices
USB-PD	Configurable up to 20 V	Configurable up to 5 A	Directional control and power level management

The Type-C interface brings one new signal comparing to the previous USB cables: the CC lines. (control channel). On these lines, at 300 Kbit/s the power delivery protocol gives the possibility to exchange messages between the 2 connected partners.

The Power Delivery feature comes with a protocol that brings real-time possibilities :

change the power role. To change dynamically who provides VBUS, independently of the USB data role.
change the USB data role dynamically. This replaces the OTG from the previous USB specifications
carry authentication messages to authenticate the connected partner.
select an "Alternate Mode" to use the USB 3.0 super-speed lines to carry video information (Display port or HDMI)
firmware update
exchange battery information

To determine the power delivery role, a pull-up/down resistor must be presented on the CC lines, so that the power role change is reflected by the updated resistor on the CC lines. Whenever you have a "legacy cable" (Type-A to Type-C for example), to comply with the specification, it has an integrated resistor. As the Type-A/B does not have a CC line in the connector, the power role is determined by the pull-up/down resistor in the plug.

Frequent acronyms :

Acronym	Definition
AM	Alternate Mode: to specify the use of the super-speed lines for Video for example
APDO	Augmented power data object. It is a PDO in the case of PPS
DFP	Downstream Facing Port
DRP	Dual Role Power: the ability to change power role dynamically, meaning Source or Sink. The device toggles the pull-up/down resistor
GUI	Graphical User Interface = STM32CubeMonitor-UCPD
PDO	Power Data Object: the definition of a power capability
PPS	Programmable Power Supply: option in power delivery specification to be able to specify a voltage with 20 mV precision within a range.
SNK	Sink = device that will ask for VBUS
SRC	Source = device that will provide VBUS
TCPC	Type-C port controller
TCPM	Type-C port manager
UCPD	USB Type-C™ Power Delivery peripheral
UFP	Upstream facing port
VDM	Vendor Defined Message. Type of message used for the Alternate Mode

2 Getting started with STM32 and USB Power Delivery

Depending on the need, using the Type-C only may be enough, for example, if you need only 5V/3A. In that case, you do not need an MCU with the UCPD peripheral inside. Refer to AN5225 for more details.

If you need specific power delivery features (more than 3A, role changes...), then you need the stack, and you need to manage the CC1 and CC2 lines.

Reminder: even if there is only one CC line used for communication, you need to manage both lines, because you cannot guess how the cable will be plugged.

The Power Delivery protocol is provided by ST as a library as shown in the following picture:

The library (light pink box) only includes PE (Policy Engine), PRL (PRotocol Layer), and a part of CAD (CAble Detection). This library is common to all STM32 including the UCPD IP. The device part depends on the STM32 family (STM32G0, STM32G4...) The customer application is in DPM (Device Policy Manager). This is where the strategy (choose the maximum power...) is coded.

Here is a USBPD project example in IAR:

USBPD IAR Project example

In all our project examples, different folders can be found:

The Application/User folder contains the source files that we need to edit to enrich the application, particularly the *_user.c files.
The Drivers folder contains the HAL drivers for the STM32.
The Middleware folder contains the source files and the libraries for FreeRTOS and USB-PD stack.
The Utilities folder contains the GUI (STM32CubeMonitor-UCPD) and tracer embedded source files part.
The Output folder contains the compilation result files.

3 Video related to STM32 and USB Power Delivery

STM32G0: Create a USB Power Delivery sink application in less than 10 minutes.

4 STM32 compliant with USB Power Delivery

If you are looking for STM32 products that support Power Delivery, you can search in STM32CubeMX for the integration of the UCPD peripheral. STM32G0 is the only family with parts that contain up to 2 UCPD instances.

5 Specific tools

STM32CubeMonitor-UCPD for USB-C and Power Delivery is a tool to debug and configure the stack. DB3747

If the GUI responder is not activated in the embedded firmware, but the debug trace is available (UART through VCP of the STLink, and the compilation switch _TRACE activated) you may still see the trace in UCPD monitor by clicking on the Trace button in the bottom right corner.

USBPD UCPD Monitor Trace selection

USBPD UCPD Monitor COM Port Selection

The trace files are saved in c:\Users\your_login\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition\ with ".cpd" extension.

Note: the cpd files are a pretty good entry point to report an issue to our support team, it provides helpful debug information of the USB-PD stack behavior.

6 STMicroelectronics Resources

USB Type-C and Power Delivery solutions page
The general application note describing how to do power delivery with the STM32. AN5225
The USBPD stack user manual UM2552.
The AN5418 is a simple application note guiding on the creation of a Sink application with STM32CubeMX. Watch the video

7 Application examples

You can find a lot of application examples in the STM32G0 firmware package. For example, in Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD Or if you have downloaded the package through STM32CubeMX : c:\Users\your_login\STM32Cube\Repository\STM32Cube_FW_G0_V1.3.0\

MCU ref	Power role	User Manual	Application path
STM32G071B-Disco	Sink	UM2546	Projects\STM32G071B-DISCO\Demonstrations\USBPD_Analyzer
STM32G081B-Eval	Dual port DRP and Sink	UM2321	Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD Projects\STM32G081B-EVAL\Applications\USB-PD\USB-PD_Consumer_1port Projects\STM32G081B-EVAL\Applications\USB-PD\USB-PD_Provider_1port
B-G474E-DPOW1	DRP	UM2557	Projects\B-G474E-DPOW1\Applications\USB-PD\USB-PD_Consumer_1port
STM32G474E-EVAL	DRP	UM2514	Projects\STM32G474E-EVAL\Demonstrations\Demo Projects\STM32G474E-EVAL\Applications\USB-PD\USB-PD_Consumer_1port Projects\STM32G474E-EVAL\Applications\USB-PD\USB-PD_Provider_1port
STM32L552E-EVAL	Sink	UM2597	Projects\STM32L552E-EV\Demonstrations\Demo
NUCLEO-L552ZE-Q	Sink	UM2581	Projects\NUCLEO-L552ZE-Q\Applications\USB-PD\USB-PD_Consumer_1port

8 FAQ

8.1 Why cannot I get a higher voltage contract ?

If you stay to 5V contracts when testing a sink, and you cannot get a higher voltage using STM32CubeMonitor-USBPD, look in your trace if you have the message : "PE_EvaluateCapability: could not find desired voltage"

 Type	Time	Port	Message
 IN	8575	0	SRC_CAPABILITIES    DATA:2C9101082CD10200FAC00300C8B0040096400600  / 5V - 3A  / 9V - 3A  / 12V - 2.5A  / 15V - 2A  / 20V - 1.5A	SOP	 PD3	    H:0x51A1    
 OUT	8575	0	GOODCRC	SOP		    H:0x0001    
 PE	8575	0	PE_SNK_EVALUATE_CAPABILITY
 DEBUG	8577	0	PE_EvaluateCapability: could not find desired voltage

It means that your PDO defined for your sink, cannot find any matching PDOs on the source side. You will probably send a 5V request, using PDO number one :

 OUT	17508	1	REQUEST DATA: F4B10414 / ObjectPosition:1 / GiveBack:0 / CapabilityMismatch:1 / USBCommunicationCapable:0 / NoUSBSuspend:0 / UnchunkedExtendedMessagesSupported:0	SOP	 PD3	    H:0x1082

It could be that in your sink PDOs, you request too much current, and your source cannot support such requests. Check your PDOs either in the file usbpd_pdo_defs.h, or if you have activated the utility (_GUI_INTERFACE switch), in the STM32CubeMonitor-USBPD "Port Configuration/SINK Capabilities" tab. Perhaps your operational current is too high with respect to what your source can provide ?

8.2 How to analyze the failed return by the function USBPD_DPM_InitCore ?

This function is called at the init stage to initialize the USB-PD application (device and stack part)

  /* Check the lib selected */
  if (USBPD_TRUE != USBPD_PE_CheckLIB(_LIB_ID))
  {
    return USBPD_ERROR;
  }

At this stage, the software is checking if the LIB files selected to build the project and the compilation switch USBPDCORE_LIB****** are aligned.

Definition available in usbpd_def.h

  /* _LIB_ID definition */
  /*
    _LIB_ID constructs like this: 0xXYVVVWWW
    * X: 3 (PD3.0) or 2 (PD2.0)
    * Y: 0 (CORE) or 1 (TCPM)
    * VVV: Stack version (ex 200 for Stack 2.0.0)
    * WWW: 0 (FULL VERSION) or config_x
  */

For instance, if the lib 'USBPDCORE_PD3_FULL_CM*.*' is selected, the user should enable the switch 'USBPDCORE_LIB_PD3_FULL'

8.3 How to know the memory needed by the stack ?

This is done dynamically in the stack, depending on the linked USBPD library :

 stack_dynamemsize = USBPD_PE_GetMemoryConsumption();

This stage is optional (could be removed) and only present to know how much memory is needed in the USB-PD stack to help define the correct value of the HEAP.

8.4 How to insert my own debug information inside the trace system ?

Add Debug trace inside embedded code :

by using the USBPD_TRACE_Add from file usbpd_trace.c, you can print information inside the GUI tools

         USBPD_TRACE_Add(6, 0, 0, 'string', 'string size');

example :

Debug trace in STM32CubeMonitor-UCPD when _GUI_INTERFACE is disabled

          USBPD_TRACE_Add(6, 0, 0, "hello world", 11);

Check the line "DEBUG hello world" in gray on the following pictures (Click to enlarge). The numbers indicated in the trace are the TimeStamp and the port number. (TimeStamp can be practical to debug real-time issues)

Debug trace in STM32CubeMonitor-UCPD when _GUI_INTERFACE is enabled

Add livewatch on CAD_HW_Handles. This variable can be used to check the Type-C attachment or detachment.

See usbpd_cad_hw_if.c:

  #define USBPD_CAD_STATE_RESET 0u /*!< USBPD CAD State Reset */
  #define USBPD_CAD_STATE_DETACHED 1u /*!< USBPD CAD State No cable detected */
  #define USBPD_CAD_STATE_ATTACHED_WAIT 2u /*!< USBPD CAD State Port partner detected */
  #define USBPD_CAD_STATE_ATTACHED 3u /*!< USBPD CAD State Port partner attached */

If the CC lines are empty, check that the TCPP is passed through, which means that the active LOW _DB pin is disabled at 3.3 V. This is due to the jumpers or some GPIO settings.

Note: In the current STM32CubeMX for STM32G4, there is an issue with the default GPIO mode for CC2. In usbpd_cad_hw_if.c there must be: LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG); In STM32G4 versions before FW 1.2.0, the correct compilation switch is not set. An easy way to correct this issue is to activate the compilation switch MB1367.

You can add the compilation switch __DEBUG_CAD to have more information in trace about the CAD state machine.

Using STM32CubeMonitor-UCPD you will be able to see the debug traces :

 Type	TimeStamp	Port		Message
 CAD	17152		1	      	USBPD_CAD_STATE_ATTACHED_WAIT
 CAD	17356		1		USBPD_CAD_STATE_ATTACHED0

...

 CAD	19418		1		USBPD_CAD_STATE_DETACHED

For further debug, the VBUS measured value can be printed in the trace, using the user button.

Add in src/main.c:

  /**
  * @brief EXTI line detection callbacks
  * @param GPIO_Pin Specifies the pins connected EXTI line
  * @retval None
  */
  void HAL_GPIO_EXTI_Falling_Callback(uint16_t GPIO_Pin)
  {
  	if (GPIO_Pin == USER_BUTTON_PIN) /* Will display in trace the VBUS value when the user button is pressed */
  	{
  		char _str[10];
  		BSP_PWR_VBUSGetVoltage(0);
  		sprintf(_str,"VBUS:%d", BSP_PWR_VBUSGetVoltage(0));
  		USBPD_TRACE_Add(USBPD_TRACE_DEBUG, 0, 0, (uint8_t*)_str, strlen(_str));
  	}
  }

and the corresponding interrupt in src/stm32g0xx_it.c:

  /**
  * @brief This function handles external line 4_15 interrupt request.
  * @retval None
  */
  void EXTI4_15_IRQHandler(void)
  {
  	HAL_GPIO_EXTI_IRQHandler(USER_BUTTON_PIN);
  }

8.5 Why a request function returned USBPD_OK but I cannot see the message in the trace ?

All the request functions (like USBPD_DPM_RequestDataRoleSwap) will not trig directly the sending of the message to the port partner. The idea is to post a request to the stack and when the stack is ready, it will consume this request to send it to the port partner.

Note1: only 1 request is possible. Another request sent whereas the previous one has not been consumed will be not taken in account (USBPD_BUSY status will be returned).

Note2: USBPD_BUSY is also returned if there are no connected port partner.

8.6 About FreeRTOS in our stack

Tasks creations are done in usbpd_dpm_core.c file. At the initialization, the USB-PD creates 2 threads:

CAD Task: used for the cable detection (higher priority in our system set to osPriorityRealtime)
TRA_TX: used to evacuate the debug trace (set to osPriorityLow priority)

When the Type-C is connected, we create a dynamic task for PE_TASK set to a priority lower than CAD, osPriorityAboveNormal (done through callback ‘USBPD_DPM_CADCallback’. It allows starting a PD negotiation. The task is killed if a detach is done.

In usbpd_dpm_user.c, we create also a task for DPM set as low priority

DPM task: used mainly to manage the specification to be done after the timer expiration like:
- Management of ALERT messages
- Management of SRC_CAPA_EXT messages …

Two different scenarios:
1- No Type-C cable connected:

In DRP mode, we have a CAD toggle to switch every 40 ms from Source (present Rp) to Sink (present Rd). Then the CAD task is woken up regularly (every 40 ms)
In SRC or SNK mode, CAD will be woken up if an event occurs on the CC lines (through ‘USBPD_DPM_CADCallback’ function)

2- Type-C cable connected:

If the Power Delivery negotiation is OK, CAD and PE should wait for a new event, and CAD will be woken up:
- In SRC: due to an event on the CC lines (through ‘USBPD_DPM_CADCallback’ function)
- In SNK: every 10 ms or an event on the CC lines, PE will be woken up only if a message is sent or received (through ‘USBPD_PE_TaskWakeUp’ function)
Negotiation failed:
- In SNK, CAD will be woken up every 10 ms or if an event occurs on the CC lines
- In SRC, if no answer from the port partner:
  - PE_CapscounterSupport = 0: PE wakes up every 150 ms
  - PE_CapscounterSupport = 1: the system wakes up only after a change on the CC lines

Normally, during the CAD/PE sleep, FreeRTOS should provide the control to other tasks having a lower priority (thanks to osDelay function for instance). There are no real reason for another task with less priority to take the control.

8.7 SNK PDO selection policy in DPM

On SNK side, when SRC capabilities are received from the SRC port, the SNK has to select the SRC PDOs that will be used for building the REQUEST message to be sent to the attached SRC port. The selection of this PDO among all available SRC PDOs is under the SNK responsibility, and is achieved through a DPM callback, called by PE during the Explicit Contract negotiation. The callback that will determine the PDO that the SNK will try to request, is the USBPD_DPM_SNK_EvaluateCapabilities() function. This function (executed on SNK side) aims to identify the PDO within those presented by the SRC, that will match the SNK requirements as much as possible. In Demonstrations code, the current content of USBPD_DPM_SNK_EvaluateCapabilities() code, provides an example of the SNK PDO selection policy, aiming to select the SRC PDO that will provide the maximum power according to the SNK requirements.

This part of the SNK port implementation is described in the below scheme :

Description of SNK PDO selection policy example in Demo DPM code

The current policy is now implemented in Demonstrations projects available in STM32G0, G4 or L5 firmware packages :

STM32G0 firmware package : Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD
STM32G4 firmware package : Projects\STM32G474E-EVAL\Demonstrations\Demo
STM32L5 firmware package : Projects\STM32L552E-EV\Demonstrations\Demo

This is only an example and this policy could be updated according to application needs. For example, if application wants to implement its own policy of selection of the SRC PDO to use in the REQUEST message, it could be done in DPM_FindVoltageIndex() function.

8.8 Why is the PD message not sent by the stack ?

The Policy Engine schedules the PD message to be sent with a system of timer. If the timers are not managed (decremented) the stack will be not able to send the message. To avoid this issue, check if the function USBPD_DPM_TimerCounter is called inside SysTick_Handler (file stm32xxxx_it.c) or any tick system management.

        void SysTick_Handler(void)
        {
             USBPD_DPM_TimerCounter();
             HAL_IncTick();
        }