This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UCC28950: Master-Slave Configuration. Starup, Burst Mode.

Part Number: UCC28950
Other Parts Discussed in Thread: PMP, , UCC28951-Q1

Hello experts,
Google translates my letters from German to English:


I am currently working on developing a DC / DC power supply.
It is designed as 2 parallel channels (2x 55V, 1000W). PMP 6712_Rev.D was taken as an example.
On the secondary side I have full-wave rectifiers with Shottky diodes.

The controller UCC28950 is on the primary side, feedback via SFH615-A3.
Two UCC 27714D are used as Mosfet drivers, taking into account SLUA 787 “Gate Drive Outputs on the UCC28950 and UCC28951-Q1 During Burst Mode Operation”. This is implemented as a daughter board (DB).
The problem looks like this:


1. When starting with different DB (controller UCC28950) it can happen that the channel configured as master either does not start or goes out shortly after the start. Slave channel starts without problems.
      When the load is applied, the master also starts and everything works.
      In some cases you can get the master to start by reducing Tmin (R_Tmin from 130K to 20k, for example).
As two independently configured channels, the two start without any problems.
The increases in the Css only for the slave channel by a factor of 2 to 5 or the resistance from 820k to 1.2 meg did not help.
How can you get around this?


2. The DC-DC power supply leaves the burst mode at approx. 22..25% of Po_max. I would like to have it at around 10% J. Changes in the T_min time from approx. 700ns to 140ns have hardly brought anything. In my opinion, the downsizing of R_gate could help here. I didn't want to do that because I fear the possible EMC problems.
Is there another way to shorten the transition from burst mode to normal mode?

ZVS occurs at a load of approx. 35..37% (left leg) -Ok.

Thank you!

  • Hello Juri

    1/    First thing to do is to try to figure out why the 'Master fails to start but Slave starts ok'

    Am I right in assuming that this is a start up into no load ?

    Check the SS/EN pin of the Master and Slave when the 'Master fails to start but Slave starts ok'. If the Master were operating in ILIM it might be that the SS/EN pin drops below the 3.6V hiccup threshold at which time switching stops. Or, if the SS/EN pin is pulled below 500mV switching will also stop immediately.

    Check the SYNC pin on the Master - this is the pin that supplies the synchronisation signals to the Slave.

    2/ Check the width of the TMIN pulses coming out of the controller - The overlap between the OUTA/OUTD signal pair and between the OUTB/OUTC signal pair. Compare this to the width of the voltage pulse applied to the transformer. They should be fairly similar. If you see 200ns pulses from the controller but 700ns at the transformer then the effective duty cycle is much larger than the one being demanded by the controller. You will need to diagnose where the additional delays are coming from.

    Please let us know how you get on.

    Regards

    Colin

  • Hello Collin,

    Thank you for your response.

    You are right: it is a start without load, OR with a low load up to 1% of Po_max: at higher load, both start as intended.

    I will do the new investigations later because I am still working on the other projects. I hope that I can get back to you at the beginning of next week.

    At this point I am irritated by the fact that out of 7 controller cards I have 2, which make no problem at all when starting! In another I reduced the resistance R_Tmin from 130K to 20k and then the masters and slaves start properly. The rest start properly only under load.
    With two "good" controller cards changes of R_tmin have NO influence on the startup rutine.

    Therefore, I thought that the problem may be due to the tolerances of the internal power source that Css is charging (20… 30 microamps). Increasing the Css from 100nF to 570nF on the slave channel did not solve the problem.

    Ok, as I said, I will carry out the measurements you have proposed and I will contact you on February 11th… February 12th, 2020.

    Regards
    Jurij.

    Burst Mode at low load is shown here.  Blie V_QA_d; gelb: V_QDg; lila: Ipri

  • Hello Collin,


    here are my measurements for point 1):
    First start the process with the "bad" DB (controller UCC28950). You can see that the master starts briefly and then goes out. The slave channel starts without a problem. Fo = 100 kHz,
    C_ss / en = 100nF, with slave C_ss / en = 100nF + 820k in parallel. C_Vdd = C_Vref = 1u5 ceramic X7R
    Ch1-V_SS / EN master, Ch3-Out-D master; Ch4- V_SS / EN- Slave, Ch2-Out_D-Slave:

                                                                               Bild. 1

    Ch1-V_SS/EN-Master, Ch3-Out-D-Master; Ch4- I_pri-Master, Ch2-Out_D-Slave:

                                                                          Bild.2

                                                                          Bild.3

    Why does the master crash during the start, then start again and then finally "off"?

    Now the "good" DB (controller UCC28950). Hopefully the two channels will start right here, the same power unit.
    Ch1-V_SS / EN master, Ch3-Out-D master; Ch4- V_SS / EN- Slave, Ch2-Out_D-Slave:

     
                                           

    Bild.4

    Bild. 5: Ch1-V_SS/EN-Master, Ch3-Out-D-Master; Ch4- I_pri-Master, Ch2-Out_D-Slave:

      

     

      
                                                                              

    Bild.6-8

    Can you please explain these start-up processes to me?

    Where could the fault be?
    Increasing C_Vdd and C_Vref to 2uF did nothing.

     

    Regards

    Jurij.

  • Hello Jurij

    I'm afraid that the images didn't come through. This can happen if you don't use the paperclip icon to insert the images (he e2e user interface can be a bit counterintuitive at times) - can I ask you to try it again please ?  And just to make sure, can you email the images to me as well at colingillmor@ti.com 

    Apologies for the delay.

    Regards
    Colin

  • Hello Collin,

    Thank you for your answer.
    I will send the oscilloscope recordings to your email.

    Regards

    Jurij

  • Hello Jurij

    Thanks - I received them this morning. I'm going to keep this thread open just in case we find something that would be of interest to the wider community.

    Regards

    Colin