TCPP03-M20 with STM32G0B1CBT6 failed role switch (Data/Power)

[PaulMinh]

Hello ST Expert,

On our custom board - USB PD, it has 

1. HW: TCPP03-M20 with STM32G0B1CBT6

2. SW: X-CUBE-TCPP 4.2.0 ( USBPD Application 4.2.0 - Dual_Role)

3. SW: Board Part tcpp0203 1.2.3

4. Tools: STM32CubeMX (6.15) & STM32CubeIDE 1.19.0 & STM32CubeMonitor-UCPD-1.4

  

May you guide how to fix below issue?

Issue:

a) When pluging a usb device (smart phone USB type-c 3.1) in /connect to our custom board, on the "STM32CubeMonitor-UCPD-1.4",  we could see CC1/CC2 is detected, and it (SRC) starts charging the smart phone (SNK). However, only SRC, CCI/2 info is shown on the GUI; data role (UFP/DFP) info is not shown, etc.

b) When we try to do Power role swtich, or try to get SRC's capacity by sending message to connected port on  "STM32CubeMonitor-UCPD-1.4", it always shows the message is rejected. (* We already turned on support options on CubeMX - Stack Port 0 Parameters). All messages are rejected.

c) Similiar to B), even we enable support all options on CubeMX for the firmware code, some fatures are still shown [disable] on "STM32CubeMonitor-UCPD-1.4". On ""STM32CubeMonitor-UCPD-1.4" we try to enable mannually and SAVE to Target, then the board is restart automatically (unable to enable).

 

- This issue may be caused by using tool versions? Any recommedation of tools version for STM32G0B1CBT6?

- May you guide how to debug this issue both firmware/hw? Thanks.

Note, we used to verify TCPP03-M20 with NUCLEO STM32G071RB, it works fine.

 

[FBL]

Hi @PaulMinh 

Would you attach a trace .cpd to check who is rejecting the power role swap! 

[PaulMinh]

Hello, 

we don't have .cpd now but CubeMonitor logs as the attached files.

[FBL]

Hi @PaulMinh 

Did you refer to examples provided in cube FW to narrow down the issue?  It seems the source has send his src capabilities. But we don't have visibility from the sink, if is getting the source capabilities 

We need to debug the issue further in sink mode! Actually, this could be linked to hardware integration as well if you don't reproduce on reference board.

[PaulMinh]

Hello FBL, 

We followed this Dual-Role instruction (https://www.youtube.com/watch?v=mJ4VX_2B6wE&t=839s) and we configured our PD device as Source by default. (We will try to configure as Sink only.)

BTW, we try to modify/increase more  delay at the existing HAL_Delay() in custom_board_usbpd_pwr.c, usbpd_phy_hw_if.c, and usb_cad_hw_if.c. "Sometime" we could do Power role switch successfully but not always. Probably it may be related with our custom HW. 

E.g in usbpd_cad_hw_if.c

In 

static uint32_t ManageStateDetached_SNK(uint8_t PortNum)

/* Temporary patch for test TD.PD 4.5.2 + rework for Patch TP.PD.C.E5 */

HAL_Delay(30); //changed 1 -> 30

In

static uint32_t ManageStateDetached_SRC(uint8_t PortNum)

/* let time to internal state machine update */

HAL_Delay(60); //changed 1 -> 60

Etc.

So, we concern that some extra need to be added for our custom board.

May you comment about this? Also please suggest any delays we should try for the debugging?

 

Note, On CubMX tool, we must change CAD source toggle time to 100ms (and CAD sink toggle time to 100ms), otherwise we could not detect our custom board on STMCubeMonotor-UCPD tool.   

 

[FBL]

Hi @PaulMinh 

Any updates regarding this thread?

[FBL]

Hi @PaulMinh 

a) About Data role (UFP/DFP) info not shown on STM32CubeMonitor-UCPD GUI, only CC1/CC2 and power role (SRC) detected. This issue is more likely linked to GUI interface 

b) and c)  About Power role swap and message rejected. 

You need to narrow down the issue. Since, you have custom board, MX generated code, software configuration and new to use PD stack. I suggest to start with example firmware provided, use DRP shield, for managing dual role Power and Data.

About toggle logic, in CAD_StateMachine_DRP, ManageStateDetached_DRP() is implemented in middleware you should not change it. When the elapsed time since last toggle exceeds CAD_SRCToggleTime and CAD_SNKToggleTime values, the role switches and the corresponding pull-up (Rp) or pull-down (Rd) is asserted on CC lines.