We’re seeing a problem with GPIO outputs on the UCD90160 power manager. We initially noticed the problem with GPIO2, which we’re using as the System-Reset to drive a low-going pulse to another device which uses this pulse to begin its power-up. The input on the downstream device is 5V, so we’re using an SN74LVC1G07 open drain buffer to translate from the 3.3V power manager to 5V logic, with a pullup resistor on each side of the buffer.
The UCD90160 datasheet states that the GPIOs (except the FPWM/GPIOs, which GPIO2 is not) are high-impedance during reset, and the UCD90160 stays in reset until Vdd (3.3V) reaches 2.4V. While the 3.3V rail is ramping up, we expect to see the voltage on GPIO2 follow the 3.3V rail since it’s pulled up, but we actually see a short glitch on GPIO2 where the pin appears to be driven low. The glitch begins when Vdd reaches ~0.7V and continues until Vdd reaches ~1.0V, after which GPIO2 follows the 3.3V rail again. This low pulse goes through the 1G07 and to the downstream device, which begins its power-up sooner than we want.
We’ve found similar glitches on other GPIO pins on this board and other boards. The downstream functions on the other pins are not as sensitive to the glitch as GPIO2, but we are still concerned about it. The glitch is not affected by the programming of the GPIO pins, and it occurs before the UCD90160 comes out of power-on reset. We would like to understand the root cause before choosing a workaround.
Alex, I can duplicate the glitches on the TI EVM and am requesting help from the design team to better understand the root cause. I have also been able to prove that the occurrence of the glitches are a function of the 3.3V slew rate. If I slow the slew rate to less than ~ 1V/ms then the glitch goes away. Keep in mind that in our datasheet, slew rate is specified as 0.25V/ms minimum between 2.3V and 2.9V, so I would not go any slower than 0.25V/ms.
This is only based on very limited data but may be an option for you. I will update as I receive more information.
Hi Eric,
The customer tried three different slew rates on the 3.3V rail and they have seen the glitch with each. As shown in the attached screenshots (I have sent you the waveforms in a separate email), they have used 0.08V/ms, 0.8V/ms and 2V/ms. 2V/ms seems to be the upper limit for their board.
Did TI mean that when they sped up the slew rate to faster than 1V/ms they saw the glitch go away? From what they have seen the glitch occurs while the 3.3V supply is in a certain window during ramp-up, so slowing the slew rate causes a longer glitch for them. They can’t go any faster than 2V/ms and they still have the glitch at that rate.
Thanks,Alex
I've attached the data I took last week but as I mentioned the data is very limited and is not meant to define a specification. Unfortunately, it appears that the behavior of the GPO cannot be determined prior to when the supply voltage reaches the Vreset voltage (2.4V max). Typical Vreset will range from 1.4V to 1.9V
TI will have to document this deficiency in an errata.
The customer ran similar tests with their TI EVM board. Even at 0.6V/ms the glitches are visible. Can you offer some sort of a workaround? Is there any kind of a master reset signal that can be generated by an external SVS (like TPS3809) that would keep all GPIO signals low or high until 3.3V supply reaches its level.
The text below is from the customer.
Here are screenshots from our UCD90120EVM. The slew rate is 3.3V/5.4ms = 0.6V/ms. There’s a low-going glitch on GPIO1, visible when the pullup is enabled, and a high-going glitch on GPIO2, most visible when the pulldown is enabled.
0383.UCD90120EVM.zip
The RESET pin doesn't seem to have an effect on the non-FPWM GPO glitches prior to POR (ie, a pulled high GPO will still glitch low prior to POR even if RESET, pin 9 is held low). The best workaround is to externally invert the required signal and use a pull down on the GPO. Alternatively, one of the FPWM GPO can be used. These only blip to ~ 0.7V when pulled up and then go low until the chip internal init is complete (~20ms).