STM32G0 USB PD periphery doesn't send data after extracting code from CubeIDE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-04 2:59 PM
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:
- Source advertises SRC_CAPABILITIES
- Sink requests PDO
- No answer, sink repeats request 3 more times
- Sink requests PE_STATE_SEND_SOFT_RESET
- Sometimes, source answers, usually not
- After 4 attempts ad soft reset, sink requests hard reset.
- 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?
- Labels:
-
USB Type-C and Power Delivery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-12 6:59 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-22 8:32 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-01 8:51 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-01 8:51 AM
Maybe it should be mentioned somewhere. The STM32G0B1VET6 has 4 big timers, but if you want to use USB-PD, it only has 3.
