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.

UCD90120a Voltage fault max glitch time not working

Other Parts Discussed in Thread: UCD90120A

I have a rail defined as voltage but monitoring current.

There is a large surge current charging the capacitors when the rail is turned on.

The voltage on the current monitoring rail goes way above the OV limit, but for less than 200 uSec.

I have set the Voltage Fault Max Glitch Time to 0.8 msec, and set the Vout Over Voltage Glitch filter to ON, and response to Shut down immediately, do not restart.

I find that when I turn the rail on, it turns off again with an OV fault within 500 usec. this is less time than the glitch filter.

Am I somehow misunderstanding how the glitch filter is supposed to work? Shouldn't the UCD90120A ignore voltage excursions above the limit for less than the voltage fault max glitch time?

  • The glitch filter has 0.4ms resolution. So when you set the glitch time to be 0.8ms, the actual glitch time can be somewhere between 0.4ms and 0.8ms.
  • But my "glitch" is less than 200 usec, so it still should not have triggered the OV fault.
  • In Fusion GUI, pin assignment, click the Configure button next to the rail-in-question. In the pop-up window, is the Voltage Monitor Type set to Hardware Comparator? Hardware comparator doesn't have glitch filter.
  • No, I'm not using the hardware comparator.

    Is the voltage reported back when I read the voltage filtered (averaged), and the OV Fault based on instantaneous readings? If the raw A/D readings were significantly noisier than the reported values, it might explain the behavior.
  • The reported voltage is instantaneous ADC value. I also suspect that noise is the cause.
  • I just did another experiment. I set the glitch filter to 2.0 ms. Turned the supply on, and it shut off again within 392 usec with an over voltage error.
    I'd send you a copy of the scope traces, but this forum does not seem to allow that.
  • I tried changing from "shut down immediately" to "Shutdown with delay" and set the shutdown delay to 3.0ms.
    On failure, it still shuts down within 600 uSecs of turn on.
  • Configuring the MON pin as current will provide filtering and remove noise.

    Add external filter cap on the MON pin will also remove the noise.

    The shutdown delay does not help because it merely delays the shutdown decision.

    With the glitch filter time set to 0.8ms, upon sensing the OV condition, the device will check the ADC result again when 0.8ms is elapsed. If the OV condition still exists at that time, the rail will shutdown. So, if the OV condition goes away in 0.2ms, and then re-appear in the time window near 0.8ms, the device will consider this as a sustained OV condition, and shut down the rail as a result. Therefore, if the monitored signal is bouncing (OV condition comes and goes), it is better to set the filter time longer than the bouncing time.

    Lifting the OV threshold will also help avoid mis-triggering.
  • I have lifted the OV threshold to almost no effect. I have set the filter time very large and still had very quick shutdowns, much shorter than the filter time.
    Is there any issue with cross rail shutdowns? the current sense rail does not control the rail enable line itself, it is linked with the Fault Shutdown Slaves so a fault on the current sense rail shuts down the rail that actually controls the supply.
    I presume the glitch filter still works even if the rail does not have a control output? Hmm, I'll try assigning a dummy control output to the current sense rail.
  • Hooking up a control output to this rail pointed out a setup error I had. I had the On/Off Config value set to zero.
    I fixed this and changed it to 0x18.
    Since both the main rail and the current monitoring rail are turned on by the software, the current monitoring rail gets turned on about 2ms after the main rail. I would have expected that the current monitoring rail would not monitor for OV faults until it was turned on, but I am getting the OV Fault shut down before the current monitoring rail is even turned on.
    A will attempt to have our software guy change the sequence to turn on the current monitoring rail first, and see if that enables the glitch filter.
  • OV is always monitored regardless whether the rail is on or off.
    But fault response is disabled if the rail is off, because the rail is already off. For the same reason, fault shutdown slave will not be affected.

    By setting ON_OFF_CONFIG to 0x18 (operation only), the rail is off until an OPERATION command is received. So, before OPERATION is received, OV fault will not trigger fault response .

    Actually, you may avoid the issue by enabling the current rail later (after the inrush current).
  • This does not match my experience. The primary rail (voltage, temperature & control) is set up to shut off if the secondary (current) sees a fault. The primary is turned on, and very shortly turns itself off before the secondary is turned on. The only error reported is an OV Fault on the secondary rail.
  • When a rail is in OFF state, it will not have fault response, and will not shut down its slaves.
    The fault log, however, will record OV fault, regardless whether the rail is on or off, regardless whether the fault is filtered out by glitch filter. The glitch filter is only associated with the fault response, not the fault itself.

    Therefore, when you see OV fault in the secondary rail, it doesn't mean glitch filter is not effective. If the primary rail is indeed turned off as a slave of the secondary rail, its MFR_STATUS register bit 0 (Slaved Fault) should be set.

    If the primary rail is indeed shut down by the secondary rail, the secondary rail must be somehow in "ON" state. The reason is described above. This also matches your observation that when secondary rail is set to OPERATION Only (without sending OPERATION, the rail is kept off), the slave shutdown does not happen.

    When you say " The primary is turned on, and very shortly turns itself off before the secondary is turned on. " How did you control the secondary rail to be turned on later than the primary rail? Have you checked the configuration? I can take a look at your project file.
  • I have not yet observed the slave shutdown not happening.
    Unfortunately, I have never been able to convince our software engineer to read out and make available the data from the UCD90120A when a fault happens. I have had to disable our microprocessor and reboot to attach the TI programming cable, and read out the fault logs. I will attempt to find a way to read the registers without resetting to see of the slaved Fault bit is set.
  • I figured out a way to get the software to stop polling the I2C bus so I could run the TI software with all of the power supplies properly programmed.
    When I turn on rail 2 with rail 7 already on (2 is the control, 7 is the current sense rail) it sometimes will immediately shut down. The only flag that is set is Vout OV fault for rail 7. the Slaved Fault bit is not set for rail 3, or any other rail.
    I'd be happy to send you the program, but I don't see a way to upload to this forum.
  • If you click "Use rich formatting" at the lower-right corner, you will enter an interface that allows you to upload attachments.
  • Labyrinth 53d Rev C Current.xml

    The design contains 4 power programmable power supplies. I had originally programmed the current measurement as the current for the 1st four rails, but I found that we only got 8 bits of resolution. This is why the current measurement is on separate rails defined as voltage.

    Current measurement on rail 5 is associated with the voltage rail on rail 1 etc.

    The voltage on each of these power supplies is programmable between 0.8V and 8V. This is part of a piece of test equipment, so the voltage & fault limits are set at run time, the fault limit values in this file are defaults that will get overwritten.

    The chip is programmed so that a fault on any rail shuts down all rails.

    I will add a waveform of what I am seeing shortly.

  • I have attached two wave forms of the turn on failure. The blue trace is the voltage of the power supply controlled by rail 2, the red trace is the current drawn, and is measured by rail 7. The green trace is measured on an LED that is controlled by the same signal that enables the power supply controlled by rail 2.

    The only error reported in both cases is an over voltage on rail 7.

    The first capture has rail 7 on, the second capture has rail 7 off. I see no difference in behavior, and neither one is what I would expect from the way this IC is documented.

    I must be doing something wrong, but I have not been able to figure out what.

  • 1. I have verified on EVM that, when a rail is in OFF state, it has no fault response and does not shut down its slaves.

    2. I have verified on EVM that, when a rail is in OFF state, it will still report OV fault.

    3. As I answered in another post, if it is incorrect to say the current measurement has 8-bit resolution. Actually, current measurement has 15.625mA resolution. If the 15.625mA resolution is sufficient for your application, configuring the MON pin as current measurement would be a solution.

    4. The current signal can go up to 4V, exceeding the voltage limit of UCD.

    5. (1) The EN signal doesn't go down to 0V, but 2.4V, and it goes back to 3.1V after 400us. In the project file, there is no re-sequence configured; so if the EN is indeed de-asserted, it should stay low. Therefore, I suspect the UCD did not actually turn off Rail 2. The problem is elsewhere.
    (2) Rail 7 has all other rails as slaves. All rails should be turned off if Rail7 OV fault response is triggered. Does it agree with the observation?
  • 1. I have not seen this behavior.

    2. I have seen this behavior.

    3. 15.625 mA is not sufficient for our needs. We designed for and expected to get 1mA resolution (what we should have gotten with a 12 bit ADC that the data sheet mentioned). When we did not get this we had to do a work around.

    4. There is a voltage divider on the input to the UCD90120A that divides the voltage by 2. The signal displayed is before this voltage divider.

    5. The EN signal is measured on an LED (easiest thing to get a probe on). This signal is the same signal that enables my voltage regulator, buffered through a transistor, and therefore inverted. It does not go all the way low because the probe point is between the LED and the current limiting resistor. Yes the intent of the design is that if there is a fault or Rail7, all other rails should be turned off. But I would expect the glitch filter to prevent a fault or Rail 7 since the over current event is much shorter than the 0.8 msec filter setting. I would also expect rail 2 to not shut down if rail 7 is not enabled. I don't see this.
    I know it is rail 7 that is causing rail 2 to shut down regardless of whether it is enabled or not because if I set the OV limit high enough on rail 7 (above the peak), rail 2 does not shut down.

    It is beginning to look like the only possible work around is to set the OV limit on rail 7 very high before turning on rail 2, then dropping it down to the correct value once the capacitor charging surge is complete.
  • I forgot to mention that there is a DC offset added to the current signal to allow us to measure slightly negative currents. Since the voltage result can't represent negative values, the DC offset is handled by our software and not programmed into the UCD90120A.
    The DC offset is equivalent to 0.3417A
  • Based on source code and EVM test, I can confirm that when a rail is in OFF state, it has no fault response and does not shut down its slaves. If Rail 7 indeed turned off Rail 2, Rail 7 may have been turned on unexpectedly.

    Based on the project file, if Rail 7 turns off Rail 2, it should also turn off all other rails. Is this observed?

    Based on the project file, if Rail 7 turns off Rail 2, it should stay off. But the waveform shows the EN pin is back on after 400us.

    I suspect the project file doesn't match the configuration in the device.
  • Since I am probing on an LED that is driven by a transistor, the signal you see on the scope is inverted. You are seeing rail 2 being turned on, and then very shortly later turning itself off.

    In these examples I was using the fusion software to control the "Operation" bit of rail 2 and rail 7 manually.

    Lets confirm that we agree on what the "off" state is for this. I think the off state is when I have the "Immediate Off (No Sequencing)" selected on the monitor page.

    Yes, when rail 7 turns off rail 2, all other rails are turned off as well. (the state of their "Operation" bits do not change, but the outputs do shut off until the fault is cleared. Clearing the fault instantly re-enables the outputs, and the other rails turn back on.
  • If the rail's on_off_config is set to "operation only", setting OPERATION to immediate off should turn off the rail.

    How do you clear the fault? If clear fault by clicking the "Clear Fault" button in Fusion GUI, the rails would keep off. "Clear Fault" merely clear the status bits and does not affect on/off status. You must toggle CONTROL pin and/or OPERATION to turn the rails back on. I have verified this on EVM.
  • Are we using the same IC? are there multiple firmware versions for this IC.

    Yes I am using the clear faults button on the monitor page. I just re-ran the experiment, The fault that turns off the supplies does not change the state of the operation bit, and clicking the clear faults button causes all power supplies that were on before to turn back on.

    I have re verified that the behavior is not affected by the operation state of rail 7, on, immediate off, or soft off.  regardless of the state of this setting, the OV fault occurs, and all power supplies are turned off, but the state of their operation bit does not change.

    I just noticed that the current rails ON/Off Config were set to 0x18, I changed them to 0x1F to match the control rails and saw no difference.


    I just realized what is going on. I actually have 8 rails (two identical copies of this IC) that I want to have shut down on a fault. I have logic to generate an output on OV fault that drives external logic to drive PMBUS_CNTRL of both ICs when a fault is detected. Since the OV Fault flag is set when the rail is off or on, and the glitch filter is ignored for the setting of this flag, the external logic is getting triggered to turn off PMBUS_CNTRL shutting everything off.

    I need to go away and think this through.

  • The external logic is using VOUT_OV_FAULT_LATCH. Is there an alternative that is equivalent to what the rail uses? (glitch filter applied, disabled when rail disabled).
  • No. Glitch filter is only associated with fault response.

    You can remove the external switch and use UCD's built in function to re sequence the rails when a fault occurs. Glitch filter will be applied in this case.

  • The problem is that I can not base logic on the actual fault conditions, so I can't shut down the rails on a second UCD90120A when the first detects a problem.
  • I see. You may consider adding a low pass filter to the sensed current signal.
  • Is there a way to read out the raw A/D values? If I could do that, I could go back to defining the current measurement rails as current. We only need the 12 bits of resolution for displaying the values, we can live with 8 bits of resolution for current limits.

  • There is no PMBus command to read raw ADC data.

    If you have a spare MON pin, the two UCDs can be cascaded by connecting one's Logic GPO to the other's MON pin. This way, you can remove the external switch.
  • Dear Mr. Douglas,
    Plz help.

    Purpose of discussion is to program UCD90120A, thats
    mounted on ZC706 Board:

    (1)
    USB-GPIO firmware 1.0.14 works, i understand no other
    firmware version works for above board, comment on
    this
    If 1.0.13 is used then error voltage "Rail #1 does not
    get powered up (thereby shutting all remaining 4 voltage
    rails on the board).

    (2)
    On the above hardware with the same setup, USB-GPIO
    firmware 1.0.14 is used asserts Enable signals Rail #1
    & Rail #2, so Rail #1 powers up to 1V but Rail #2 does
    not power up & remaining 3 power rails are in shutdown
    mode.

    Regards
    Kamlesh.