Why does EMI shut down topswitch JX?

Posted by: jtiers on 01/02/2014

We have a topswitch JX supply which provides a 12V and 24V isolated output, as well as an 8V and 20V bias supply. It is the housekeeping supply for a motor control operating from 3 phase 208/240VAC

The isolated supply runs the user interface, which communicates with the non-isolated parts via optoisolators, 3 channels of about 1 pF or less capacitance per. Power level is around 15W max, at max loading of the 24V.

The 24V is the controlled output, with a simple Zener voltage detector and opto for isolation. Measured capacitance of the transformer is about 35 pF from isolated part to primary side, and we have a 2.2nF Y cap, output common toDC bus.

Drain clamp is a simple diode and transient suppressor zener.

Circuit works great, has passed all tests except one.

The problem:

We have shutdowns of the Topswitch supply in the EMI test.

We have to pass a test for EMI injection on the isolated side, which is done via a "showering arc" noise source, which is a multi-kilovolt spark gap which has its grounded lead connected to the isolated supply common, so the EMI signal is across a meter or so of wire inductance.

The path is from HV through the spark gap, through a meter of wire to ground, with the injection wire connected at the spark gap end of the grounded meter of wire. The other end of the injection wire goes to "common" on the 24V supply.

It is a source of high frequency random interference noise injected onto the output common of the 24V isolated supply.

What we find is that the showering arc will cause the Topswitch 265 to shut off reasonably reliably. It may go off for a short time, maybe 100mS, or it may go off and refuse to complete a re-start, shutting off immediately, and so "stuttering" on and off.

We have put the V sense terminal to "S", no change. "F" is already to "S" (132 kHz) , X has 16k to "S", and the control terminal has the recommended parts. All are very close to the Topswitch, going to the "blob" of foil we use as a heatsink. That blob is out of the path of the power circuitry of the motor control, but obviously is connected to the negative side of the DC bus.

The bad features of this particular design are

1) the V sense resistors are not connected to the 50uF film cap (bus capacitor) directly. But the problem still exists when V sense is disabled.

2) The feedback line passes close to part of the snubber traces. But, since this causes no problem in normal operation, it may not be part of this issue. Also using a wire to re-route feedback makes no difference. Probably this is due to the low impedance of the feedback node (47uF and 6,8 ohms to ground).

We have not yet been able to track down the cause of this problem.

Is this a known issue of any kind? I looked in the apps data, and found nothing related to it.

Any ideas?

The relevant part of the schematic is attached

Comments

No reply?

Bumping up to top to be visible again...

Hi,

Thanks fr contacting PI.

So basically the noise injected to the power supply make the power supply enter into protection mode in the mean of latch off or auto restart. I am glad to see that you already tried a couple of things to figure out what the cause of the failure. Sometime the noise injection could be very complicated, I am sorry I did not really fully understand the how the noise injected, is this noise test a kind of the IEC standard test? If you candraw some simple diagram, it will be helpful.

The layout could be very critical in terms of eleminate the noise affection, so it will be helpful if you can attache the layout and a clear schematic, the schematic you attached is very hard to read, sorry.

Having said that I would also recommend you to try to remove the Y capacitor, and redo the test. You could also try to connect the Y capaitor directly to the Bus capacitor (DC minus), see if there is a different. Please also remember the V pin is very sensitive to the noise, so if you trid to disable to protection function, make solid short to GND. You could also try to use the transformer with shield technology, this will decrease the noise coupling from the secondary to the primary.

Hope this can be helpful.

Thanks

Y cap was not present, but we provided a place for it. When the problem showed up, we put it in place. No change.

Test is not an IEC test, but an industry test used in various versions by several companies internally. We use it to check general EMI susceptibility. Most circuits, even with microcontrollers, etc, can be reasonably simply made immune to the interference, and when that is done, we find the real world behavior is also immune to most noise. We have another smaller motor control product with a Linkswitch supply (non-isolated buck), which passes the test very well, for instance. No interference.

A Hi-pot type tester is used to provide high voltage AC, since they can tolerate arcing current on their output. An adjustable spark gap is in put series with the high voltage lead of the Hipot tester, and the other side of the gap is connected to the ground lead, about a meter of wire going to the tester chassis(earth). The "output" is from the connection of spark gap to earth lead.

Because it is nearly at ground, there are only voltages of high frequency present. But they are of relatively low impedance, so ordinary bypassing is less effective.

Note that the high voltage is NOT connected to the UUT... the arc is really used to generate relatively broadband EMI. The voltage that appears across 1metre of wire (earthed at one end to tester chassis which is earthed through mains lead) is what is coupled into the unit.

So, we find that we have intermittent problems with the Topswitch shutting off briefly, which causes a shutdown/restart of the motor control also. This is not acceptable to the customer (military subcontractor), who will do immunity testing, including a test that simulates a nearby lightning strike.

The schematic I will have to extract again, I agree it looks fine until you try to view it closer.... sorry. But it is a pretty standard app note circuit.

I have attached a layout, and sketch of test setup.

Note that two things about the layout are known to be not ideal.... 1) The voltage sensor connection point we mentioned, it seems not to be the problem, since "V" was grounded to source common with a very short wire... no change. The nearest bus capacitor (film type 50 uF) is the rectangle just below "R13" at bottom of picture.

2) The feedback trace is rather long, and in the original layout it was put way too close to the drain and snubber. However, we have cut that trace and "red-wired" it in a different position following over the trace carrying common, with no particular difference.

Despite "red-wiring" fixes, we still get shutdowns from the arc test, about 10x per hour at lower voltage arcs, many more if we use somewhat higher arc voltage. Arc voltage affects strength of signal, and also to some degree frequency distribution of the EMI.

What we know:

* PI chip shuts down, output switching stops. We put an LED monitor on it with short wires, and it definitely goes out.

* Shorting the voltage sense pin to "source" made no change.

* there is capacitive coupling through transformer and opto units.

* No interference is noted when the arc tester has is merely "nearby", but as soon as it is directly connected, or closely capacitovely coupled to a wire leading to "common" or 24V supply output, the trouble starts.

* The customer has had some cases of the apparent shutdown, they have signal & ground wires connected to the controller PWB, and use the 24VDC ouput.

* The microcontroller based controller PWB which is powered by the 24v supply, and which has the tester directly connected to common, is not affected by the arc signal (we had to do some work to make it immune).

* The uC is not on the same PWB with the PI chip, there is a short (40mm) ribbon cable between them that carries the 24V and comm wires to the controller. Lossy absorbing ferrites on that cable do very little if anything, we tried that, both LF and higher frequency types.

* The PI chip is directly affected, even though it is not conductively connected to the controller pwb.

* Connection of bypass capacitors from controller ground to earth (chassis) do not help, presumably because the source is low-Z.

* All capacitors in the unit are film or ceramic low-Z types, none are electrolytic (for temperature range and lifetime reasons)

we do not know if the feedback system is being fooled into giving an overvoltage signal. Any wires we attach affect behavior.... they are extra antennas. So we cannot really monitor it without the suspicion that we have changed the behavior. But with so few "inputs" to the chip, we are very suspicious of teh feedback, despite the fact that it is at very low Z....

Thank you

Better schematic copy attached

I should mention....

The transformer is fixed... is an existing unit and does not include a shield winding.

Because of the relatively low volume production rate, this unit is probably not a candidate for a new custom transformer which could be made with a shield.

And the shield would not actually change the capacitive currents, but it would divert them. Diversion might improve the performance, or it might not, depending on where the diversion goes to, and what the susceptibility meachanism really is.

We need to solve this problem, and it seems we may need factory assistance, because there is not much to be done with the chip itself as far as bypassing, or layout.

We eliminated the V pin as a possible problem by grounding it.

The bad feature of feedback was reduced by re-routing the feedback well away from D pin and snubber, no significant change was noted.

This seems to be a different sort of problem that may be associated with some inherent characteristic of the chip.

Thanks a lot for all the detail information and the way that you tried to fix the noise issue.

As what you described, basically the high frequency noise injected from the secondary output to the primary side which has the Topswitch through the transformer and the opto-coupler. And if this noise reach some level of voltage, it may disturb the functionality of the IC. So what I can think the way to solve it is to creat some path for the noise, avoid the noise to go directly to the IC. Here is what I will propose:

1. Please attach the spec of the transformer, I know that you mentioned you can not change the transformer because it has to be reused. But It will be helpful to see the root cause of the problem.

2. You could also just try to build very similar transformer with shield, see if there is any difference.

3. Considering the layout, it is not easy to see clearly as it is only a picture. But I would strongly recommand you to apply the kevin connection for the bias winding ground. The pin 9 of the transformer is the return ground of the bias winding. If you can cut the track and route this pin directly to the negative bus capacitor pin. You can keep the rest of the COMSP net as what it is now. Basically this will help to pass high frequency noise directly to the bus capacitor and avoid it to be coupled into the Top-switch.

Please let me know if you tried these.

Thanks

OK. Thank you

1) Attached.

2) Agreed, but since the transformer is a commercial part (due to low volume for US government program) that is a problem to do. I don't think we can effectively take apart these transformers to insert foil or a winding as a shield, I am pretty good at winding SMPS transformer, but these are small, and almost 100% fill.(also seem to be varnished/glued)

3) Bias winding already has a separate path to the local bulk capacitor, not including any of the PI chip ground.

Also, there is no interference UNLESS the EMI is injected onto the isolated supply ground or signals. So the interference inherent to the product layout is not sufficient to cause any disturbances. Of course, the sum of outside EMI and local disturbances might be sufficient, of course. I am not sure how we can determine that exactly.

Our concern is that we don't have knowledge of what the inherent susceptibility of the PI chip is. Many signals are very low currents, and it would not take much to disturb them. But some cannot be bypassed (V pin) and others are already bypassed very well (control pin, which has 47uF ceramic and 6.8 ohms, plus a 100nF ceramic capacitor).

It is not clear what can be done about the current programming pin, but the trace is so short it seems unlikely to be an issue.

However, as I hope is visible on the layout, all the parts for C, V, and X are quite close to the PI chip, and go direct to the same ground "node" as the "S" pins.

We have bypassed various parts of the circuit in an attempt to divert the currents. This has had very limited success, although we are quite familiar with EMI countermeasures. It appears that the source is a low enough impedance that bypasses need to be so large as to be somewhat impractical. There are leakage current limits also, which mean we cannot use an arbitrary size.

The first problem, I believe is to identify what part of the PI chip is receiving the interference. That will set the possible countermeasures. But any probes we attach will almost certainly change the behavior and the interference so much as to make the test worthless.

So we hoped that the nature of the problem will itself point to the probable cause. If you have specific tests we should make to identify what pin is probably getting the interference, we would immediately try the tests!

Thanks for the information, looks like it is very hard to try the transformer with shield.

What I can think that you may try to connect the transformer core to the bus voltage or primary ground if it is possible to have another try. You could also try to connect the Y cap to the Voutput instead of the seconday ground, this will somehow change the noise coupling path.

As you know that the root cause and the way of the high frequency noise coupling is not a simple and direct. Unfortunately we did not have a direct clue to point out the probable cause. As soon as we know that the V pin is sensitive to the nosie, but as what you mentioned, you already tried to have a direct connection to source, and the issue is still there.

I would recommand you to contact our local FAE for further support if you tried all these proposals, and they can put a close eye on the board and help you out.

Thanks