UCD9244: CLF fault during power-down sequense

Hello, 

During the active ramp-down (soft-off), the UCD7242 is not capable to report the correct current. There are actually a couple of older posts on this forum which are mentioning this. I'm not sure if your channel 2 waveform is inverted (IMON), but typically the inductor current should actually be going negative during the TOFF FALL period. 

To overcome this issue, I would suggest to either:

1- Use Immediate-Off in the configuration (set through Rail Config > On/Off Config). This will make the controller stop regulation, instead of try to switch all the way down to zero in closed loop. 

2- You could try to increase the TOFF FALL time to reduce the overall negative current amplitude 

Also, for your second question. Can you please capture the PMBus status bits and data logging values after a failed power attempt? You may want to clear the logs before trying to avoid logging older faults from previous tests. 

Hi Matt,

1) Fast OC Fault Limit exceeeded:

2) IOUT OC Fault Limit exceeeded (Fast OC Fault Limit is too high or set to zero):

There is no change of the controller status when I am trying to start that rail by changing the active level of the control pin or by selecting the "Always Converting" mode on the System Dashboard page  - it stays in the "Output Off, POWER_GOOD#" state for the 1st attempt. It doesn't matter whether I have cleared all faults before start or not. And there is no (new) logged faults after the 2nd (successful) power on.

BR,
  Denis

Matt Schurmann said:

Use Immediate-Off in the configuration

It is too hard to satisfy the proper power-down sequence in the multiprocessor system using Immediate-Off mode without significant increase in the shutdown process duration that is unacceptable e.g. in the case of an input power failure.

Matt Schurmann said:

I'm not sure if your channel 2 waveform is inverted (IMON), but typically the inductor current should actually be going negative during the TOFF FALL period.

That waveform is not inverted. Both Ch2 (IMON) and Ch4 (current probe) show similar positive values with higher load currents, and Ch4 (current probe) confirms that the output current is going negative during the TOFF FALL period.

Unfortunately there is no significant reduction of the peak IMON voltage with the TOFF FALL time increasing.
When I have increased this time from 5ms to 15ms the negative output current has reduced about 3 times (~70%) but the IMON voltage has reduced from 8.7A to 7.2A only (~17%).

Hello, 

I do not think we will be able to change the behavior of the UCD7242.

A few thoughts: 

- Since you are using a powder core inductor, it is probably safe to increase the fast current limit value to provide more margin. 

- Could you add a dummy load with immediate off? It is possible also to gate it by power good/enable to avoid static power draw. 

Hi Matt,

We are currently considering two alternatives:
- to increase the fast current limit to, say, 95% of theoretical maximum value of an internal analog comparator, or
- to disable that fast current limit and to increase IOUT_OC_FAULT_RESPONSE timeout in order to prevent this fault triggering during the TOFF_FALL period.

And what for my second question (the rail doesn't start after failure during power off sequence)?

BR,
  Denis

Hi Denis,

I would not expect a different result for Enable or OPERATION start-up. Is it possible there is noise or glitching on the enable pin? Does the result change if you add an RC filter on the enable? 

Hi Matt,

It doesn't matter how I've initiated the start-up sequence:
- by changing the external voltage level at the physical control line (PMBus_Cntrl pin), or
- by changing  the "On/Off Config" - "Control Pin Polarity" setting issued from the TI Fusion Digital Power Designer program without changing of the external voltage,
so it is definitely not the problem of noise/glitching.

BR,
  Denis

Some more info:

This behavior still has observed when I'm disabling the Fast OC limit and somewhat decreasing the OC Fault limit (IOUT OC Fault is reported instead of the CLF Fault) - but only when the Fault Response is set to "Shut Down Immediately" or "Continue Operation For 0 ms" or "Maintain Output Current Per Limits" (with subsequent UV_FAULT in the last case).
There is however no subsequent unsuccessful power on event when the Fault Response is set to "Continue Operation For 1 ms" and the rail had been shut down after this timeout .

Hello, Can you compare the IMON waveform from the power stage in the case of a successful start-up, and a failed start-up. These are all consistent with triggering the OC fault due to inrush, but actually the Inrush current should be relatively small based on the schematic snippet you've posted, only a few hundred mA 

Hi Matt,

There is neither the IMON waveform nor the inrush current during a failed start-up as there's no switching at all - that previously failed rail is simply not trying to start.

The step by step sequence:

1. All rails are powered
2. The PMBus_Cntrl pin is changed to inactive state by an external controller
3. Rails start to ramp down in predefined order
4. One of the IMON pins reports fake current (up to ~50 times more than the real current - e.g. 5A instead of ~50+50mA at the 1st picture of my 1st post)
5. That measured current exceeds the limit
6. The over-current fault protection is triggered
7. This rail is shut down immediately, disabling its DPWM output, and a fault flag is set
8. Other rails are powered down as usual
9. The PMBus_Cntrl pin is changed to active state by an external controller
10. Rails start to operate except the previously failed one that stays inactive
11. The Power Good signal is not asserted due to the UV at this rail
12. The PMBus_Cntrl pin is changed to inactive state by an external controller
13. All started rails are powered down
14. The PMBus_Cntrl pin changes to active state again
15. All rails start to operate

The IMON waveform from the power stage in the case of a failed shut down and a successful one are at the first two pictures of my initial post.

SW node (the SW-B pin of the UCD7242) waveform (Ch3) with IMON (Ch2) during two consecutive start attempts:

The IMON waveform of a successful start-up

BR,
  Denis

Hello., sorry for the late reply.

I am not able to find an obvious reason for this behavior in the configuration file you have shared. And the IMON value looks normal during the first power-on attempt .

Does it make a difference if you issue a CLEAR FAULT, or if you clear the fault logs before attempting to re-enable the controller? Also if you set the OC FAULT RESPONSE to ignore, just as an experiment, does this change anything? Your status captures show the CLF+ IOUT OC, and sometimes only IOUT OC. 

Hi Matt,

fdm said:

 It doesn't matter whether I have cleared all faults before start or not.

These two status captures posted earlier are:
- Fast OC Fault triggered,
- Fast OC Fault disabled, IOUT OC Fault  triggered.

When I disable the Fast OC Fault (set Limit to zero) and set the IOUT OC Fault Response to "Continue Without Interruption" the IOUT OC Fault flag is set during the power off but there's no following "rail is not starting" condition.

This is really puzzling. All of your experiments point to OCP/Fast-OC being triggered during the ramp-up of first enable attempt, but we do not see any SW pulses (did you try to look at PWM also?), Imon is normal, and clearing the faults/clearing the logs does not make a difference... 

Is it possible there is loading from the probes that is masking leakage on Imon in some cases? Also, this is consistent across multiple boards/units... 

Matt,

I use 1:10 probes (10MOhm/8pF) so there is no significant loading.

PWM node waveform (Ch3) with VOUT (Ch1) and PMBus_Cntrl (Ch4) during two consecutive start attempts:

There is no logged faults seen after the 1st (unsuccessful) power on, provided that I have cleared flags before start.

It looks like a bug in the UCD9242 microprogram.

Is there any cross-rail leakage here? Trying to understand why the output voltage went up 200mV without any PWM pulses. 

Yes, it certainly is a cross-rail leakage. There's the same stuff with the only 1.5V rail enabled - without any leakage:

I am checking if we can find an eval board to try and reproduce this case. It will take some time.