cancel
Showing results for 
Search instead for 
Did you mean: 

Overcurrent Fault Issue with STM32G0 + TCPP02-M18 PD Implementation

siddhipandare
Associate II

Our team is using the STM32G0 with the USBPD stack and the TCPP02-M18 as the protection circuit. Please find the attached schematic for reference.

We are configuring the PD contract with a maximum of 15V, 3A. When connecting an HP G11 laptop to the USB-C port, the contract is successfully negotiated, but we observe repeated hard resets. Upon investigation, the resets are linked to the TCPP nFAULT signal going low, indicating an overcurrent fault.

When we short the sense resistor (R10) in the schematic, the fault does not occur. We also tried adding a 0.1 µF capacitor across the sense resistor, but the fault still occurs.

When we limit the PD contract in software to 15V, 2.9A, the faults no longer appear. We are using Nexperia GANB4R8-040CBAZ MOSFETs, which have a drain-to-gate capacitance greater than 20 pF, so an additional capacitor should not be necessary.

We also tried reducing the sense resistor R10 to 7m Ohms, but the same overcurrent fault still occurs. Please see the attached scope captures for reference. The captures show the nFLAG signal (yellow) and IANA voltage (purple). The IANA scaling is 7 mV/A × 39 (gain) = 273 mV/A, meaning each 200 mV grid corresponds to approximately 733 mA.

From the waveforms, the trip current (IANA voltage at the falling edge of nFLAG) varies significantly.

In Scope Capture 1, Vtrip= 0.95V, corresponding to 2.89 A.

In Scope Capture 2, Vtrip = 0.54 V, corresponding to 1.98 A.

According to the datasheet, the internal trip threshold is around 1.7–1.8 V, yet we are observing trips as low as 0.54 V, as evidenced by the scope traces.

Could you please advise what might be causing this variability in the trip point? Any guidance or suggestions on how we can further debug or tune this behavior would be greatly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
MROUV.1
ST Employee

Hello Siddhipandare,

 

Thanks for sharing your case.

To better understand, some additional info would be useful to deepen the analysis.

Same screenshots with a larger time scale (100µs/div or 1ms/div) to be able to see the current shape

  • Add (if possible) current proble on VBUS (to perform a direct current readout)
  • Add VBUS voltage sense

 

Could you perform register n°2 readout after the fault ? To confirm OCP fault (see table below).

MROUV1_0-1760021416766.png

 

Best regards,

Mathieu

View solution in original post

4 REPLIES 4
mbrossett
Associate III

The source pin of the TCPP02 is connected to the drain of the back-to-back mosfets which might be causing the fault. Could you try using mosfets with the source connection exposed like the STL40DN3LLH5D used in the reference design for the TCPP02?

MROUV.1
ST Employee

Hello Siddhipandare,

 

Thanks for sharing your case.

To better understand, some additional info would be useful to deepen the analysis.

Same screenshots with a larger time scale (100µs/div or 1ms/div) to be able to see the current shape

  • Add (if possible) current proble on VBUS (to perform a direct current readout)
  • Add VBUS voltage sense

 

Could you perform register n°2 readout after the fault ? To confirm OCP fault (see table below).

MROUV1_0-1760021416766.png

 

Best regards,

Mathieu

siddhipandare
Associate II

Hi Mathieu thank you for your reply, 

The current measurements on the Vbus showed that we do infact have around 5A that is tripping the TCPP OCP. The register reads 0xA2 after the Flagn.

In the trace attached, the yellow trace is the current sense resistor where the scope 'gnd' is at VBUS (~15V). The green trace is the Flagn pin of the TCPP02-M18 part and as it is typically at 3V  (-12V with respect to the scope 'gnd' at 15V) 

I have a follow up question: Why is this not reflected on the IANA, is the output of the TCPP part filtered? I think it would help debugging if you mention this in the datasheet. 

MROUV.1
ST Employee

Hi Siddhipandare,

 

Your comment is fair.

The IANA output filter has been extracted, its bandwidth is 18kHz typ.

 

Best regards,

Mathieu