• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 430 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS65218D0: PGOOD goes low for 1us

Muriel Pauli
Prodigy 80 points
Part Number: TPS65218D0
Other Parts Discussed in Thread: TPS65218, , TIDA-00606

Hello,

I'm using the TPS65218D0 to power a Cyclone V FPGA. The PGOOD output pin is connected to the nConfig Pin of the FPGA, to trigger a reconfiguration of the FPGA when the power is out-of-bounds. The TPS65218 is not reprogrammed using I2C, all the settings are as per default, meaning that also STRICT=1.

Unfortunately, when trying to configure a "larger" image onto the FPGA, one that using a decent amout of logic and I/O, a 400ms cycle of reconfigurations happen. The reason for this, that every time a new configuration tries to start, the PGOOD goes low for a duration of amout 1us.

In the screenshot below, the yellow is the PGOOD signal, DC-coupled. The red signal is the output of the DCDC1, AC-coupled without a limitation of bandwidth.

With measurements, I am not able to detect any change in voltage that should trigger the PGOOD signal, on either of the rails. The DCDC1 to DCDC3 have noise up to 20mV, DCDC4 has up to 40mV, which at a voltage of 3.3V should not be a problem, either.

And what confuses me too, how can it even be that the PGOOD is low for only 1us? Shouldn't the deglitch of the monitoring prevent this?

When starting the reconfiguration of a smaller image, or when using the DEV_CLRN pin of the FPGA instead of the nConfig, the system works without a problem.

  • 0
    TI__Mastermind 30310 points

    The images you tried to insert did not come through.

    Can you try to re-insert them using the "Insert/Edit Media" button, which looks like a Polaroid photo with a '+' sign in the bottom right corner?

    If that doesn't work, you can Zip them up and click the "Attach" button, which is the familiar paperclip icon. 

    Did you follow the power tree in the TIDA-00606 design? This power tree shows that VCC_AUX and many other rails require 2.5V from DCDC3. The default output voltage of DCDC3 is set by the DC34_SEL pin as shown in Table 5-2. Power-Up Default Values of DCDC3 and DCDC4 in the TPS65218D0 datasheet. When DC34_SEL is shorted to GND, the voltage is loaded from Register 0x18 (DCDC3) which is backed by EEPROM memory. The default voltage is 1.2V, and the other options (1.35V, 1.5V, 1.8V, 3.3V) are all DDR voltages or I/O voltages, but none of them are 2.5V

    I'm also a little concerned that the power sequencing requirements of the Cyclone V FPGA are different than the default settings of the TPS65218D0 PMIC. Ideally, you would re-program the PMIC before it is used to power the FPGA, and when you re-program the EEPROM memory you should also set STRICT = 0b in CONFIG1 (register address 0x13).

  • 0 in reply to Brian Berner
    Prodigy 80 points

    Hi Brian,

    Ah, sorry, I didn't notice.

    The schematics are the following:

    Yes, the generation of the 2.5V is not exactly according to textbook, but we experienced no problems in another, finished project with this setup.

    The waveform I wanted to add is:

    In the screenshot below, the yellow is the PGOOD signal, DC-coupled. The red signal is the output of the DCDC1, AC-coupled without a limitation of bandwidth.

  • 0 in reply to Muriel Pauli
    TI__Mastermind 30310 points

    You are correct: PGOOD is an output that will only go low when there is a fault, which would result in every rail sequencing down, and then every rail would sequence up again (i.e. the PMIC would initiate a system reset). PGOOD would be low for >>1ms, most likely for >70ms based on the default sequence timing (10 strobes *

    Based on what I see in this scope shot, there is no fault on DCDC1. And it is very improbably that PGOOD would be driven low by the TPS65218D0 for <1ms, and certainly not for only 1-2us. 

    Unfortunately for you, in my opinion the next step for debugging points away from the PMIC:

    • Where are you measuring the PGOOD signal?
      • PGOOD pin = PGOOD_MAN net =  R1049//R1060, plus R1040 series resistor Side A
      • PGOOD net = Side B of R1040 resistor, connected to pin 3 of V1002
    • What else is PGOOD (PGOOD_MAN, COB_RESET_N, and PGOOD nets on schematic) connected to? The entire circuit shown is not shown in the screen shots you provided 
    • Is the nConfig pin on the FPGA a configurable GPIO, or is it implemented in hardware only?
    • What is the definition of the nConfig pin? What voltage domain is it connected to? What is the Reset state (pulled low, pulled high, Hi-Z)?

    To me, it looks like the V1002 FET is pulling it low, not the PGOOD pin of the TPS65218D0. Maybe this transistor is being enabled by the Schmitt Trigger inverter due to a glitch on the COB_RESET_N line. The PWR_EN pin on the TPS65218D0 would filter out the glitch, but the Schmitt Trigger might respond and drive the FET, pulling down hard on the PGOOD signal for a short period of time.

    This is where I would look, because your analysis is accurate and the data you shared verifies that there is no fault on the PMIC.

  • 0 in reply to Brian Berner
    TI__Mastermind 30310 points

    Just out of curiosity, why do you need to invert the COB_RESET_N signal twice? Why not just connect it directly to PGOOD? If both signals are open-drain, they can be connected together with a wire-AND connection (i.e. sharing a pull-up resistor.

    It seems odd that there are 2 pull-up resistors in parallel for PGOOD_MAN (R1049//R1060 = 10k//10k = 5k) and the double-inverting of the COB_RESET_N signal.

  • 0 in reply to Brian Berner
    Prodigy 80 points

    Hi Brian,

    Thanks for your fast answer. I did some more debugging today.

    Actually, I removed the V1002 very early in the debugging to be sure that this was not the cause. And by adding a filter in PGOOD, it was obvious that the pull-down is coming from the TPS65218D0.

    This schematics is a second version of the board, so I soldered the differences onto an already existing version 1 board by hand. This includes the AND between PGOOD and COB_RESET_N. The board is around two years old, and still has the TPS65128 without D0 on it.

    What solved the problem now was just using another board, there it works like a charm. It seems like the Power Manager got broken at one point, either already before the soldering or now while doing the change.

    To satisfy your curiosity: The COB_RESET_N and the PGOOD from the Power Manager have to be completely independent for safety reasons, so one may to influence the other ever in such a way that the signal stays high wrongly. And the COB_RESET_N is not an open-drain, but a push-pull, so with the double invertion, it is easier to argument why they don't influence each other.

    Thanks for the 2 pull-up resistors, I didn't see it, I'll definitively remove one of them.

  • 0 in reply to Muriel Pauli
    TI__Mastermind 30310 points

    Muriel,

    Thanks for the update. Good to hear you got it working :-)