TPS23751: TPS23751 Surge issue during option 2 ORing

Hello, 

Thanks for the question. My first guess is that somehow the surge current is finding its way to the front end of the design. If the PD sees a detection or current voltage on VDD_VSS, it could send the PD into the detection or class state. This will trigger the internal state-machine, which will shut off the converter. Is there any path for the surge current to get to the input during your testing?

You could test this theory by monitoring the VDD_VSS voltage. I would suggest a differential probe, or using two probes (one on VDD, one on VSS, both reference RTN and subtracting the two traces in the oscilloscope) to see what the VDD_VSS voltage is during the test. 

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments 

Hello Michael,

Thank you for your answer!
In the meantime things got a bit clearer.
I only see the system crashing with the CDN connected on the ethernet line.
Means, we supply our device via the 24V DC input. In addition, network (without PoE) is provided via the CDN for HV-decoupling. Unfortunately, this CDN adds a significant capacitance to PE

The following screenshot shows the Voltage between VDD and VSS of the TPS23751.
(1) with no ethernet cable connected
(2) with 10m SFTP cable connected
(3) with the CDN connected via 0,3m UTP cable



So, for the moment I am not sure if our CDN is allowed to be used in this setup but on the other hand, capacitances from a PoE Line to PE can occur. I can not estimate if this is a real life scenario as i can not find any statement in the IEEE how big the parasitic capacitance on a PoE Line to PE is allowed to be.

As not every surge leads the PD manager to latch in off state, I assume that the surge is somehow interpreted as PSE negotiation and erroneously triggers the PD PoE Statemachine which resides in UVLO after finishing the surge.

The questions is
- is it possible to avoid the TPS getting false triggered
- what is the allowed amount of capacitance on the PoE lines ref. to PE

Hey Fabian, 

Thanks for all the data and background information. 

1. Would it be possible to put a blocking diode on VDD --- there is one for the adapter, but can we add one for VDD_VSS? Does that make sense? Put it before the input inductor. 

Otherwise I am thinking if there was a way to help filter the noise, like a common mode choke?

2. To clarify, you mean between like PoE ground and the output ground, what is the max common mode capacitance?

Typically 10uF is the max, but interestingly what i found is reducing the common mode cap reduces the ability the surge current can do this. Just some personal experimenting with surge and our EVM's. 

Let me know if my understanding is correct here. 

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments 

Hello Michael,

thank you for your feedback!
I discovered yesterday, that there is need of a CDN to trigger this event. Simply connecting a shielded Twisted Pair ethernet cable of 25 ... 50m is enough. This seems to already add enough capacitance from the PoE lines to PE.

1) Adding a blocking diode on VDD would not work i guess. I cant think of an position for the diode where on the one hand PoE and DC input are still possible and on the other Hand the surge is kept away from the VDD-VSS input.

2) I measured some cable capacitances of common ethernet cables (S/FTP and F/UTP) as both offer a shield, i measured the capacitance from shield to the wires which is approx 40nF / 100m (measured all eight wires in parallel). We see failing units already with 25m ethernet cable. How should i place a filter on VDD as this port also does the PoE negotiation? Can you propose a solution either for the diode or the filter?

3) i was able to reproduce this with the evalboard PMP20220A.
- I connected the secondary GND and Ethernet shield (BS PLANE) to PE.
- I added the TVS diode (SMAJ58A) parallel to the Hotswap-FET (see slua736) - but anyhow it makes no difference either this diode is applied other not
- I've changed R23 that the module can be powered with 24V (APD goes high at 19,5V)
- I provided 24V to power the eval board
- I connected 50m of F/UTP cable to the PoE port (no device on the other end of the cable). Latches occur down to 25m. Without a cable connected, no latch occurred.
- I applied a surge of 500V to ether DC+ or DC- referred to PE with both polarities.

-> Converter latches in UVLO with the first surge pulse.

Any further ideas how to solve this issue?
What do you think about this scenario at all?

Hey Fabian, 

1. When I look at the provided scope shot, to me trace #3 shows a voltage on VDD_VSS which makes me conclude the surge is affecting this input. How do you understand that image?

For the diode, would the below image not work? This would block current flowing this way, and the TVS on the VSS_RTN would block current flowing the other way. Might require a layout change. 

2. Use an EMI choke like 744272251. These filters target common mode current, which is the typical path for surge events. For PMP20220 it would go in series with L3 and L4. 

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments 

Hello Michael,

Thank you for your feedback!

Michael Pahl said:

1. When I look at the provided scope shot, to me trace #3 shows a voltage on VDD_VSS which makes me conclude the surge is affecting this input. How do you understand that image?

Yes, i would also say so. I am pretty sure, that the effect is triggered due to a voltage between VSS and VDD. The above screenshot is made with the CDN connected. With 50m cable connected, the is only a spike left but this seems to be enough.

Michael Pahl said:

For the diode, would the below image not work? This would block current flowing this way, and the TVS on the VSS_RTN would block current flowing the other way. Might require a layout change. 

I will try that on Monday but i can't see that the diode should have an effect on the problem, as it is in the same direction like the diodes in the rectifier bridges. I will see on Monday.

Michael Pahl said:

2. Use an EMI choke like 744272251. These filters target common mode current, which is the typical path for surge events. For PMP20220 it would go in series with L3 and L4. 

Yes, a common mode filter will likely relax the situation. This is not the preferred way as we are right about to start the (till now) last Samplerun before mass production. But I more and more think that we have to accept it like it is and do a HW modification. Anyhow i will also try this on Monday and see if it helps.

I will keep you updated on Monday.

Hey Fabian, 

Thanks for all the updates. Let me know how Monday goes and we'll take it from there. 

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments 

Hello Michael,

sorry for the delay but I had some trouble with my TI login.

Unfortunately both proposals (the diode and the CMC choke) did not improve the situation.

Do you think of any further solutions?

Hey Fabian, 

The link provided here is all of our guidance on surge protection for the PD: https://www.ti.com/lit/an/slua736/slua736.pdf?ts=1648048799201&ref_url=https%253A%252F%252Fwww.google.com%252F 

Figure 5 and Table 4 give a proposed schematic and part recommendations up to 4kV surge protection. Can you try implementing these components?

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments 

Michael Pahl said:

Figure 5 and Table 4 give a proposed schematic and part recommendations up to 4kV surge protection. Can you try implementing these components?

In our Board...
- SPD1 is applied with a SMCJ58A TVS Diode
- SPD2...5 is applied with a Sidactor array (SEP0640Q38CB + P45CM) providing  a 500V protection against PE (i did not draw that in my above drawing, as it makes no difference if this components are populated or not.
- "clamp" on the data lines are SP2555NUTG
-> compared to figure 5 we do not have any further options.

The voltage spike that occurs on VDD/VSS/RTN is limited by the TVS to approx 70V. that is enough to misstrigger the PoE UVLO.

To be clear, if you perform a surge with a setup according to the standard the module will pass - so no certification issue will occur. But, if you connect >25m shielded ethernetcable (what is a valid usecase) the PD manager will fail so there will be problems in the field.

I more and more come to the conclusion, that - unfortunately - the PD manager is not able to be powered with 24V in option 2 Oring in a stable and reliable way.

Yea i guess this is a difficult case because the surge protection is working to protect the IC, and the IC is behaving as it should. Surge is a system level phenomenon that depends on the grounding scheme, adapter scheme, the protection, the common mode capacitance and where the surge is applied. 

However, we have had many of our PD's implemented with 24V adapters in the past. The IC will require a reboot if a surge event happens, but that is not the same as  IC damage. If the IC get's stuck in this state I think we can find a different work around. If the APD voltage is raised above its threshold, the T2P pin is forced high. If the 24V adapter is connected then this pin should be high. Or as you said in your original post, VCC and VB are high. We could use these signals to indicate that power is present, and if there is no output power after xx ms then disconnect and reconnect the power supply. I think there are more work arounds here than not using the 24V adapter. 

You could also put a buck-boost to boost the adapter to 48V. These two potential solutions could correct the behavior. 

If this post answers your question, please indicate so by marking this thread as resolved. Thank you.

Regards, 

Michael P.

Applications Engineer

Texas Instruments