Difference between revisions of "USB Power Delivery overview"

[quality revision] [pending revision]
m
m
 

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[edit]

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

1.1 Power delivery features[edit]

The power delivery 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 :

1.2 Default USB role[edit]

Once the power role is defined (at the attach state) the default data role is induced as follow :

Power role at the attachment Default USB role
Source (Provider) DFP (Host)
Sink (Consumer) UFP (Device)

The power role is independent of the data role. You may need to ask for a data role swap if you need a precise USB data role.

1.3 Frequent acronyms[edit]

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 (Host data role)
DP Display Port
DRP Dual Role Power: the ability to change power role dynamically, meaning Source or Sink. The device toggles the pull-up/down resistor
EMC Electronically Marked Cable
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 (Device data role)
VDM Vendor Defined Message. Type of message used for the Alternate Mode

2 Getting started with STM32 and USB Power Delivery[edit]

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.

USBPD Type-C cable orientation
Electronically marked cable : Direct connection on the left/ flipped connection on the right

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

USBPD stack architecture

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[edit]

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

4 STM32 compliant with USB Power Delivery[edit]

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[edit]

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%username%\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[edit]

7 Application examples[edit]

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[edit]

8.1 Why cannot I get a higher voltage contract ?[edit]

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 ?[edit]

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 ?[edit]

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 ?[edit]

  • 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 ?[edit]

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[edit]

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[edit]

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 :

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 ?[edit]

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();
        }

8.9 How DP does it work on EVAL-G081 demonstration ?[edit]

This part is to describe the mechanism used in our demonstration to be able to connect a laptop to a screen through Port2_Sink port. This is a add-on of the description done in UM2321 (4.3.7 Display Port demonstration, Fig.63)

G0 role is to:

  1. Detect connection of laptop on Type-C:
    1. establish a PD contract
      1. if contract is established in SRC/DFP configuration, application has to request a data role swap for switching in UFP mode (cf Figure 36. Data role swap generation in UM2552)
    2. configure MUX (DL and AUX lines) according to the CC orientation and Laptop request (VDM negociation)
  2. Detect HPD pin linked to a connection/disconnection on DP port (screen)
    1. May send SVDM attention message to laptop to indicate a connection/disconnection of DP cable

The following picture is based on convention defined in UM2552 (§4)

All the user code can be found in the usbpd_vdm_user.c file available in the EVAL-G081 demonstration.

Moreover, ST provides a DP connector based on STM32F0: STEVAL-USBC2DP. An Techical Note has been provided with this board: TA0356




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

==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 delivery features ===
The power delivery 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 :=== Default USB role ===
Once the power role is defined (at the attach state) the default data role is induced as follow :
{|
|-
! Power role at the attachment !! Default USB role
|-
| Source (Provider) || DFP (Host)
|-
| Sink (Consumer) || UFP (Device)
|-
|}
The power role is independent of the data role.
You may need to ask for a data role swap if you need a precise USB data role.

=== 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 |-
| (Host data role)
|-
| DP|| Display Port
|-
| DRP|| Dual Role Power: the ability to change power role dynamically, meaning Source or Sink. The device toggles the pull-up/down resistor
|-
| EMC || Electronically Marked Cable
|-
| 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 (Device data role)|-
| VDM|| Vendor Defined Message. Type of message used for the Alternate Mode 
|}

==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 [https://www.st.com/resource/en/application_note/dm00536349.pdf 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. <br>


'''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.
[[File:USBPD-Orientation-detection.jpg|center|USBPD Type-C cable orientation| 800px]]<div style='text-align: center;'>Electronically marked cable : Direct connection on the left/ flipped connection on the right</div>

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

[[File:USBPD Stack Architecture.jpg|center|USBPD stack architecture]]
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''':
[[File:USBPD Project presentation.jpg|thumb|center|USBPD IAR Project example|500px]]
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.

==Video related to STM32 and USB Power Delivery==
[[File:pc_videol.png|left|20px|link=https://youtu.be/Z_Sn6CBbz-k]] [https://youtu.be/Z_Sn6CBbz-k  STM32G0: Create a USB Power Delivery sink application in less than 10 minutes].<br>


==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.

==Specific tools==
* [https://www.st.com/en/development-tools/stm32cubemonucpd.html STM32CubeMonitor-UCPD] for USB-C and Power Delivery is a tool to debug and configure the stack. [https://www.st.com/resource/en/data_brief/stm32cubemonucpd.pdf 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.<br>

[[File:UCPDMonitor Trace selection.jpg|thumb|center|USBPD UCPD Monitor Trace selection|500px]]
[[File:USBPD UCPDMonitor ComPort Selection.jpg|thumb|center|USBPD UCPD Monitor COM Port Selection|600px]]
The trace files are saved in c:\Users\''your_login''%username%\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.

==STMicroelectronics Resources==
* [https://www.st.com/en/applications/connectivity/usb-type-c-and-power-delivery.html USB Type-C and Power Delivery solutions page]
* The general application note describing how to do power delivery with the STM32. [https://www.st.com/resource/en/application_note/dm00536349.pdf AN5225]
* The USBPD stack user manual [https://www.st.com/resource/en/user_manual/dm00598101.pdf UM2552].
* The [https://www.st.com/resource/en/application_note/dm00663511.pdf AN5418] is a simple application note guiding on the creation of a Sink application with STM32CubeMX. [https://youtu.be/Z_Sn6CBbz-k Watch the video]

== Application examples==
You can find a lot of application examples in the STM32G0 firmware package. For example, in [https://github.com/STMicroelectronics/STM32CubeG0/tree/master/Projects/STM32G081B-EVAL/Demonstrations/DemoUCPD Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD]
Or if you have downloaded the package through [https://www.st.com/en/development-tools/stm32cubemx.html STM32CubeMX] : c:\Users\''your_login''\STM32Cube\Repository\STM32Cube_FW_G0_V1.3.0\
{|
|-
! MCU ref !! Power role !! User Manual !! Application path
|-
|[https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-discovery-kits/stm32g071b-disco.html STM32G071B-Disco]|| Sink || [https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/b8/f8/e2/b2/73/84/4a/e2/DM00595951/files/DM00595951.pdf/jcr:content/translations/en.DM00595951.pdf UM2546]
|Projects\STM32G071B-DISCO\Demonstrations\USBPD_Analyzer
|-
|[https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-eval-boards/stm32g081b-eval.html STM32G081B-Eval]|| Dual port DRP and Sink|| [https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/06/b5/81/fe/fb/a8/46/d9/DM00452280/files/DM00452280.pdf/jcr:content/translations/en.DM00452280.pdf UM2321]
|Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD<br>

Projects\STM32G081B-EVAL\Applications\USB-PD\USB-PD_Consumer_1port<br>

Projects\STM32G081B-EVAL\Applications\USB-PD\USB-PD_Provider_1port
|-
|[https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-discovery-kits/b-g474e-dpow1.html B-G474E-DPOW1]|| DRP|| [https://www.st.com/resource/en/user_manual/dm00613627-discovery-kit-with-stm32g474re-mcu-stmicroelectronics.pdf UM2557]
|Projects\B-G474E-DPOW1\Applications\USB-PD\USB-PD_Consumer_1port
|-
|[https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-eval-boards/stm32g474e-eval.html STM32G474E-EVAL]|| DRP|| [https://www.st.com/resource/en/user_manual/dm00564162-evaluation-board-with-stm32g4xxqe-mcu-stmicroelectronics.pdf UM2514]
|Projects\STM32G474E-EVAL\Demonstrations\Demo<br>

Projects\STM32G474E-EVAL\Applications\USB-PD\USB-PD_Consumer_1port<br>

Projects\STM32G474E-EVAL\Applications\USB-PD\USB-PD_Provider_1port
|-
|[https://www.st.com/en/evaluation-tools/stm32l552e-ev.htmll STM32L552E-EVAL]|| Sink|| [https://www.st.com/resource/en/user_manual/dm00623588-evaluation-board-with-stm32l552ze-mcu-stmicroelectronics.pdf UM2597]
|Projects\STM32L552E-EV\Demonstrations\Demo
|-
|[https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-nucleo-boards/nucleo-l552ze-q.html NUCLEO-L552ZE-Q]|| Sink|| [https://www.st.com/resource/en/user_manual/dm00615305-stm32l5-nucleo144-board-mb1361-stmicroelectronics.pdf UM2581]
|Projects\NUCLEO-L552ZE-Q\Applications\USB-PD\USB-PD_Consumer_1port
|}

==FAQ==
=== 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 ?

=== 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) <syntaxhighlight lang="c">

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

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<syntaxhighlight lang="c">

  /* _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
  */</syntaxhighlight>

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

=== 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.

=== 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''' :[[File:USBPD Trace debug.jpg|thumb|center|600px|Debug trace in STM32CubeMonitor-UCPD when _GUI_INTERFACE is disabled]]<br>


           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)<br>

[[File:Trace debug.jpg|thumb|center|680px|Debug trace in STM32CubeMonitor-UCPD when _GUI_INTERFACE is enabled]]<br>


* 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:<syntaxhighlight lang="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 */</syntaxhighlight>

* 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:<syntaxhighlight lang="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));
  	}
  }</syntaxhighlight>

and the corresponding interrupt in src/stm32g0xx_it.c:<syntaxhighlight lang="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);
  }</syntaxhighlight>

=== 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.

=== About FreeRTOS in our stack ===
Tasks creations are done in usbpd_dpm_core.c file.
At the initialization, the USB-PD creates 2 threads:<br>

*	CAD Task: used for the cable detection (higher priority in our system set to osPriorityRealtime)<br>

*	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<br>

*	DPM task: used mainly to manage the specification to be done after the timer expiration like:<br>

** Management of ALERT messages<br>

** Management of SRC_CAPA_EXT messages …

Two different scenarios:<br>

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)<br>

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.

=== 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 <code> '''''USBPD_DPM_SNK_EvaluateCapabilities()'''''</code> 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 :

[[File:SNK PDO Selection.jpg|thumb|center|Description of SNK PDO selection policy example in Demo DPM code| 900px]]

The current policy is now implemented in Demonstrations projects available in STM32G0, G4 or L5 firmware packages :
* STM32G0 firmware package : [https://github.com/STMicroelectronics/STM32CubeG0/tree/master/Projects/STM32G081B-EVAL/Demonstrations/DemoUCPD Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD]
* STM32G4 firmware package : [https://github.com/STMicroelectronics/STM32CubeG4/tree/master/Projects/STM32G474E-EVAL/Demonstrations/Demo Projects\STM32G474E-EVAL\Demonstrations\Demo]
* STM32L5 firmware package : [https://github.com/STMicroelectronics/STM32CubeL5/tree/master/Projects/STM32L552E-EV/Demonstrations/Demo 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<code> '''''DPM_FindVoltageIndex()'''''</code> function.

=== 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.
<syntaxhighlight lang="c">

        void SysTick_Handler(void)
        {
             USBPD_DPM_TimerCounter();
             HAL_IncTick();
        }</syntaxhighlight>

=== How DP does it work on EVAL-G081 demonstration ? ===

This part is to describe the mechanism used in our demonstration to be able to connect a laptop to a screen through Port2_Sink port.
This is a add-on of the description done in [https://www.st.com/resource/en/user_manual/dm00452280-stm32cubeg0-demonstration-firmware-stmicroelectronics.pdf UM2321] (4.3.7 Display Port demonstration, Fig.63)

G0 role is to:
# Detect connection of laptop on Type-C: 
## establish a PD contract
### if contract is established in SRC/DFP configuration, application has to request a data role swap for switching in UFP mode (cf Figure 36. Data role swap generation in [https://www.st.com/resource/en/user_manual/dm00598101-managing-usb-power-delivery-systems-with-stm32-microcontrollers-stmicroelectronics.pdf UM2552])
## configure MUX (DL and AUX lines) according to the CC orientation and Laptop request (VDM negociation)
# Detect HPD pin linked to a connection/disconnection on DP port (screen)
## May send SVDM attention message to laptop to indicate a connection/disconnection of DP cable

The following picture is based on convention defined in [https://www.st.com/resource/en/user_manual/dm00598101-managing-usb-power-delivery-systems-with-stm32-microcontrollers-stmicroelectronics.pdf UM2552] (§4)

[[File:AMS_Convention_Color.jpg|thumb|center|Atomic Message Sequence color legend| 500px]]

[[File:VDM_CompleteDPTransaction.png|thumb|center|Description of DP transaction example in Demo code| 900px]]

All the user code can be found in the [https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Projects/STM32G081B-EVAL/Demonstrations/DemoUCPD/Src/usbpd_vdm_user.c usbpd_vdm_user.c] file available in the EVAL-G081 demonstration.

Moreover, ST provides a DP connector based on STM32F0: [https://www.st.com/en/evaluation-tools/steval-usbc2dp.html STEVAL-USBC2DP]. An Techical Note has been provided with this board: [https://www.st.com/resource/en/technical_article/dm00479305-usb-typec-and-power-delivery-displayport-alternate-mode-stmicroelectronics.pdf TA0356]
{{PublicationRequestId | 14852| 2020-01-29 |}} <noinclude>

{{ArticleBasedOnModel | Example tech domain article}}
[[Category:USB Power Delivery]]</noinclude>
(13 intermediate revisions by 3 users not shown)
Line 27: Line 27:
 
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 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 :
+
=== Power delivery features ===
  +
The power delivery 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 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
 
* change the USB data role dynamically. This replaces the OTG from the previous USB specifications
Line 38: Line 39:
 
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.
 
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 :
+
=== Default USB role ===
  +
Once the power role is defined (at the attach state) the default data role is induced as follow :
  +
{|
  +
|-
  +
! Power role at the attachment !! Default USB role
  +
|-
  +
| Source (Provider) || DFP (Host)
  +
|-
  +
| Sink (Consumer) || UFP (Device)
  +
|-
  +
|}
  +
The power role is independent of the data role.
  +
You may need to ask for a data role swap if you need a precise USB data role.
  +
 
  +
=== Frequent acronyms ===
 
{|
 
{|
 
|-
 
|-
Line 47: Line 62:
 
| APDO|| Augmented power data object. It is a PDO in the case of PPS
 
| APDO|| Augmented power data object. It is a PDO in the case of PPS
 
|-
 
|-
| DFP|| Downstream Facing Port
+
| DFP|| Downstream Facing Port (Host data role)
  +
|-
  +
| DP|| Display Port
 
|-
 
|-
 
| DRP|| Dual Role Power: the ability to change power role dynamically, meaning Source or Sink. The device toggles the pull-up/down resistor
 
| DRP|| Dual Role Power: the ability to change power role dynamically, meaning Source or Sink. The device toggles the pull-up/down resistor
  +
|-
  +
| EMC || Electronically Marked Cable
 
|-
 
|-
 
| GUI|| Graphical User Interface = STM32CubeMonitor-UCPD
 
| GUI|| Graphical User Interface = STM32CubeMonitor-UCPD
Line 67: Line 86:
 
| UCPD|| USB Type-C™ Power Delivery peripheral
 
| UCPD|| USB Type-C™ Power Delivery peripheral
 
|-
 
|-
| UFP|| Upstream facing port
+
| UFP|| Upstream facing port (Device data role)
 
|-
 
|-
 
| VDM|| Vendor Defined Message. Type of message used for the Alternate Mode  
 
| VDM|| Vendor Defined Message. Type of message used for the Alternate Mode  
Line 79: Line 98:
 
'''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.
 
'''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.
 
[[File:USBPD-Orientation-detection.jpg|center|USBPD Type-C cable orientation| 800px]]
 
[[File:USBPD-Orientation-detection.jpg|center|USBPD Type-C cable orientation| 800px]]
  +
<div style='text-align: center;'>Electronically marked cable : Direct connection on the left/ flipped connection on the right</div>
  +
 
The Power Delivery protocol is provided by ST as a library as shown in the following picture:
 
The Power Delivery protocol is provided by ST as a library as shown in the following picture:
   
Line 108: Line 129:
 
[[File:UCPDMonitor Trace selection.jpg|thumb|center|USBPD UCPD Monitor Trace selection|500px]]
 
[[File:UCPDMonitor Trace selection.jpg|thumb|center|USBPD UCPD Monitor Trace selection|500px]]
 
[[File:USBPD UCPDMonitor ComPort Selection.jpg|thumb|center|USBPD UCPD Monitor COM Port Selection|600px]]
 
[[File:USBPD UCPDMonitor ComPort Selection.jpg|thumb|center|USBPD UCPD Monitor COM Port Selection|600px]]
The trace files are saved in c:\Users\''your_login''\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition\ with ".cpd" extension.
+
The trace files are saved in c:\Users\%username%\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.
 
'''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.
Line 321: Line 342:
 
         }
 
         }
 
</syntaxhighlight>
 
</syntaxhighlight>
  +
  +
=== How DP does it work on EVAL-G081 demonstration ? ===
  +
  +
This part is to describe the mechanism used in our demonstration to be able to connect a laptop to a screen through Port2_Sink port.
  +
This is a add-on of the description done in [https://www.st.com/resource/en/user_manual/dm00452280-stm32cubeg0-demonstration-firmware-stmicroelectronics.pdf UM2321] (4.3.7 Display Port demonstration, Fig.63)
  +
  +
G0 role is to:
  +
# Detect connection of laptop on Type-C:
  +
## establish a PD contract
  +
### if contract is established in SRC/DFP configuration, application has to request a data role swap for switching in UFP mode (cf Figure 36. Data role swap generation in [https://www.st.com/resource/en/user_manual/dm00598101-managing-usb-power-delivery-systems-with-stm32-microcontrollers-stmicroelectronics.pdf UM2552])
  +
## configure MUX (DL and AUX lines) according to the CC orientation and Laptop request (VDM negociation)
  +
# Detect HPD pin linked to a connection/disconnection on DP port (screen)
  +
## May send SVDM attention message to laptop to indicate a connection/disconnection of DP cable
  +
  +
The following picture is based on convention defined in [https://www.st.com/resource/en/user_manual/dm00598101-managing-usb-power-delivery-systems-with-stm32-microcontrollers-stmicroelectronics.pdf UM2552] (§4)
  +
  +
[[File:AMS_Convention_Color.jpg|thumb|center|Atomic Message Sequence color legend| 500px]]
  +
  +
[[File:VDM_CompleteDPTransaction.png|thumb|center|Description of DP transaction example in Demo code| 900px]]
  +
  +
All the user code can be found in the [https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Projects/STM32G081B-EVAL/Demonstrations/DemoUCPD/Src/usbpd_vdm_user.c usbpd_vdm_user.c] file available in the EVAL-G081 demonstration.
  +
  +
Moreover, ST provides a DP connector based on STM32F0: [https://www.st.com/en/evaluation-tools/steval-usbc2dp.html STEVAL-USBC2DP]. An Techical Note has been provided with this board: [https://www.st.com/resource/en/technical_article/dm00479305-usb-typec-and-power-delivery-displayport-alternate-mode-stmicroelectronics.pdf TA0356]
   
 
{{PublicationRequestId | 14852| 2020-01-29 |}}  
 
{{PublicationRequestId | 14852| 2020-01-29 |}}