PTD08A006W 5V operation

(Mostly) cross-posted (after a week without a response) from digital power section:

Hello Edgar,
You state that the logged failures are either (1) a rail fault line (input over-current), or (2) a large (impossible) negative current transient on a module.   What do you mean by "rail fault line"?  Is this the FLT signal the is returned from the PTD module to UCD controller?  (Indicated as "FLT fault" in the logged faults or  the STATUS_MFR_SPECIFIC status word.)  The gate driver in the PTD module (which is a UCD7230A) will generate a FLT if the input voltage to the driver is below the undervoltage lockout (UVLO) value.  From the UCD7230A datasheet this is:

LOW-VOLTAGE UNDER-VOLTAGE LOCKOUT

VDD UVLO ON  (VDD rising)            4.25     4.50     4.75 V

VDD UVLO OFF (VDD falling)          4.00     4.25      4.50 V

VDD UVLO hysteresis                     100      250       400 mV

So it could be that during start-up the inrush current required to charge all the output capacitance in your system is causing the 5V to sag and generate the UVLO induced FLT events.  The fix, as you surmised, would be to slow down and spread-out the start ramps on each rail in the system. 

Let me answer your numbered questions in reverse order:
4.  The UCD9248 would indeed be better because it has enhanced sequencing capability.  The programmable sequencing enable pins/events are split into two types of enable signals:  a) turn-on dependencies and b) stay-on dependencies.  This allows you to define a stay-on dependency for a rail such that if a rail fails to come up, the other rails can be configured to shut down. 

3.  You need to insure that you stay above the 4.75V UVLO for the PTD08A006W to work reliably.

2.  Yes, using the stay-on dependency capability of the UCD9224/46/48 controllers.

1.  Each fault that is detected by the ADCs in the UCD92xx: OC, OV, OT, UV, etc.  has a configurable fault limit and a configurable fault response action--including how to re-start from the fault.  Unfortunately, the FLT indication from the driver/power module does not have a corresponding fault response command.  So the recovery must be handled by the host by either sending an OPERATION command to turn off, then on, or by cycling the PMBus CTRL signal.  (This is the behavior that is specified by the PMBus standard.)  There is a way to disable the FLT indication.  That is to configure the FLT input pin to be a sequencing input and then not assign that input to any of the voltage rails.  Of course, by disabling the FLT signal you lose the ability to monitor a true OC that is detected by the gate driver.  In this case the UCD92xx can still detect an OC by monitoring the AO output from the PTD module, but at a slower response since it is monitoring AO with the internal 12-bit ADC and the measured current is compared agains the configured limit in firmware.

Mark,

Yes by rail fault line I mean the FLT signal from a module driving a rail, as logged by the UCD. This specific rail fault has been sporadic, but relatively consistent across multiple systems. It is the second (or third) rail to go up, and it is the rail with the lowest power consumption in the system.

We looked at the input rail during start-up and, given the amount of filtering and regulation, the supply power looks extremely stable. I have looked carefully at start-up conditions, and I fail to see any transients that could explain this problem. My initial instinct has been our possible use of excessive filtering around the main supply components, but the scope traces suggest otherwise. Although the 5.15V supply goes through a 3.3µH inductor before it gets to the modules, that filtered node has more than 1.3mF total of low-ESR capacitance just beside the modules (>330µF/module). We have even increased UVLO on the UCD to 4.9V to no avail.

Two more systems have started failing but, in this specific case, the problem _seems_ to have been related to a cold solder joint in an output shunt for the rail (but I suspect just heating the area might have more to do with this). One of the systems, the one that had the most consistent problem, stopped failing after I liberally applied freeze spray to the UCD and PTD components while trying to find the cause of the problem, and has not failed since. Applying heat to components near the rail also seems to solve the problem for several days (going from multiple failures in sequence across multiple days to none for more than a week). This might all be multiple coincidences, as I can't see what mechanism could account for all of this, but it is the only consistent behavior I have managed to discern.

Edgar,
It still looks like you may be getting a momentary drop in the 5V Vin voltage during start-up.  The 3.3 uH inductor in series with Vin does not help in this case.  What is the DC resistance of this inductor?  If there is more than 100 mOhms of resistance in the windings and 2.5 Amps of inrush to charge the output capacitors you will see a 0.25V drop in Vin.  The thing to instrument is pin 12 of the PTD module.  This is connected to pin 18 of the UCD7230A driver in the module.  It is this voltage that is compared against the 4.75V UVLO in the driver.  

The issue is the input bus voltage is drooping below 4.75V during power -up mode.The input IR loses must be reduced.

Mark,

I'll get back to you on the specific values, but it seems to me that just the 1.3mF of low-ESR capacitance (without taking into account parallel ceramics, or extra input from the main supply) should be able to sustain 2A continuously for 160µs (a full 160 PWM cycles) with less than a 250mV drop (I do have to check on the specific ESR and DCR values, though). Given that this subsystem consumes less than 10W, that the faulting supply is the one with the lowest power consumption, that it is not the lowest or the highest voltage in the system, and not having been able to see any power dip under any conditions (even when inducing a fault by cycling power too fast) makes me doubt this to be the case.

We now have a worse problem that shows the same manifestation but occurs while the system is running for a few hours (causing a power-down). Our system does not have big shifts in power consumption while it is operational, I expect less than 5% variation overall and that would mostly be due to thermal effects on the components. So it should be running steady state without any big shifts in the power supplies.

I have tried to instrument two of these systems, but the problem seems to have disappeared just by my soldering a couple of 1" 28-gage wires for test leads. It has not resurfaced in more than 5hrs of oscilloscope capture in what was a consistently failing system (more than 5 failures in a couple of hours before I attached the oscilloscope). I have instrumented the input power directly to the module leads so, if the system fails overnight, I should have a capture of the event by tomorrow.

I am starting to suspect that the problem might be due to noise in the fault line or analog GND connections. We seem to have excessive noise being coupled to ground by our main (external) 24V supply. This noise, when combined with internal system noise _might_ be the cause of all the problems we are seeing. The fact that the specific faulting supply is the one closest to the UCD and to the power input suggests that the noise might find the path of least resistance from that supply (either via signal gnd or the FLT line itself). We also have anecdotal evidence that the problem surfaces more readily (within 30 minutes or so) when a separate PWM supply (powering a low-temperature heater directly from the main 24V supply) is also running in the system (thus increasing overall PCB noise).

My noise measurement is relative to power GND with a floating oscilloscope, and the capacitance of the oscilloscope body has considerable effects on such measurements. I have confirmed the presence of some noise on the FLT line (~300mV) with a fully-isolated 100MHz scope, but I cannot trust the measurement as the pulses seem to far exceed this oscilloscope bandwidth and could have been coupled directly via the leads.

What is the likelihood that narrow noise pulses (sub-10ns) in the FLT line would be recognized by the UCD as a legitimate fault?

Could such fast noise pulses via power or signal gnd directly affect the circuitry in the module?

Thanks!

Tom,

If the problem was that obvious, I would not have felt the need to post in this forum!!

This specific subsystem has 1.3mF (that is mili-Farads) of low-ESR capacitance on the input power node, in parallel with more than 100µF of ceramics. It can sustain more than 160µs of full-power consumption (without any additional power input!) before the voltage on the capacitors dips down to such 4.75V level (and the modules are running at 1MHz).

The specific supply generating the fault is the one with the lowest output current, and it is neither the lowest nor the highest voltage in the system.

I have carefully looked at the input voltage nodes with a wide-bandwidth oscilloscope and absolutely no dips or sags can be seen when the fault happens.

Now I am starting to see the same faults on a steady-state running system (less than 5% power variation). That is, the problem is not even due to power-up inrush.

Any other ideas?

Edgar,
The reason I keep coming back to the inrush current is the following:

·         This PTD module has a 140 nsec minimum pulse width.  Therefore the UCD92xx controller will perform the soft start by setting the setpoint reference to
      Vout = Vin*Fsw*140 nsec = 0.24V  (at Vin = 5V and Fsw = 350 kHz)
Then the controller applies a PWM duty cycle with a fixed 140 nsec pulse width until the voltage reaches this setpoint reference value.  When the sensed output voltage is within +/-64 mv of this setpoint voltage the feedback loop is closed and the rest of the soft start ramp is performed by ramping the setpoint reference up to the final output voltage.

·         While the controller is outputting a fixed pulse width, the current is strictly a function of the time constant of the LC output filter.  The formula for this current is presented in section 5.5 of the UCD92xx Design Guide.  If there is a lot of capacitance on the output, this current can be substantial.

·         The soft start takes several msec.  So depending on where the input inductor is relative to the 1300 uF of input capacitance in your system, there can be a not-insignificant IR drop as seen at pin 18 of the gate driver IC.

·         You state that the voltage rail that is generating the FLT fault is a low current rail.  This also points to a under voltage condition as the source of the fault. 

OK enough about inrush current.

·         The FLT input to the UCD92xx is a standard 3.3V CMOS digital I/O, so it should have 0.5V or more of noise margin.  However, this pin when configured as a fault input, generates an interrupt to the core micro on a positive edge.  So a pulse as narrow as 10 nsec will generate a fault if the amplitude is large enough.

·         If you think that ground noise is an issue, you could try applying an additional 1.0 uF ceramic cap at either the V33A or V33D pins to the closest ground.  We have seen some customer applications where the monitored current and temperature variation was compromised by poor decoupling between V33A and gnd.  In this case the distribution of monitored values was improved by adding the additional capacitance such that there were no vias between the V33A and gnd pins on the controller.  (That said, I am not sure that there would be an expected improvement in noise margin on the FLT pins.)

·         Another source of the FLT event could be noise on the current sense signal in the power module.  There is a analog ground pin on the low power connector of the PTD module which is separate for the power return ground.  This pin allows you to tie the ground for the temperature and current signals from the module back to the ground for the controller.  You could try an experiment to try to separate this signal from the Vin ground and Vout ground.

Regarding inrush current:

Thanks!! I was not aware of that delayed Vstart in these modules. In our system we are running at 1MHz, which makes Vstart =  700mV, greatly increasing inrush current. That could explain why raising input voltage by 100mV considerably improved performance. I now realize that we might be having two somewhat unrelated problems that show the same basic symptoms (although, after going through the numbers, I believe ground bounce due to the inrush current to be more of a problem than the inrush itself).

BTW: I verified all components and layout, capacitors are directly against the module pins (which also connect to power distribution planes providing less than 2mΩ impedances between modules). We have 330µF 160mΩ ESR capacitors (one per module, for 4 capacitors total which brings capacitance in those nodes to 1.3mF with ~50mΩ ESR). This is in parallel with four 22µF X5R ceramics so effective ESR is considerably lower. The supply inductor (needed for main supply stability given the large capacitance in these nodes), has a 24mΩ DC resistance. So we should be able to tolerate in excess of 5A to 10A inrush without inducing a fault condition. Raising the supply to 5.15V (as we did) should allow for a 8A to 16A inrush.

I am hesitant to reduce switching frequency too much, as this would put it in the bandwidth of our analog system. But I could tolerate going down to 750kHz or even 500kHz, which should considerably reduce inrush problems.

Regarding noise:

BTW: As I feared, neither of the instrumented systems failed overnight. Which is what has made this problem a pain to diagnose.

Our system has separate power GND and signal GND planes. Pin 7 (AGND) of all the modules is connected to signal ground while pins 2 and 3 (GND) are connected to power ground. The UCD ins only connected to the signal ground lines. The impedance between power GND and signal GND (one-point connection) is 9mΩ. I have 4.7µF ceramics on both V33A and V33D. So there is little more that I can do regarding noise internally in this system.

I am suspecting that the problem might have to do with high-frequency noise injected into the system. Although internally there is a one-point ground connection, externally there exists a ground loop that could inject high-frequency noise directly across the PGND-SGND bridge. This could even be exacerbated by the very large capacitance between +5V main power and PGND. I will try simply placing capacitance on the module's FLT line itself.

Thanks again.

- Edgar