STM32F072RB and X-CUBE-USB-PD problem.

[Red]

The usb type c pd example code does not seem to work although it compiles properly using SW4STM32. I tried the provided binary file (PNUCLEO-USB001-DEMO1.bin) and it works just fine. I am using nucleo-f072rb and MB1257 expansion board.

PNUCLEO_USB001-DEMO1.bin result

it identifies the source(usb pd capable psu). The yellow waveform is VBus others are cc

successful transaction from 5V - 9V

Consumer(Consumer_CLI_RTOS) example code result

here, it looks like it is trying to establish connection to the source but couldn't.

here is the waveform.

What could be the problem here?

[Yohann M.]

Dear Red,

It is quite difficult to understand your issue without USB-PD log.

For your information, we have a way to trace messages exchanged between our solution and the port partner thanks to trace mechanism.

Please have a look to the following thread: https://community.st.com/s/question/0D50X0000BdfSu2SQE/how-to-use-debug-trace-trace-

I advice you to switch to 'Consumer_RTOS' application. You could enable in this project the compilation switch _TRACE.

Then in using  Cubemonitor-UCPD, you will be able to check what happens exactly.

The binary log (.cpd file) can be retrieved locally in your hard disk under:

C:\Users\<login>\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition

You could attach directly this file for analysis.

Regards

Yohann

[Red]

Here is the USB-PD log.

[Yohann M. · Accepted solution]

Quick analysis:

• CC attached
• VBUS set by provider, sink goes into PE_SNK_WAIT_FOR_CAPABILITIES state
• No src capa received by sink after 500ms, stack sends a HARD_RESET to provider
• Wait for VSafe0V and then VSafe5V but VBUS is not more available => DETACHED !!!

(etc...)

Problem is linked to the fact than SRC_CAPA is not sent by the provider or not seen by the consumer !

Could you please check with this attached binary if it is better or not? If no, please attach the log.

Thanks

[Red]

The binary works. Is this binary compiled from the same project (Consumer_CLI_RTOS)? or a different one? Is it possible to send the project file here? I've found a project from github named X-CUBE-USB-PD-master with binaries provided from each example codes. The binaries worked but when i compile the example code using SW4STM32 and flash it to the board, it wouldn't work.

Thanks.

[Red]

Everything is working now. Thanks for your fast response !

[Nicolas P.]

P-NUCLEO-USB001 is now obsolete. Have you looked at the new STM32 (STM32G0, STM32G4, STM32L5 ...) that embeds the USB power delivery PHY ?

Look also for available HW ressources.

[Yohann M.]

Hello

For your information, we pushed under github an update of the XCUBE-USB-PD package:

* https://github.com/STMicroelectronics/x-cube-usb-pd

Regards,

Yohann

[PRENE.1]

Hi,

I am also using the STM32F072RB-Nucleo with the MB1257 version C expansion board with the analog front-end. I chose the DUAL_PORT_RTOS project among the different applications available in the archive. I have two different behaviors of the program depending on the toolchain used for the compilation:

 -With IAR / EWARM: When I plug a USB-C charger, the power delivery negotiation goes well and leads to the establishment of a contract.

 -With SW4STM32 (arm-none-eabi): When I connect a usb-c charger, the power delivery negotiation does not happen correctly, the nucleo returns a hard reset after the sending of PDO by the charger. When debugging, I notice that the nucleo misses the beginning of the message sent by the charger and considers it as a bad packet (USBPD_PHY_RX_STATUS_ERROR_UNSUPPORTED_SOP) I tried with several chargers and other applications available in the X-CUBE-USB-PD folder, the issue is still present.

Do you have a solution to use SW4STM32 ?

The design we did is based on the analog front-end of the nucleo-usb001. We would like to switch our toolchain from IAR to arm-none-eabi.

Thanks,

[Yohann M.]

Dear @PRENE.1​ 

We reproduced this issue with CubeIDE (GCC).

This is a real time issue. With GCC, RX process is started too late. We lost the 1st bits of GoodCRC message.

I suspect a problem with memset function called under interruption.

I suggest to comment it in the following function:

void RX_Init_Hvar(uint8_t PortNum)
{
  /* Decoding variables */
  FiveBitCodingVar_TypeDef *hvar = &(Ports[PortNum].decfields);
 
  /* Set the state of the port */
  Ports[PortNum].State =     HAL_USBPD_PORT_STATE_BUSY_RX;
  /* Init the decoding variables */
 
  hvar->preamble =         0;
  hvar->k =                0;
  hvar->j =                0;
  hvar->curr_indx =        0;
  hvar->prev_bit =         0;
  hvar->exed_flag =        0;
  hvar->temp_data =        0;
 
  /* reset the Rx Raw data buffer (in diff edge BMC coded) */
  //memset(Ports[PortNum].pRxBuffPtr, 0, PHY_MAX_RAW_SIZE);
 

Regards,

Yohann