How to create basic USBPD sink application with STM32G431KB?

[ardnew]

I purchased a NUCLEO-G431KB to begin and test firmware development of my project, using the latest STM32CubeIDE with the STM32Cube_FW_G4_V1.1.0 library BSP.

Following several USBPD library examples of a sink application -- and some considerable configuration to FreeRTOS and the initial STM32Cube-generated code -- I am able to build the firmware, flash the target, and debug via ST-Link running on the little NUCLEO device. 

I can verify the USBPD middleware thread and the TRACER_EMB utility thread are being created by FreeRTOS. But the main USBPD process that listens for USB Type-C cable attach/detach seems to hang and never return (and it never calls any of the installed callback functions). This function is part of the CAD module I believe and is named USBPD_CAD_Process(). 

Unfortunately this function is implemented in the library core USBPDCORE_PD3_FULL_CM4_wc32.a (binary distribution), so I don't have any visibility into why it is hanging or not calling my callback functions. And I can't find any good documentation on troubleshooting this area of USBPD library either.

Also a side note -- I'm not real certain how to actually use the TRACER_EMB utility, and the STM32CubeMon-UCPD application does not detect any boards present when I have the target running.

--

EDIT:

My hardware setup is as follows. Equipment:

1. NUCLEO-G431KB ( 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-g431kb.html )
2. USB 3.1/3.2 Type-C female receptacle breakout ( https://www.saikosystems.com/web/p-86-usb-type-c-female-receptacle-breakout-board-v20.aspx )
3. Apple 87W USB-C Power Adapter ( https://www.apple.com/shop/product/MNF82LL/A/87w-usb-c-power-adapter )

Configuration:

• Both (1) and (2) are placed on a breadboard. 
• Jumper wires connecting all VBUS pins of (2) are connected to the open power rail on the breadboard. 
• Jumper wires connecting all GROUND pins of (2) are connected to the open ground rail on the breadboard. 
• Jumper wire connecting pin CC1 of (2) is connected to the UCPD_CC1 pin of (1).
• Jumper wire connecting pin CC2 of (2) is connected to the UCPD_CC2 pin of (1).

With a digital multimeter attached to the open power and ground rails on the breadboard, I can verify that 5 V (default power profile per USB spec) is present when both the NUCLEO (1) is running my USBPD firmware, and the power adapter is plugged into the Type-C receptacle (2). 

If I disconnect and reconnect the power adapter to (2) while (1) is NOT running my USBPD firmware, the 5 V supply is NOT present again until the NUCLEO (1) target resets and begins running the firmware again. Therefore, I am fairly certain the USBPD library is functioning correctly to some extent, it just doesn't seem to be communicating with the main application.

[Yohann M.]

Dear Andrew,

I have a question linked to your VBUS connnection. How to do you measure it?

In our reference design, I added a voltage divider on VSENSE and map it on ADC channel on our MCU.

For instance, on our NUCLEO-G474RE, we use a TCPP01-M12 extenstion board and read the VBUS thanks to the VSENSE pin connected to our ADC:

Please find a message sequence chart for SINK connection:

"Is VBUS On?" is done through functions:

=> ManageStateAttachedWait_SNK -> CAD_Check_VBus -> HW_IF_PWR_GetVoltage -> BSP_PWR_VBUSGetVoltage

And then in 'usbpd_pwr_user.c', when CAD detects a connection, it should wait for getting VBUS at 5V before starting PD stack thanks to the following function:

uint32_t BSP_PWR_VBUSGetVoltage(uint32_t PortId)
{
/* USER CODE BEGIN BSP_PWR_VBUSGetVoltage */
 uint32_t voltage;
 
 voltage = __LL_ADC_CALC_DATA_TO_VOLTAGE(VDDA_APPLI, ((uint32_t)LL_ADC_REG_ReadConversionData12(VSENSE_ADC_INSTANCE)), LL_ADC_RESOLUTION_12B); /* mV */
 
 /* STM32G474E_EVAL board is used */
 /* Value is multiplied by 5.97 according to board measurments.
 Theorically, it should have been 5.97 (Divider R6/R7 (40.2K/200K) for VSENSE */
 voltage *= 597U;
 voltage /= 100U;
 
 return voltage;
/* USER CODE END BSP_PWR_VBUSGetVoltage */
}

Could you please check in your side if you respect the above condition?

Regards

Yohann

[ardnew]

Thank you very much for such great detail! I was attempting to measure VBUS by setting the following option in the device configuration tool in STM32CubeIDE:

Under Pinout & Configuration > System Core > SYS; for option Power Voltage Detector In, I selected External Input Analog Voltage, but I wasn't wiring anything from the Type-C port to that pin on the MCU, as I didn't realize it was necessary for basic cable detection (I assumed it only needed the CC pins).

But looking at your message sequence chart for SNK, I now see why it is necessary! I also see that I'm using the wrong mechanism for VBUS measurement. According to the video linked by @Nicolas P​ in the other answer, it suggests the USBPD stack actually depends on defining the user label of an ADC pin to "VSENSE". So this is how a given ADC input is associated with the USBPD stack?

I am positive I do not correctly implement the VBUS measurement in BSP_PWR_VBUSGetVoltage. I will implement the required ADC configuration and VBUS measurement routines, and I will copy your same voltage divider and attach VBUS to the ADC input. I can use my multimeter to finesse the multipliers appropriately.

I don't believe I have the necessary components to implement proper CC-short-to-VBUS protection (not sure what components I need or how I would do that anyway), like your TCPP01-M12 offers. I'll need to do more research for that.

I will make these changes when I get home tonight after work and report back my findings. Again, thanks a bunch.

[Nicolas P.]

Hello,

which STM32CubeMx version are you using ?

You can have a look at this video, even if it is targeted to STM32G0, based on STM32CubeMX 5.4.0.

The detailed application note giving all the details is coming very soon.

Nicolas

[ardnew]

The video you linked was fantastic -- very, very insightful!

I am using STM32CubeIDE 1.1.0, build 4551_20191014-1140. I am not using a standalone installation of STM32CubeMX, just the version integrated with CubeIDE, which is STM32CubeMX 5.4.0 build 20191009-1541.

I have a few questions regarding the video:

1. When configuring FreeRTOS, how do you determine the heap size TOTAL_HEAP_SIZE? The example sets it to 5000 bytes seemingly arbitrarily.
2. When configuring USBPD default SNK PDOs, you have to provide the PDO as a 32-bit word. Are there any tools or resources to assist constructing this word? The example changes the initial value of SNK PDO 1 from 0x26019096 to 0x02019096, but it isn't clear what either of these mean.
3. When enabling the debug trace, the example employs an LPUART. However, I cannot use the LPUART on the STM32G431KB because those pins are reserved for the ST-Link USART2 interface. I can re-assign the USART2 pins to other GPIO pins, but I'm afraid I will lose ST-Link functionality by doing that. Is that true? And the LPUART cannot be reassigned to any other GPIO pins.
   1. Alternatively, can I just use the regular USART1 interface for the debug trace? Specifically, will that have any negative impact on the functionality of STM32CubeMon-UCPD?
4. In the GUI_INTERFACE configuration, the HWBoardVersionName looks like a string I can define however I choose. But for PDTypeName, the example uses the value MB1360. Is this value important? What does it mean?

Thanks a bunch!

[Nicolas P.]

Again, all the details around the parameters are currently being written in an application note.

About :

1- Correct. This is arbitrarily set, not trying to optimize anything. This is not the goal here.

We could also get rid of FreeRTOS but this is not yet possible with CubeMx.

2- About the PDOs. It is planned to be able to edit them directly in CubeMX.

Even if some values are entered here, they are not used by the very basic application after. It is only a way to indicate to the user that he will have to complete them later.

0x02019096 means 5000mV/ 1500mA, dual role data, without Fast Role swap, see table 6-14 in document Universal Serial Bus Power Delivery Specification, Revision 3.0, Version 2.0, August 28 2019 for more information

3- As you wrote : yes, you can use USART1. STM32CubeMon-UCPD can use any UART.

4- For the HWBoardVersionName and the PDTypeName can be what you want. MB1360 has been set because it is the board reference of the NUCLEO-G071RB