cancel
Showing results for 
Search instead for 
Did you mean: 

How should the USBPD stack be informed about a error from the protection IC?

ChristophR
Associate III

Hi,

We use a STM32G071 with the USBPD library together with a USB-C protection IC to implement a DRP device. 

How should I handle a fault signalled by the protection IC? 

- How should I inform the USB-C PD stack about this event? 

- Is it sufficient to request a hard reset (USBPD_PE_Request_HardReset(0);)?

I'm using:

- FW pack STM32Cube_FW_G0_V1.5.1

- USBPD core library V4.0.0

- USBPD device library V3.3.1

Thanks!

BR, Christoph

1 ACCEPTED SOLUTION

Accepted Solutions
Nicolas P.
ST Employee

Hello @Christoph Rüdisser​ 

Can we close this thread and follow the disable stack topic in this one ?

(to avoid loosing ourselves in multiple threads)

Thank you.

View solution in original post

6 REPLIES 6
Nicolas P.
ST Employee

Hello @Christoph Rüdisser​ 

Can you tell a bit more what protection IC you are using ?

Because if it is the TCPP0x family, when an issue (OVP, OCT, OTP) is detected, the TCPP will open the CC lines and the VBUS MOSfet, and raise error through the FLT line (on TCPP01) or alert (on TCPP02/3).

Have a look at : BSP example on github

On TCPP02/3 you can then read the error source, reading the I2C registers.

On stack side, as the CC line opens, we will get a detach.

ChristophR
Associate III

Hi @Nicolas P​ 

We use the TPD8S300A from TI. It's just for protection of the CC1, CC2, DP & DM signals against ESD, overvoltage and short circuit to VBUS, but doesn't monitor VBUS (VBUS is not connected to this protection IC at all). It has a fault output, which indicates if a error has happened.

I thought that it might make sense to inform the USB PD stack about errors signaled by this protection IC, since it also protects the CC signals. In case of overvoltage on the CC signals, it opens its OVP FETs which means, that the CC signals are disconnected from the UCPD peripheral of the STM32G071.

OK, I see, if the CC signals are disconnected, the USB PD stack recognizes a detach. Does that mean, that it's not necessary to inform the stack about protection faults in my case?

Best regards,

Christoph

The stack doesn't need that, but your application could need it. Depending on the failure case.

Think of water in the connector... Fault is raised, CC lines and I hope VBUS are disconnected, then contract is stopped, but then again if the cable is still attached, you may have a start of a new contract and so on...

So perhaps some application would like to know that there is a faulty connector or cable.

In the ST protection IC (TCPP03) you get warned upon failure, and then you can read through an I2C access in the TCPP, what kind of failure happened (Over voltage, over temperature, over current, on VBUS, or VCONN) and then adapt your application.

0693W00000Nsid7QAB.pngIt could be like after 2 errors in 1mn, you decide to go in a safety mode for example.

ChristophR
Associate III

Hi @Nicolas P​ 

Thanks for the quick response.

I think you are right, our device should enter some sort of safety mode. The datasheet of our protection IC recommends to force a detach which also disconnects VBUS.

I think the best way would be to enter the ErrorRecovery state (4.5.2.2.2 of the USB-C Spec R2.0, in this state VBUS is disconnected and the terminations from the CC signals are removed) and stay there as long as the protection fault is active. How could I achieve that? I couldn't find a suitable function in the high-level API.

As an alternative, we could also enter the Disabled state (4.5.2.2.1), but I think this state is not implemented in your USBPD stack.

Now this question is also related to this question.

Thanks,

Christoph

ChristophR
Associate III

Hi @Nicolas P​ 

could you please help me with the questions above?

Thanks,

Christoph

Nicolas P.
ST Employee

Hello @Christoph Rüdisser​ 

Can we close this thread and follow the disable stack topic in this one ?

(to avoid loosing ourselves in multiple threads)

Thank you.