STM 32 Power Delivery software expansion ; TCPM-TCPC architecture core library.

[FaikN]

Hi,

I am working on the power delivery expansion pack with cpm tcp architecture by using STM32F072 and PTN5110 as tcpc. Right now i am configuring one of the ports for sink and connect to PD2 capable source device. I am able to get 5v default voltage. however for the later stages of power negotiation i have been stuck at where the Sink generates the last GoodCRC message. this has been always get stuck within the PE_State Machine which is not accessible. Is there a way to get an access to this core function to figure out why the negotiation get stuck? In attach you can see the log file of the traces i m getting. Please feel free to comment on the negotiation, how it should be, if there is something else wrong and how to fix it!

Thanks,

Faik

0	EVENT	381188	1	EVENT_ATTACHED
1	DEBUG	381188	1	VBUS:2393, CC:2
2	SRC	381288	1	SRC_CAPABILITIES    DATA:2C91012E  / 5V - 3A	SOP	 PD2	    H:0x1161    
3	SNK	381289	1	GOODCRC	SOP		    H:0x0081    
4	SNK	381300	1	REQUEST DATA: 96580211 / ObjectPosition:1 / GiveBack:0 / CapabilityMismatch:0 / USBCommunicationCapable:0 / NoUSBSuspend:1 / UnchunkedExtendedMessagesSupported:0	SOP	 PD2	    H:0x1042    
5	SRC	381301	1	GOODCRC	SOP		    H:0x0161    
6	SRC	381305	1	ACCEPT	SOP	 PD2	    H:0x0363    
7	SNK	381305	1	GOODCRC	SOP		    H:0x0281    
8	SRC	381334	1	PS_RDY	SOP	 PD2	    H:0x0566    
9	SRC	381336	1	PS_RDY	SOP	 PD2	    H:0x0566    
10	SRC	381337	1	PS_RDY	SOP	 PD2	    H:0x0566    
11	SRC	381339	1	PS_RDY	SOP	 PD2	    H:0x0566    
12	SRC	381341	1	SOFT_RESET	SOP	 PD2	    H:0x016D    
13	SRC	381342	1	SOFT_RESET	SOP	 PD2	    H:0x016D    
14	SRC	381344	1	SOFT_RESET	SOP	 PD2	    H:0x016D    
15	SRC	381345	1	SOFT_RESET	SOP	 PD2	    H:0x016D    
16	DEBUG	381370	1	VBUS:755: CC:2
17	EVENT	381370	1	EVENT_DETACHED
18	EVENT	382208	1	EVENT_ATTACHED
19	DEBUG	382208	1	VBUS:4953, CC:2
20	SRC	382308	1	SRC_CAPABILITIES    DATA:2C91012E  / 5V - 3A	SOP	 PD2	    H:0x1161    

[Yohann M.]

Dear Faik,

Could you confirm that the trace has been done on TCPM side? A message received by TCPM means that the goodCRC has been automatically sent by the TCPC. Then if I see the PS_RDY, it means that the GoodCRC has been sent. It looks like that the trace has been done on port partner side (with a ST solution?)

Stuck on this solution may be a alert issue (pending alert not correctly clear?) Can you add debug traces around alerts?

Regards,

Yohann

[Yohann M.]

Did you use the STM32G0-Discovery board?

[FaikN]

Dear Yohann,

The traces are done from the port partner side, which I used a Mac charger. Indeed STM32G0 Discovery was used in SPy mode to track the traces. So after PS_RDY, the Sink fails to send the last GoodCRC and it seems like it is stuck within the PRL_SendMessage function within the core library. Alert register seems cleared. I am double checking it right now tho. Can it be because of buffer overflow or clash due to incoming repetitive ps_rdy messages? if yes, how can it be solved?

Thanks

[Yohann M. · Accepted solution]

Hello,

To analyze such issues, best way is to get the traces on device side. Regarding the logs, it means that the PS_RDY did not been received by TCPC because we have some retransmissions. Debug trace can be easily added in your code to check the behaviour of the system (refer to paragraph "3.6.4 TRACE system" from UM2552).

Yohann