2019-10-24 09:24 PM
Act as the DFP. I request the PE to send SOP identify request to the UFP after PE received the data it didn't fire the callback function. (I set the breakpoint at fusb305_tcpc_get_message and i see the data received from the DFP is correct.)
But
I'm not sure if i set the configuration correct or there is any problem in the usb pd library.
Thanks.
John
Solved! Go to Solution.
2019-11-12 05:33 AM
Dear @John886
Please find all the libs generated with VDM patch.
For the 2nd question, I would prefer keeping the other thread already opened by you :
Regards,
Yohann
Note: For your information, we posted an update of X-CUBE-USBPD under github (V3.1.0):
2019-10-28 02:56 AM
Hello,
Project 'EVAL_FUSB307_DRP' delivered with 'STM32CubeExpansion_USBPD_F0_V2.1.0' does not have the VDM option enabled.
User Manual UM2552 explains the different libs delivered with FW package:
It means that you have to:
(you can refer to Consumer_VDM_RTOS application which enables VDM by default)
To help you, I updated the project to enable VDM and import usbpd_vdm_user files which allows to implement different VDM callbacks.
For your information, I also enabled _TRACE in this project to allow to evacuate traces over USART pins (PA0 & PA1) connected in my side to VCP used in ST-Link.
Further details described in another post:
"in the projects we deliver, the internal trace is enabled. It is possible to see if you have communication between 2 boards.
Trace is done through USART pins connected to ST link. You should use Cubemonitor-UCPD and use the functionality described in the following image:
"
Regards,
Yohann
2019-10-30 08:12 PM
Hi Yohann
Thanks for your help.
I followed your step but the problem is the same when mcu received the VDM message from the partner port, UPF, it didn't call the callback function USBPD_VDM_InformIdentity.
It is the screenshot of the STM32CudeMonirot USB Type-C PD shows PE actually received the message.
BR
John.
2019-10-31 03:54 AM
Hi John
I'm a colleague of Yohann working on type C. I think your issue could be link with the request mechanisme implemented within our USB-PD stack.
Our USB-PD stack allows to send request but only one at a time. Therefore, if a request is ongoing and you try to post a second request, the stack will reply USBPD_BUSY. This means that the request has not been taken into account by the stack because there is already a pending request. So you shall wait the request completion before to send a new one.
The function USBPD_PE_SVDM_RequestIdentity could repply USBPD_ERROR if there is mismatch within the conditions to send this kind of request
The conditions are the following:
the feature PE_AttemptsDiscovSOP has been enabled inside the usbpd_conf.h
there is VDM_Callback
request is SOP or SOP'
no ongoing request (USBPD_BUSY)
there in an explicit contract bewteen the both ports partner or the port is SRC and providing 5V
Please could you check the return of the function USBPD_PE_SVDM_RequestIdentity ?
Another important thing, any discussion with the cable implies that you must power VCONN otherwise the component inside the cable is not powered and can not answer to a message.
BR
Dominique.
2019-10-31 08:25 PM
Hi Dominique
Thanks for your reply.
I enable the VDM, VCONN_SUPPORT, USBPD_TCPM_LIB_PD3_FULL and link the library to USBPDTCPM_PD3_FULL_CM0_wc32.
This is my DPM_Settitng
The below is my debug process.
I use fusb307evb and configure it to
1.Sop_1
When i called the USBPD_PE_SVDM_RequestIdentity(PortNum,SOP'), i got the VDM message replied by the e-marker of the cable.
The figures shows VDM message received by usb305 is consistent with what ez_pd, EZ-PD™ Protocol Analyzer for cypress, read then the PE calls the callback function.
2. SOP
When i called the USBPD_PE_SVDM_RequestIdentity(PortNum,SOP), i got the VDM message replied by the partner port.
The figures shows the VDM message usb305 received is consistent with what ez_pd, EZ-PD™ Protocol Analyzer for cypress, read.
The return value o the USBPD_PE_SVDM_RequestIdentity(PortNum,SOP) is USBPD_TRUE but this time PE didn't call the callback after receiving the VDM message.
I'm not sure if i can retrieve the VDM message from the callback function called by the PE after receiving the correct VDM message replied by partner port after calling USBPD_PE_SVDM_RequestIdentity or i need to call another function to retrieve it.
Thanks.
BR.
John
2019-11-05 12:03 AM
Dear John,
In our stack, we check the content validity of the Discovery identity and we had an issue in this check (fixed in our latest delivery done for our G0 series). I updated the lib used in your environment. Could you please try it and let me know if it works or not? (I tested in my side, it should be OK ;) )
Regards
Yohann
2019-11-06 01:21 AM
Dear Yohann
I used the library you uploaded yesterday, the weird thing happened.
The block in black is the old library that x-cude pd provide and the block in red is the new library you provided.
when i used the new library.
After receiving the hard reset sent by the fusb307evb , mcu hanged on the hard fault
Could you please provide the project that worked well in your side.
Thanks.
BR.
John
2019-11-07 02:35 AM
2019-11-07 11:23 PM
Hi Yohann
Thanks for help.
The project you uploaded worked well.
Another question will the en.x-cube-usb-pd release the new version that fix this issue ?
Thanks,
BR
John
2019-11-08 07:12 AM
Dear @John886 ,
Nice to see that it works now :)
For the release, we need to align the XCUBE-USBPD package for TCPM/TCPC with all the modifications done since the V2.1.0 delivery.
There are no scheduled dates yet but do you have blocking points in your side with this current package?
Regards,
Yohann