Skip to main content
Visitor II
January 11, 2020
Solved

STM32F072RB and X-CUBE-USB-PD problem.

  • January 11, 2020
  • 3 replies
  • 2823 views

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?

    This topic has been closed for replies.
    Best answer by Yohann M.

    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

    3 replies

    ST Employee
    January 13, 2020

    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

    RedAuthor
    Visitor II
    January 13, 2020

    Here is the USB-PD log.

    Yohann M.Answer
    ST Employee
    January 13, 2020

    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

    RedAuthor
    Visitor II
    January 14, 2020

    Everything is working now. Thanks for your fast response !

    ST Employee
    January 15, 2020

    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.

    Visitor II
    July 16, 2020

    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,

    ST Employee
    July 21, 2020

    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