UCD9090: Control Pin access through System reset functionality from GPO for Power down sequence

I did a quick test with the project file, the system reset is very clear when the 5V is in?

Did you see any glitch on the system reset pin when the 5V is in? If so,  is glitch still available if disconnected the system reset and control pin?

Is 5V very stable without big noise or ripple?

what're duration of the glitch pulse on the GPO signals?

Is GPIO16 stable during the whole power up?

Is a waveform available to show 5V, system reset, contro pin and one of the glitched GPO output?

Thanks

Yihe

Hi Yihe,

The system reset signal (which is driving the control pin in our case) is producing a glitch exactly at when the 5V is powered on.

Please refer the attached folders with waveform.

We captured all the enable output form UCD along with the 5V input and the respective power rail that the Enable pin activates. We can see the Glitch on all the Enable pins when the 5V is turned on.

Still we have to check for the captures after removing the System reset settings. Would you suggest to do it in the fusion tool? or in hardware itself do we need to cut the path?

Kindly review and give your input.

One more thing we observed in one of the boards, when we probe the control pin the board shuts down. This is happening in one of the boards. Other board is showing a High when probing, which is also the expected. Will there be any reason behind this? We are not having any pullup on the loop path. Hope it doesn't needed, as we are not configuring the System Reset GPO as open drain.Kindly give your view point on this.

Regards,

Felix.PowerSequ_Capture.zip

Hi

Does the 5V also power on the 3.3VS that powers on UCD?

What's the slew rate of the 5V? Could you change the slew rate of 5V to 4v/ms?

Could you help to capture the 5V, 3.3VS, BPCAP voltage with  one glitch GPIO?

You mentioned that this problem was not present at the previous design, what're the changes other than the loop of SYSTEM_RESET and CONTROL_PIN?

you can remove the R3753 to disconnect the SYSTEM_RESET and CONTROL_PIN?

Thanks

Yihe

Hi Yihe,

Here is our response

1. 3.3VS which is powering UCD is generated from 5V board in supply through a Linear circuit.

2. We are powering the board with 5V through the in-built power supply in the client product. Please refer the attached waveform for the ramp. 

3. We captured the 5V, 3.3VS & EN (gpo) glitch. 

4. Other than the loop, we connected the 3.3VD to the MON3 instead of MON11 and we connected 2.5VD on the MON4 instead of 2.5V rail. The "D" rails are delayed rails from the main supply like3.3v,2.5v & 1.8V

we dont have any other changes.

5. We removed the R3753 and powered the board, but we still saw the glitch on the GPOs

6. We were thinking that the 5V reaches monitoring pin early to the 3.3VS i.e, the UCD power itself. So we removed the 5V monitoring from the board and also from the UCD project file.

Even doing this also we saw the glitches on the GPO (enable) lines.

7. Instead of monitoring 5V, we monitored 3.3VS. Even then we found glitches on the GPO lines.

We are not sure which causes this glitch on the GPO lines.

8. BPCAP was ramping to 1.8V 

Kindly review the waveform and our inputs provided and help us to resolve this.

Regards,

Felix.CTRLPIN_5V_3-3VS_Capture.zip

Hi Yihe,

Thanks a lot for your inputs and direction.

1. We tried powering our board with an external lab power supply, which has good ramp. We were not seeing the glitches then.
Then we focused into our board to increase the ramping of the 5V & 3.3VS rails by removing the 47uf caps on the 5V to 3.3VS conversion circuit(kindly ref. the schematic snap shot on the previous posts). This helped to have the ramp of around 2.5v/ms. This time we were not seeing any cliches on EN Outputs. Still we could see Glitch on the PUP_RST_L and UCD_SYS_RST_L lines. Anyway we understood the major reason behind the glitch formation.

2. We checked the existing Proto1 for the glitches. Even they produced Glitches and somehow we missed out to notice before and also made no impact on the 1.8V & 2.5V regulator with false switching as like we are having in the Proto2.

3. I could see that these glitches may not be related with the control pin loop.

4. Related with the System reset (UCD_SYS_RST_L ) and Control Pin (PMBUS_CTRL_UCD) implementation, we need to get one more clarification. The system reset is generated based on a GPI signal state, which is driven from a CPLD. The requirement here is we need to do a power recycle when ever the software initiates a request through this CPLD line. Whenever that GPI driven Low to High, we generate a system reset toggle from High to Low and control pin is driven by this system reset and making the UCD to do the power recycle. CPLD is powered by 3.3V, so during the power recycle CPLD also shuts down. What we are seeing here is, when the control pin tracking the GPI, both are coming out on almost same pulse duration of around 500uSec. Here we are not giving time for the 1V rail going down as last as per power down sequence. 1V rails continuously existing. Here our need is to keep the control pin low for a sufficient duration (in terms of ms) so that we can allow the 1V rails properly shuts down. We tried by giving the "Pulse time" on the condition window with GPI tracking enabled but it is not working out. Kindly help us to implement a longer system reset pulse as per our requirement.

Regards,
Felix.

UCD9090 2.3.5.0 Address 101 Project File_02282017_UCDTest.xmlHi Yihe,

Thanks for your input. As per your suggestion, I kept a 50ms Release Delay Time under GPI Tracking. Now i could see a long control pin low which allows proper sequence on the power down. 1V goes low after the 3.3V & 3.3VD goes low. Power on sequence is also matching.

We have a power down sequence req, saying except 1V all other rails can go to zero first.

After some delay 1V (core voltage) has to see the zero. Apart from this, all the voltage rails should have been less than 0.4V level before the next On sequence starts.

This is the reason we kept 40ms, which is approximate value. Anyway we updated it to 20ms. So, on the 1V configuration, we have selected all the rails as seq off dependence.  Kindly confirm this implementation.

Please find attached the project file and snaps shots for your reference.

We implemented the fault response - Glitches, Restart both for OV(5 times), UV(1 time) & Max Fault Turn On(5 times)

Also, we would like to validate these response implementation.  

Could you please suggest a way or simulating environment to test this fault responses?

Regards,

Felix.