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.

TPS65185: Startup Issues with VN regulator

Part Number: TPS65185

Hello,

I'm having some troubles with the TPS65185 starting up. I'm using a typical startup sequence: Wakeup pin high, Program part via I2C, then set powerup pin high and write the enable register. 

Upon doing this, occasionally the part starts right up and works at the proper voltage, but most of the time it's stuck with the VN undervolt flag (register 0x08 = 0x20). I can see the VN trying to switch for some 150ms, but the output languishes around -5V before giving up. Interestingly, it seems to work more consistently if the input supply voltage to the part is lower, especially below ~3.45V. Also, regardless of the input supply voltage the part never fully starts up if a load (E ink display) is connected. Eventually the board will be powered by battery but for now it's being powered by a bench supply. My issue looks very similar to another one posted on this forum, except theire was found to be an issue with setting the powerup pin. I'm certain I'm doing this correctly.

Any ideas? Schematic is attached, although I've checked and double checked it against the EVM.

Thanks!

  • Hi,

    To clarify this issue: are you reading a VN_UV flag or a VNEG_UV flag from register 0x08? You mention that it's a VN_UV flag, but the value 0x02 corresponds to a VNEG_UV flag.  

    The reason I would like to clarify is because each rail on the TPS65185 has a 50-ms power-good time-out. A VNEG_UV flag is set if the VNEG fails to power up within the 50-ms window. The window starts once the regulator is enabled. 

    Since the enable for LDO2 (VNEG) is gated by the two DCDC converters, they should both be properly regulating, and VN should measure -16 V while VB should measure 16 V. If this applies to your case, similar behavior has been discussed previously in this thread:

    https://e2e.ti.com/support/power-management/f/196/t/692064?tisearch=e2e-sitesearch&keymatch=tps65185

    Due to the internal soft start feature on each rail, the device must startup into a small load to ensure each output capacitor charges to the desired output voltage within the 50-ms time-out window. Once all rails are properly regulating, a larger load like the E ink display can be applied. Another point to keep in mind is that, for switching converters operating with a fixed output power, decreasing the input voltage results in a larger input current. This can be seen by the difference in inrush current in Figure 5 and Figure 6 of the datasheet:

    For further investigation, please provide a scope shot of the startup including the VIN, VN, VB, and VNEG rails to provide a visual of the different timings on each rail. If you can also provide additional rails or even current waveforms, that would provide even more insight. 

    Thanks,

    Gerard

  • Thanks for the help with this! It's been a frustrating one to debug. Sorry, I keep getting VN and VNEG mixed up. They should really come up with more dissimilar names. It is indeed the VN regulator (I've updated the above post). Register 0x08 reads 0x20, meaning VN is in undervolt. Here's a snapshot of all the registers:

    Reg 0: 0
    Reg 1: 20
    Reg 2: 3
    Reg 3: 96
    Reg 4: 0
    Reg 5: 0
    Reg 6: 0
    Reg 7: 0
    Reg 8: 20
    Reg 9: E4
    Reg A: 0
    Reg B: 1B
    Reg C: 0
    Reg D: 20
    Reg E: 78
    Reg F: 0
    Reg 10: 65

    Reg 1 alternates between 20 and A0 as the microcontroller repeatedly tries to re-enable the rails.The VN rail sits at some -4V, which clearly is what's triggering the undervolt flag. A scope shot of the output rails doesn't tell much as they're all stuck at zero, but here's VN and VN_SW at startup:

    VN_SW (yellow) tries to switch for about 150ms while VN (blue) converges on ~-4V. After 150ms, VN_SW gives up. Some 200ms later the microcontroller tries to start it back up again, but to no avail. It seems like almost a voltage reference problem, but the reference looks good.

    Does the the VN regulator require the downstream regulators to have loads?

  • Hi,

    Thanks for also providing the register data. VN does not require loads on the downstream regulators. Even if you were to enable them by writing to register 0x01, VN will experience a very light load during most of its output voltage ramp because the downstream regulators are all directly or indirectly enabled by VN's power good status. 

    During the first period of switching cycles, the VN_SW node unexpectedly seems to clamp at -5 V after about 50 ms. The subsequent periods look almost symmetrical in that VNSW is always switching between +/- 5 V. 

    1. Assuming the bench supply is set to 5 V above, what do VNSW and VN look like for a 3.7 V input? 
    2. Can you also provide a zoomed in capture (around 5 us timescale) of the first period of switching cycles for both 5 V and 3.7 V input? 
    3. Is this behavior reproducible on multiple units?

    Thanks,

    Gerard 

  • Hello,

    Yes good point about the enables. It's not even getting to the point where the downstream enables are enabled. 

    Regarding VN_SW clamping at -5V, that was actually with a 3.7V supply. It's also not a "hard clamp", it floats around by a few hundred mV. A second unit shows identical behavior but at ~-7V.

    Looking at a zoomed in capture of VN_SW at startup, I think I may have found the issue. It seems to oscillate at around 5MHz:

    This is reproducible between units, with a slightly varying frequency. The signs all seem to point to feedback stability issues. How embarrassing if true. Changing the input voltage would change loop dynamics, which could throw it in or out of stability. Same with a varying load. Looking at my layout, I perhaps could have been a bit tidier with the VN_SW node:

    not only is there a fair amount of inductance in the loop, but I also chose to decouple the feedback node (pin 26) through a via. Now onto validating that this is the case, which I haven't come up with a way to do so yet. And attempting to resolve it without respinning the board. Perhaps a feed forward capacitor between pin 24 and 26? What do you think?

  • Hi,

    I agree, consistent, reproducible oscillation on the switch node does point to a stability issue due to PCB parasitics. The main cause for concern based on the layout snippet above is placing the device and output capacitor(s) on opposite sides of the board - the Layout Guidelines in the datasheet state that they must be placed at pin:

    A capacitor across the power FET or rectifier diode is an option to avoid redoing the layout. A series resistor could also be added to further improve stability at the expense of additional power dissipation. John Betten has an article on EE Times describing how to calculate these snubber components here:

    https://www.eetimes.com/author.asp?section_id=36&doc_id=1329490#

    If you have access to 100 pF or 220 pF capacitors this could be a relatively quick experiment to confirm whether this is a viable solution. 

    Thanks,

    Gerard 

  • Hi,

    As it has been several weeks without a reply, I will assume this issue has been resolved and will be closing this thread. If you have any additional questions, please feel free to post at any time. 

    Thanks,

    Gerard