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.

UCC21750: FLT pin goes low even when the PWM is always low and EN pin is low too.

Part Number: UCC21750

Tool/software:

Hi,

We have been using UCC21750 for a long time without any issues. Recently we use it in a synchronous rectifier circuit. First we disabled the MOSFETs driven by the driver chip, but we still see FLT pin going low. This is strange since the PWM is always low. 

Are there any other reasons why FLT can go low even when the PWM is always low?

Thanks.

  • The MOSFETs driven by UCC21750 are supposed to work as diodes since the PWMs are low and RST/EN pin is low. So the desaturation should not be even tested. But somehow the FLT pin goes low and is latched to low. This is very strange. Please help explain what can cause this to happen.

  • Hi Charlie,

    Thanks for reaching out to us. 

    Please share the additional details about FLT Low behavior. 

    • Is the FLT going low immediately after power up? Or after PWM was toggled?
    • what is the test setup temperature?
    • Is it possible to capture the waveforms - esp VCC, DESAT, FLT, RDY during power up and when FLT goes low.

    Thanks

    Sasi

  • Hi Sasikala,

    • Is the FLT going low immediately after power up? Or after PWM was toggled?                                                         No, FLT stays high and the MOSFET does work as a diode after power up. Then I start to put some step load on the circuit, the FLT pin of one driver goes to low and latches there. PWM is always low. EN pin of the driver is also low all the time.
    • what is the test setup temperature?                                                                                                                          Room temperature, about 25 degrees C.
    • Is it possible to capture the waveforms - esp VCC, DESAT, FLT, RDY during power up and when FLT goes low.        It'll be difficult since the chip is soldered to the bottom side of the PCB which is mounted onto a heatsink. But let me see how to connect some probe wires to the board. I'll post the waveforms when I have them. 

                The two MOSFETs (Q_term3 and Q_term5) are the used in the secondary side of a phase-shifted full bridge DC/DC converter. We first just try to use the two MOSFETs as diodes. So the drivers shouldn't be even working, let alone reporting fault. 

    Thanks.

  • Thanks for your quick response. Really appreciate it.

    Please do share the waveforms, it will help us to understand the system scenario. If more than 4 channels can be captured. We are interested to monitor Vout, VDD voltage close to gate driver.

    You mentioned 1 driver's FLT pin is low. (which MOSFET driver position?) Is it possible to swap the gate driver with another driver to understand if its a specific one driver failure or the behavior repeatable for any driver installed on that position? Trying to understand if its driver fault or if the FLT is observed on a particular driver position.

    Thanks

    Sasi

  • It's always the driver for Q_term5. It'll be difficult to swap the chip. 

    We'll try to capture the waveform, but in general, when the MOSFET is used as a diode (PWM is always low, EN pin is always low), is it possible for the driver chip to report a FLT? I am trying to see what kind of fault mechanism this can be. My understanding was that when the driver receives low PWM then desaturation will never be checked. 

    Thanks. 

  • Hi Charlie,

    Unless if the device is replaced with a different device, we will not know if its a specific device issue. Or is the failure observed on multiple boards on the same location?

    Yes FLT will be triggered only when DESAT is triggered. There is a potential reason for false FLT, due to system noise - which is causing DESAT > threshold or other ways to impact FLT, which we need to understand by observing the waveforms.

    FLT, VCC, VDD, DESAT, RDY, OUTH, OUTL. (please use high BW probe so that high freq component are captured) for all secondary signal capture, it needs to be differential probe.

    Looking forward for your capture.

    Thanks

    Sasi

  • Hi Sasi,

    Sorry for the late reply. 

    The DESAT pin is actually directly linked to COM to disable the DESAT protection. But when we do step load on test, the DESAT fault is still triggered. 

    I took the screenshot of the Vin+ to Vin-, DESAT, and FLT, as shown below. The bandwidth of the probes is 200MHz and 100MHz for the oscilloscope. 

    CH1 (yellow curve) is the DESAT signal, CH2 (blue curve) is the PWM input signal, and CH4 (green curve) is the FLT signal. At the moment FLT went down to zero, PWM input is low and DESAT is also low. The peak value of the noise on DESAT signal is around 2.2V, far lower than 9V threshold. But FLT is pulled low to report a fault. 

    Following your suggestion, I'll check the waveform of VCC, VDD, VOUTH, and VOUTL. 

    Thanks.

  • Also two different boards have been checked and both show the same problem. This suggests that it's not some bad component on the board. 

    Thanks.

  • The waveforms of VCC (Ch2 blue curve), VOUT (Ch1, yellow curve), and FLT (Ch4, green curve) are shown in the screenshot below. When Flt happens, VOUT is low, and VCC is at 3.3V).

    The waveforms of VDD (Ch2 blue curve), VOUT (Ch1, yellow curve), and FLT (Ch4, green curve) are shown in the screenshot below. When Flt happens, VOUT is low, and VDD is at 15V).

    All shows that Desaturation fault shouldn't be generated and reported. Please help find the possible fault generating mechanism here and advise about possible solutions.

    Thanks.

  • In another post in this forum, UCC21750-Q1: Desat Error - Power management forum - Power management - TI E2E support forums, Andy Robles mentioned that if the DESAT pin is tied to the COM pin and the FLT is still pulled low, there should be system noise coupling into the gate driver internal circuitry. 

    This is exactly our case. 

    The question is: what is the path of the system noise coupling into the chip internal circuity and how to cut it off to make sure no false FLT is reported and no chip locking up? 

  • Hi Charlie,

    Thanks for all the screen captures and ruling out all potential FLT low scenarios. 

    FLT will be low incase of the following scenarios: DESAT occurs, VCC /VDD supply disturbed and noise impacting the gnd planes.

    If it is noise induced, need to isolate the noise source. Our understanding of noise coupling path is mainly through COM and VEE, and some cases through GATE (OUH/OUTL)

    During the FLT event, I see noise coupling to all channels (assuming that it is due to some switching).

    Please try the following options, priority as shown in the list below.

    To reduce Supply noise coupling:

    1. Add common mode choke to the supply VDD, VEE

    2. Also ensure that 10nF cap (and /or) other smaller value based on system noise range

    To reduce Ground noise coupling:

    1. Is there a way to keep the noise source away from the gate driver? are the grounds shared between noisy node to gate driver COM/VEE plane as 1 big plane- if yes, can it be separated.

    2. Is it possible to slow down the switching event (by having snubber circuitry)

    3. is it possible to add HV cap (~20pF) across GND and COM nodes (this is to bypass the common mode HF noise)

    4. Reduce capacitance between GND and COM (due to isolated bias )

    To reduce GATE noise coupling:

    1. Add ferrite bead at the gate (plan the ferrite bead freq targeted for the system noise range)

    Hope it helps in your scenario. I will close the ticket for now. For additional support, we can further communicate through Email.

    Thanks

    Sasi

  • Hi Sasi,

    OK, it looks like noise messing up the internal circuitry of the chip. I'll try the methods you mentioned above. 

    Thanks.

  • Thanks Charlie for your continuous debug inputs, really appreciate it. As we connected through email, I will close the E2E ticket for now.

    Looking forward to hear your debug outcome.