• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 63 subscribers
  • Views 1126 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.

TPS65217 - power up by tying PWR_EN to PB_IN with AM3356

David Bailey
Prodigy 35 points
Other Parts Discussed in Thread: AM3356, TPS65217

PROBLEM

I'm running an AM3356 ARM with TPS65217A PMIC connected for power and startup signals in our preproduction prototypes.  The PMIC would  not start up.

3.8V was applied to the PMIC, a 1 sec. PB signal was generated to the  PB input to the PMIC, and the only output from the PMIC was the 1.8V VRTC LDO for 5 seconds.  No 1.8V, 3.3V, or 1.1V was seen from the 3 switching regulators.  The PMIC_POWER_EN (w/VRTC pullup) from AM3356 never went high.

The PMIC finally started working when a “kludge” work around was applied. 

DESCRIPTION OF CIRCUITRY

  • TPS65217A is run as a 5-V Only Operation with power supplied through BAT PIN (AC and USB pins grounded).
  • 3.8V applied as Vin to BAT PIN, VIN_DCDCx, and VINLDO pins.

 NOTE:

  • AM3356 CAP_VDD_RTC pin mistakenly connected to VDD_CORE pwr supply instead of 1uF cap to VSS
  • AM3356 RTC_KALDO_ENn pin mistakenly connected to  VRTC instead of VSS

 

THE "KLUDGE FIX"

Was able to get working by disconnecting PWR_EN on TPS65217 from AM3356 PMIC_POWER_EN and connecting TPS65217 PWR_EN to PB_IN.

PWR_EN follows PB_IN so both PMIC pins are high when power is applied, and both go low when the PB signal goes low.  

PWR_EN is low before the 50mS debounce time for PB_IN expires, so by the time the TPS65217A recognizes PB_IN is low, PWR_EN is seen as low.

Then PWR_EN is seen going high when PB_IN signal goes high 1 second later, starting PMIC VDCDCx outputs.

 

 QUESTION

  • Our product operation is simple.
  • We come on and run at full power (no sleep mode or low power mode). 
  • We use the real time clock for time and date for the Linux system, but don’t back the clock up with a battery.  The RTC is needed just for Linux for some applications to know the date (a server resets the time if powe ris cycled)
  • We turn off power by unplugging the board - no special power down.

 

Is this kludge fix OK as far as the AM3356 powering up in the correct sequence and being initialize alright or do I need to go back and correct the CAP_VDD_RTC and RTC_LAKDO_ENn connections on the AM3356?

 

Will this fix impede the operation of the Real Time Clock?

 

The fix lets us go ahead with software and FPGA development, but I don't want surprises right before product release.

 

  • 0
    TI__Expert 3740 points
    David,

    I don't think this "Kludge" fix is okay, the PWR_EN is the signal needed to let the PMIC know everything is okay for it to start up. From what you are describing it sounds like there could be something schematically wrong, have you checked your schematic against the collateral online: www.ti.com/.../slvu551. Would it be possible for you to send your schematic so I can check. I would check with the Sitara team as well to make sure everything is hook up correctly. If everything came up for 5 seconds that leads me to believe the PMIC is fine, but not getting the signal it needs from the AM3356. Have you experienced any other issues with this fix you implemented?

    Janice
  • 0 in reply to Janice Escobar
    Prodigy 35 points

    Janice

     

    I have made a PDF of 4 sheets of my schematic that pertain to this issue (it’s a 20 sheet schematic overall)

    But I need to know how to send it to you and the other TI Engineers instead of posting it, as my manager would not want me to post a company document on a community board such as this one.  Let me know how we would work that one and I will send it as soon as I hear from you.

    Besides that,...

     

    As I stated in my original posting, I think I incorrectly wired two pins on the AM3356 ARM processor.

    Reference sheet 4 of 20 of the attached PDF.  U46 is the AM3356 processor.

    • Processor pin CAP_VDD_RTC is connected to the VDD_CORE pwr supply instead of just a 1uF cap to VSS
    • Processor pin RTC_KALDO_ENn is connected to PMIC power output VRTC instead of VSS. 

    I was under great time constraints at the time and misunderstood the two RTC modes in the AM335X schematic checklist on the TI wiki. 

    The connections of these two pins may be where the AM3356 is not generating the PMC_PWR_EN signal back to the TPS65217A.

    When powering up, the PMIC will generate the 1.8V VRTC output for 5 seconds, but the AM3356 never drives PMC_PWR_EN high, thus NONE of the other power supply outputs from the TPS65217A become active. 

     

     HOWEVER,

    If you look at all 4 pages of the selective schematic printout I attached, the control connections between the AM3356 and the TPS65217A are correct (yes, I read the slvu551 a lot before releasing the board for layout).

     

    And I must correct one of your statements. You said "If everything came up for 5 seconds that leads me to believe the PMIC is fine"

    From my original post I stated that the only output I got from the PMIC when power was applied (Before the Fix) was the 1.8V VRTC LDO for 5 seconds. 

    NONE of the other PMIC outputs ever became active.  And this was due to the PMC_PWR_EN from the AM3356 never going active.

     

    I could only get the other TPS65217 outputs to become after we instituted the FIX:

    • We disconnected the AM3356 PMC_PWR_EN from the TPS65217A by removing R110 (sheet 2 of 20 of the attached schematic),
    • We then jumpered the PWR_EN input of the TPS65217A to the PB_IN (pushbutton input) pin on the PMIC chip by running a short wire from the PMIC side of R110 pads to TP81 (PB_IN on sheet 5 of 20 of the schematic).

     After doing this FIX, we have not had the TPS65217 on any of our 8 boards fail to power up on any PMIC outputs each time we apply 3.8V to input power.

     And we are successfully running LINUX on the AM3356 and loading a XILINX FPGA from the processor. 

    (We had to go on with our development while we waited for a reply)

     

    So we still have our question as to what problems this FIX could give us.

     

    NOTE

    Our pushbutton circuit on sheet 5 of 20 on the schematic provides a PB_IN signal that goes low about 700mS after input power to the PMIC is stable, then returns high about 800mS after going low (stays high for 700mS after input power high, then pulses low for 800mS)

     

    So going by slvu551, I don’t see at this time where there is a problem, as the PMIC will not see the PWR_EN input high until after PB_IN goes low,

    And

    PB_IN is debounced for about 50mS in the TPS6217A, so with PWR_EN and PB_IN tied together, PWR_EN looks low to the PMIC after PB_IN comes out of debounce setting the PMIC up to send /WAKEUP and wait for PWR_EN to go high

    So

    PWR_EN will go high 800mS after PB_IN goes low, telling the PMIC to start all the power supply outputs

    NOTE --- It’s the 800mS PB_IN low time that helps.

     

    But pass the above on with the schematic and the fix description, as I cannot respin a board in the near future,

    I would like to know what dangers this has, and I can’t get the PMIC to not power up

    I have verified timing for the various power supply outputs with respect to the PWR_EN going high, and with respect to the power supply outputs to the POWER GOOD signal, and they all meet the datasheet.

    FINALLY, again, if we left the two mis-connections I mentioned at the beginning of this long story, will it affect the use of the real time clock just so LINUX has a clock to use for validation of software usage? - we don't require battery backup, as the clock is fed from a remote server after power cycles or outages.

     

    David Bailey