UCC28633: UCC28633 -- how to avoid Vdd(OVP) tripping due to primary-winding demagnetization voltage overshoot?

Hello Ken,

Thank you for your interest in the UCC28633 PSR flyback controller.

I think maybe all three of your questions may be related to the same issue. I believe the problem(s) may be caused by excessive leakage inductance between the transformer primary and secondary windings. At light load, this leakage could divert a significant part of each switching cycle's energy to the bias winding first before delivering the remaining part to the load.

In this situation, the bias VDD can build up to the VDD(ovp) threshold which has a range of 16.5V minimum to 18.3V maximum (17.5V typical). If VDD OVP is avoided, the other two issues may come about this way:

Issue 2 - Regulation is done by sampling the reflected bias-winding voltage at VS. If high leakage favors the bias winding, then that voltage may rise a bit compared to the output and it drives the switching frequency lower. Now the load pulls Vout lower and this overcomes the extra voltage at the bias winding and the controller responds with a higher frequency to restore Vout. This then raises the bias voltage and the cycle starts over again. It appears that the loop-response has a crossover frequency of about 2kHz.

Issue 3 - As Vout increases during a heavy load start-up, the leakage energy is higher (highest peak currents) which will add to the bias-winding voltage sensed at VS. As Vout approaches regulation, this appears as an overshoot at VS and the loop cuts switching back significantly as if Vout was close to (but not at) OVP. The reduced frequency and the heavy load quickly pulls Vout down and the voltage at VS drops enough to resume high frequency. The heavy load helps to settle the control-loop to stready-state regulation.

I recommend to investigate your transformer design and determine if the primary to secondary coupling can be improved.

Regards,
Ulrich

Hi Ulrich,
Thanks for your response. I agree with your analysis as regards cause of oscillatory behavior and so forth. I think that I have Vdd(OVP) tripping resolved -- at least, this is not causing me a problem at the heaviest loads that I can yet achieve. But all three problems are related to energy accumulations due to FET turnoff spike.
The (custom) transformer is based on EE-25/28/10 core/bobbin. It has 340E-6 H primary inductance and < 10E-6 H primary leakage (measured on bridge and also in active circuit). Its construction is layered with tight coupling, two layers of secondary sandwiched inside two layers of primary. It is a hand-built prototype. In order to reduce bias-winding turns from 8 to 7 I rewound bias winding outside of others, and so my present prototype would definitely have poorer coupling between bias winding and others than an automated winding machine would produce in the final construction.
I could work on building up a new transformer prototype with the original construction, in which the bias winding is also sandwiched inside the two layers of primary along with the secondary. However, I am not confident that this would have much impact upon the loop instability.
There are 3 windings, and leakage (i.e. self inductance) on a winding with respect to one pairing (e.g. pri-sec, pri-bias, sec-bias) is not necessarily the same as that within another pairing. To the degree that self inductance on one winding with respect to both other windings is equivalent, it is theoretically possible to snub out all of its voltage overshoot.
But in observing waveforms on the 'scope it appears to me that there is substantial coupling between primary and bias in the overshoot at FET turnoff. This coupling is magnetic (i.e. not capacitive). It is not clear to me how increasing the coupling between bias and primary windings would make any significant difference at all.
I am not a wound-magnetics expert, but I think that the performance we are working with is compatible with industry norms. I would not think that exotic techniques, such as tri-filar windings, should be required. We seem to have between 2% and 3% leakage-to-magnetizing inductance ratios -- I think that this is reasonable. Can you suggest whether better should be feasible, and if so how, using a practical winding topology?
Again, although I did not anticipate these problems, I would think that they would be pretty universal in applying the UCC28633. I am surprised that they were not mentioned in any TI literature that I had come across -- I might have considered another IC controller.
I look forward to any further guidance that can be provided. At this stage, however, I do not consider the problem resolved for reasons stated above.

Hi Ken,

Thanks for your quick reply. I'm sorry that my first suggestion isn't panning out. I agree that your transformer design seems to be a good one, with pretty decent leakage inductance. My concern had been that the primary was coupled to the bias better than to the secondary. That doesn't seem to be the case, so I see no reason to recommend to change it. Instead, let's try a different approach.

In Figure 44 of the datasheet, the EVM application circuit contains a 4.7R resistor R1 between the bias diode D1 and the VDD cap C2.
If your circuit does not have a resistance here, try adding one. If it has one of low value, try increasing its value.
It's purpose is to act as a low pass filter to smooth out the FET turn-off voltage spike that may peak-charge the VDD cap.
The resistor value should not be so high as to prevent sufficient charge into the VDD cap at narrow on-time and low frequency (usually at light loads), lest the VDD voltage fall below the UVLO turn-off threshold. Allow for some margin.

This EVM also has a 1000pF cap C14 (at bottom right of Figure 44) in parallel across the bias winding. I'm not sure why it is included, actually, maybe to combat EMI. If your design has one, try reducing it or removing it. If you don't have one, try adding one in increasing values to see if it mitigates any of the symptoms of your design.

Further following the FET turn-off spike path, try reducing the primary clamp voltage a bit if you have some margin to do so.
A lower spike may help ameliorate the bias spike problem. But beware of increased snubber losses if the clamp voltage is reduced too low.
I admit this is a trial-and-error approach. Many applications are unique so what works with one design may not be appropriate for another. Please let me know if any of this helps you.

Regards,
Ulrich

Hi Ulrich,

I had noticed the 4.7 ohm resistor and also the 1000pF cap already. I have already experimented with these.

Like you I see no good reason (including EMI suppression) for the 1000pF cap -- at least, it cannot help or impact this problem. But I verified this by actually adding into my circuit, and got the expected results -- large reduction in ringing frequency on bias winding at FET turn-on, but no other effect. Spec's mention test condition of 700pF at least once.

A series resistor cannot solve the problem(s), and is inadequate to control Vdd over a wide load range even with resistance value optimized, but could work well for a narrow load range (i.e. fixed load). Our app requires a pulsed load over a very wide programmable range. It is intrinsically a range of > 100:1, and could be reduced to maybe 10:1 or a bit less with a pre/bias-load if necessary (although this is to be avoided if possible). But again, even a pre-load at the 100V output will not solve the currently observed problems, and there is no problem operating at minimum load < 1VA up to ~20VA, other than the undesired oscillation that appears somewhere between 10VA and 20VA load. Currently I am testing with a slide-adjusted wirewound resistor, but in the real app the load will be a programmable current source coupled through a low-voltage (i.e. < 200Vpp) winding of a line-frequency HV transformer. So the load in our equipment (under development) will look like quite a high impedance.

I am currently working with an RLC (tank) circuit instead of a simple series R, and this appears to work. I do not have (available) optimal values of components yet, but if optimized the tank would dissipate most of the excess energy in the FET turn-off spike at the bias winding. I have verified the efficacy of this approach to my satisfaction by experiment at this point. I will next order some more optimal-value R/L/C components and install to test that the load-regulation of Vdd can be further improved as I expect. But even as is, the solution might prove adequate for the full load range.

Since our last exchange I have tested pre-loading Vdd to match and/or exceed proportional rate of decay at (100V) output. This appears to have no significant effect upon the loop instability that produces the ~2kHz oscillation. Nothing abnormal appears on the input (i.e. switched DC primary voltage). Presumably the oscillatory frequency would increase with increasing load (above 20VA) if full voltage could be achieved.

I am concerned that the problem may be fundamentally unsolvable for our app with the UCC2863x devices. Standard frequency-comp methods are of course not possible with these devices, as far as I can see. Do you agree?

Can you provide any quantitative info (i.e. spec's) for the so-called PID loop? Without this info it is very difficult to understand the loop instability. I would also request consultation with the relevant development engineer(s) -- if informed of the nature of our app, it might be clear to someone particularly knowledgeable about the internals of the IC that we cannot make it work. But I am not yet ready to give up without better understanding or info.

Datasheet p. 32 is pretty brief, but seems to be most relevant to loop dynamics. Possibly we do not have enough output capacitance (4.7E-6 Farads) -- I will experiment with increasing this to see if loop stability is affected. We are using polymer-film now -- increasing substantially would require going to AlO bulk cap. That might have been the assumption built into the comment about ripple-current rating in datasheet.

Most app's will probably require operation with a fixed load and at standby, but nothing in between. That is why our app might be a problem. Thanks again for your help so far.