cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0 USB PD periphery doesn't send data after extracting code from CubeIDE

Tadeas_Pilar
Associate II

Hello,
I am developing a USB PD sink product using STM32G0B1VET6 MCU.
I have a project in CubeIDE, created proof-of-concept code following ST tutorial Getting started with USB-Power Delivery Sink and everything works as expected.

I then tried to transfer all of the code into my project (outside of CubeIDE) and it's not working. See the attached trace

The events go as follows:

  1. Source advertises SRC_CAPABILITIES
  2. Sink requests PDO
  3. No answer, sink repeats request 3 more times
  4. Sink requests PE_STATE_SEND_SOFT_RESET
  5. Sometimes, source answers, usually not
  6. After 4 attempts ad soft reset, sink requests hard reset.
  7. Repeat indefinitely

I suspect the sink isn't actually sending any data out.
I tried sniffing the PD bus, and indeed, there is no communication going from sink to source. Maybe something went wrong, when moving the code to different project. Maybe I forgot something.
How do I debug this?

4 REPLIES 4
Tadeas_Pilar
Associate II

Beware different RTOS, CMSIS, HAL and USB PD lib revisions. They are not compatible. There are now compile-time checks to enforce this and no external documentation either.
If you want your USB PD to work, make sure you are picking all of the above mentioned components from the same Cube version.

FBL
ST Employee

Hello @Tadeas_Pilar 

Do you mean after transferring from CubeIDE to another toolchain, you can no longer run your project and you are suspecting the sink no longer able to send data? Would you consider checking the process to port your project?

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


I'm out of offce with limited access to my emails.
Happy New Year!
Tadeas_Pilar
Associate II

UPDATE: I tried to save a timer and the hack to to that didn't work.

Long story: USB PD consumes one of the big timers. This is caused by lasy implementation of PD response timing, which needs to be very precise.
I don't have a big timer to spare, so I rewrote usbpd_timersserver.c to only use one small timer. There was an error in overflow handling. This error, for some reason, didn't manifest itself when I tested in CubeIDE.
After moving to my project, timing didn't work and PD stack never responded to any messages.
Debugging this is of course impossible, since the PD stack is closed-source and I can't see what it's stuck on.

I temporarily solved this issue by going back to ST implementation of usbpd_timersserver.c and giving up some of the required functionality of my project.
I will eventually have to fix the error and go back to not using a big timer.

Does ST accept contributions to CubeMX? It might be useful to other people as well.

Tadeas_Pilar
Associate II

Maybe it should be mentioned somewhere. The STM32G0B1VET6 has 4 big timers, but if you want to use USB-PD, it only has 3.