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.

TPS65916: LDO1 Fails to stay on and persist in limit cycle

Part Number: TPS65916
Other Parts Discussed in Thread: AM5718, AM5718-HIREL

Hi,

We're using the TPS659162 to power a AMX5718 processor on a custom board. During the initial bring up of this design we've run into an issue whereby LDO1 comes up last in the sequence as one might expect, but then turns off after about 800us-900us. The LDO1 voltage then drops linearly to 0.8V. About 1ms later RESET_OUT asserts low and then this cycle repeats with LDO1 turning back on and off every ~8ms or so. This can be seen In the scope captures below where CH2 is the output of LDO1 and CH3 is RESET_OUT. Note:the second capture just has the horizontal axis zoomed in and the last capture increased the vertical axis to get a better measurement of the voltage out of the regulator.

We were speculating that perhaps the LDO's short circuit protection was tripping causing it to be disabled after the processor came out of reset. However there's nothing else that really loads this net beside the VDDSHV8 domain in our design, so this seems unlikely unless something is out of spec. We're considering modifying the board to make a current measurement to rule it out anyway. Any possible suggestions or explanations for why the voltage would turn off like this would be helpful.

Thanks,

John

  • John,

    I have assigned this question to the experts on the TPS65916 device. I would expect that you receive a reply by the end of the day (US Central time).

  • John,

    Can you confirm what you are doing on the PWRON pin? If the PWRON pin is held low for 8ms, the device will start to turn off. Can you also verify if only LDO1 turns off, or all rails?

    Thanks,

    Nastasha

  • Hi Natasha,


    Thanks for your response. To answer your questions.

    1. The PMIC PWRON pin is held high the entire time. See attached screenshot.

    2. No other rail is turning off. I'll attach a screenshot showing LDO4 is constant during this time. I believe this is the next rail that would transition during OFF2ACT or ACT2OFF sequence.

    These measurements also confirmed that the LDO1 current is no where near the short circuit protection threshold.

    One thing we've noticed is that nRESWARM (RSTOUT on AMX5718) is being driven low immediately after the RESET_OUT (POR on AMX5718). See below. Is that a normal behavior? Also is there a way to add another engineer/colleague to this discussion? I may be out the next few days and want to provide him a means to participate in the discussion, while I'm away.

    Thanks,

    John 

  • John,

    Your colleague can use the URL for this thread and reply as needed and I think they should also be able to watch the thread to be alerted of updates.

    It is not normal for RESET of the processor to be set immediately after POR is released. I am looping in the AM57x team to look into this.

    I agree that it doesn't look like LDO1 is hitting current limit. Can you also verify it has at least 1uF cap on the output?

    Thanks,

    Nastasha

  • Hi Natasha,

    Thanks for the tip about the URL and for looping the AM57x team in. FYI, my colleague's name is Quint in case you hear from him.

    To answer your question, LDO1 has a local 2.2uF (10V, X7R, 0603) capacitor. Even with the voltage coefficient there should still be >1uF of capacitance local to that regulator. On the same net there is an additional 4.7uF (25V, X7R, 0805) capacitor, but located further away near an SD Card Connector (not in use). That's it for bulk capacitance. For high frequency decoupling, there are a couple of 0.1uF's here and there, e.g. at the AM5718 VDDSHV8 pins. Let us know if you think of anything else to check.

    Thanks,

    John

  • Regarding TPS65916 RESET_IN connected to GPIO_1.  From datasheet and the users guide it appears to have the following characteristics:

    1.  Default input

    2.  Internal Pull Down Selected nominally 400Kohms

    3.  I could not determine the polarity

    4.  AM5718 default state is Hi-Z (our design pulls this signal up to 3.3 Volts with 10Kohm Resistor)

    I would like to understand the expected behavior of RSTOUTn from AM5718 and if this signal should be pulled down and not up.

    The AM571X_INDUSTRIAL reference schematic has a series 18.2K resistor and 20.5K pulldown but uses a different PMIC.

  • Quint,

    I did reassign this post from the PMIC team to the AM572x team to get some further clarity on the RSTOUTn of the processor. We should hear back shortly. I am still looped into the discussion in case the issue is not related to the processor pin.

    Also, based on John's feedback, I think the output capacitance on the LDO is not an issue.

    Thanks,

    Nastasha

  • Nastasha,

    I depopulated the 10K pullup on the RSTOUTn signal from the processor.  The power on reset signal from PMIC and LDO are no longer cycling.

    RSTOUTn stays low, and I still need to really understand what the expected behavior is.  We previously were unable to pass the integrity check when connecting with a JTAG debugging pod.  The integrity check passes now.  However, the icepick route controller does not show up.  I am told that should show up after a reset.

    I am wondering if something is causing a warm reset that is persistent.  So, by removing the pullup I have only enabled the PMIC to fully power on, but not solved the underlying issue.

    Quint

  • We are still looking for a response with respect to why RSTOUTn signal asserts when the PORz signal (RESET_OUT) from the PMIC is asserted.  This happens within a few nanoseconds.  I looked to see if any of the boot devices ever get accessed.  There are no transitions on the clock line or CMD/Chip Selects of the FLASH devices.  The SYSBOOT options were rechecked and match with the exception of the XIP bus width being 16 instead of 8 bits.

    The clock frequency selection was double checked along with the presence of the 20MHz clock input to the processor.

    As noted above, we cannot connect with JTAG.  If I remove the pullup resistor so RSTOUTn cannont cause a warm reset to the PMIC we can pass the JTAG Integrity checks.  Otherwise, the JTAG interface completely fails.  I am not sure why the device reset would affect the ability of JTAG to at least connect and allow the programming of connected FLASH devices.

    Quint

  • Nastasha,

    I have some additional information regarding the reset cycle shown at the beginning of this post.  I performed a careful check of the power on sequence against figure 5-2 Power-Up Sequencing in the AM5718-HIREL datasheet.  We use REGENABLE1 connected to GPIO_0 from the PMIC TPS659162 to enable 3.3Volts for the board and also the output of the 20MHz Oscillator to the processor.  According to Figure 5-2 the Oscillator should be enabled after VDDSHV8 from PMIC LDO1_OUT is stable.  There is also a requirement for the Oscillator to be stable 366us prior to the release of RESET_OUT connected to PORz of the processor.

    We meet the requirement of 366uS, but as I stated we are enabled prior to VDDSHV8 because the 3.3V supply is enabled prior to VDDSHV8.  It is also still not clear the behavior of RSTOUTn.  The figure indicates that it will be asserted a minimum 2ms after RESETN which I understand to be an optional soft reset.  We have a button reset through a reset monitor which drives this signal for ~200ms.  I removed the device so that this signal would always be high as it is powered from the switched 3.3volts.  It also is driven low far longer than when PORz is release.  This did not alter or change the issue.

    In the power on sequence figure 5-2 it would appear that RSTOUTn will be low for some time after PORz (cold reset) is released.  Since the processor does not drive this signal it is high, but then goes low and since we end up in a perpetual loop we never see it released.  So, we are still asking for clarification of the exact behavior we should expect.

    The last thing is, would the oscillator being present prior to the last supply coming up cause this reset cycle issue?

  • Quint,

    The SoC rstoutn signal will be asserted as an indication that the SoC is undergoing any form of reset, including resetn or porz assertion or for any internal warm reset assertion.  

    Also, it is required that the oscillator input to the SoC be active and clocking prior to the deassertion of porz.

    Regards,

    Kyle

  • Kyle,

    Can you look back at our post.  I have added quite a bit of new information and other questions.  The above does not address the questions regarding why we see resetn driven low when PORz is released unless this reset is supposed to be extended for some reason.  It is Hi-Z during reset so starts in the High State.  When I artificially prevent resetn from reseting the PMIC the reset cycle is broken.  This would seem to indicate that resetn would not be asserted as soon as the PMIC deasserts the RESET_OUT (PORz).

    I have posted a scope capture this morning with regard to the clock and reset.  In some earlier posts you can see how resetn asserts when PORz goes high.

    We have additional questions with respect to the JTAG not working.

    Quint

  • Quint,

    Sorry I still don't have the full understanding of the scenario.  Did you follow a particular reference design from TI for your design?  

    Can you summarize (either waveform or diagram) the timing relationship between the SoC signals porz (input), resetn (input), and rstoutn (output)?  

    What boot mode are you using?  Can you double confirm there is no SDCard in the sd card connector?

    Can you probe the I2C interface between the SoC and the PMIC?  Maybe software on the SoC is telling the PMIC to modify the voltage level for some reason. If the I2C bus wiggles right around the time of the voltage change that may help direct the next debug steps.

    Per this statement:  The above does not address the questions regarding why we see resetn driven low when PORz is released unless this reset is supposed to be extended for some reason.   The SoC's rstoutn will assert when porz/resetn inputs are asserted and rstoutn will remain asserted for additional time while the internal reset signal is propagating through scan chains of the SoC. 

    Please continue to describe the problem using this type of notation : RESET_OUT (PORz) using both the PMIC (SoC) signal naming in order to avoid confusion.

    Thanks,

    Kyle

  • Quint,  I think it's clear in the waveforms but just to double check.  What are the voltage levels before and after the ramp-down?

    Thanks,

    Kyle

  • Kyle,

    PORz is pulled to 3.3Volts through a 10K resistor.  This 3.3Volts is switched by REGENABLE1

    RSTOUTn from the processor to the PMIC GPIO_1 is also pulled up through a 10K resistor to 3.3V switched by REGENABLE1.  The PMIC indicates this pin is a Fail-Safe 5.25Volt tollerant pin.

    The 20MHz oscillator is powered from 1.8Volts and its output is switched on by REGENABLE1

    VDDSHV8 when switched on goes to 3.3Volts (our 3.3Volts runs just under 3.4 volts).  After PORz is deasserted by the PMIC with a short delay it starts to ramp down to a level of ~0.8Volts.  The average DC level is 1.28Volts.  We isolated that net and determined the current draw to be about 30mA.  This is the load presented by the processor.

    Quint

  • Kyle,

    With some further exploration I can see the following sequence:

    1.  3.3 Volts is applied when enabled by REGENABLE1; this also enables the Oscillator

    2.  3.3 Volts enables the I/O of the PMIC and you can see PMIC RESET_OUT actively driven low and Processor RSTOUTn actively driven low; previously Hi-Z.

    3.  PMIC_RESET_OUT is driven High and RSTOUTn stays low.

    4. DEVKIT does not have a pullup on RSTOUTn, so if we remove the pullup we get the above behavior.  With a pullup then we get the Recycled Reset issue.

     I cannot find a reason for RSTOUTn being persistently asserted.  In the Devkit it is released 2ms after RESET_OUT is deasserted.  Our design is consistent with the Devkit design.  We have double checked pinouts against datasheet and Devkit schematic.  We have the same sysboot settings with the exception of the GPMC XIP Bus Width is 16bits and not 8bits as in the Devkit.

    The processor is perpetually stuck in reset.  As a consequence we cannot access the ICEPick for JTAG access.  I have verified that RESETn input to the processor is pulled high.

    What reasons have you seen before to cause RSTOUTn to be always driven low.

  • Quint,

    Sorry for not fully following. 

    It sounds like porz is being deserted before the clock is stable is that correct?  Please refer to the Supply Sequencing diagram in the data manual.

    porz should be deserted as the final step in the power-up sequence:

    (11) porz must remain asserted low until all of the following conditions are met:

    • –  All device supply rails reach stable operational levels.

    • –  xi_osc0 is stable and at a valid frequency.

    • –  Minimum of 12P after both of the above conditions are met, where P = 1 / (SYS_CLK1/610), units in ns.

      resetn must be high prior to, or rise simultaneous with, porz but not before its power supply, vddshv3, rising.

    Regards,

    Kyle