cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F072RB and X-CUBE-USB-PD problem.

Red
Associate II

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

0690X00000BvsUmQAJ.png0690X00000BvsV1QAJ.png

0690X00000BvsVBQAZ.png

successful transaction from 5V - 9V

0690X00000BvsVLQAZ.png

Consumer(Consumer_CLI_RTOS) example code result

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

0690X00000BvsVaQAJ.png

here is the waveform.

0690X00000BvsVkQAJ.png

What could be the problem here?

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

9 REPLIES 9
Yohann M.
ST Employee

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

Here is the USB-PD log.

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
Associate II

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
Associate II

Everything is working now. Thanks for your fast response !

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.

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
Associate II

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,

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