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.

How to treat these dedicated input Pins(VPP,EXTINTn,EXT_WAKEUP) on AM3352?

Other Parts Discussed in Thread: AM3359, TPS65910, TPS54218, TPS65910A

1,VPP,Supply voltage range for the FUSE ROM domain.
I found "During functional operation,this pin is a no connect" on page 78 in "SPRS717D–OCTOBER 2011–REVISED MAY 2012".
But in "AM335X 15X15 ICE BOARD",I found this pin is connected to VDD2_SMPS,which is the power of VDD_CORE.

2,EXTINTn,External Interrupt to ARM Cortext A8 core
Since this pin is interrupt input, should I drive it high or low?or left it unconnected?
I found this unconnected in "AM335X 15X15 ICE BOARD" and was driven at other references.

3,EXT_WAKEUP,Dedicated Input Pin for External Wake Events
If we don't use external wake function,what should we do to this pin?

Since these pins are dedicated input pins,we cann't configure them as output GPIO.
So I think we should drive them to a fixed value.

  • Hi Simon,
     
    1. Vpp - do not connect.
    2. EXTINTn - check Errata Advisory 1.0.6. I think it's best to provide both pullup and pulldown and populate what's necessary according to AM335X revision. This interrupt is software maskable, but I do think it's better to tie it to a fixed level.
    3. EXT_WAKEUP - tie to GND.
     
    Best Regards
    Biser
  • Dear Biser,

    Thank you very much,your reply give me big help!

    Thanks and Regards
    simon

  • Hi Biser,

    I have an AM3359 processor design where the Vpp is connected to VDD_CORE because I've used the BoagleBone as reference. Is this somthing I should be worried about? What are the consequences of this error ?

    Best regards

    Reto 

  • Hi Reto,
     
    The VPP pin should be left unconnected. I don't know what BeagleBone schematics you are referring to. On the one I have (Rev. C2) VPP is NC. I can't say what the impact of this error can be, as this isn't documented anywhere. However this is the voltage supply for programming the processor e-fuses, so results can be unpredictable.
  • Hi Biser,

    thank you very much for your quick reply! That was really fast! On the cover page of the beaglebone schematic Rev. C2. you can see that they have removed the connection between VPP and VDD_CORE in Rev A5. Unfortunatly the schematic I've used was an older revision.

    However, I have the impression that the AM3359 processor on my prototype boards is getting a little bit hot (approx. 50°C) and I'm wondering whether this connection could be the reason for that. What do you think ?

    Best regards

    Reto

  • Hi Reto,
     
    50°C is not abnormal temperature, depends on what the processor is doing and the OPP (voltage/frequency). You could try stopping the system early in u-boot and check the temperarure after allowing some time for temp. settling.
  • Hi Biser,

    when I hold the processor in reset condition during power-up (WARMRSTn = low) the temperature is approx. 35°C. The ambient temperature is approx. 24°C

    Best regards

    Reto

  • Hmmm, not a temperature to worry about, but still seems a bit too warm. I'll ask the design team about this and let you know.
  • Hi Reto,
     
    Here is feedback from the design team:
     
    "The issue with connecting VPP to VDD is that there is a possibility of some current path between the supplies based on how this is shorted and during power up/down. However, with reference to the issue on the Forum, I don’t see connecting VPP – VDD being the root cause. WARM Reset does not really shut off all the clocks and some of the logic is still active during warm reset in addition to the supplies being stable. So, the power during warm reset would not be very low compared to a cold reset. Also, it would be important to understand where the temperature of the processor (35C) is being measured. If this is a board level measurement, are they sure there are other components on the system that are not active?"
     
     
  • Hi Biser,

    thank you for your reply. The design team is talking about "current path between the supplies during power up/down" Does this mean that the device can end up in a latch-up state?  Some of the AM3359 processors on my prototype boards seem to suffer from a latchup damage, they have an increased power consumption, are getting hotter and they have a significantly reduced input resistance at the VDDSHV6 power supply.

    Best regards

    Reto

  • The most common way to induce latch-up on a CMOS device is to apply a voltage potential that exceeds the specified input voltage.

    If you suspect latch-up on the VDDSHV6 power rail, you should verify all inputs powered by this supply are not exceeding the input limits of  -0.5V to (VDDSHV6 + 0.3)V.  You should also verify the transient voltage created by logic level changes do not exceed the Transient Overshoot and Undershoot limits of 25% of corresponding IO supply voltage for up to 30% of signal period.

    Keep in mind these limits must be meet even during power supply ramp up and down.  So external devices connected to VDDSHV IO terminals can not source voltage into these inputs that exceed the input limits of  -0.5V to (VDDSHV6 + 0.3)V.

    Regards,
    Paul

  • And some more comments have come in:
     
    "No. This is not a latch-up condition. The current path is possible if there is a voltage delta between VPP and VDD during a power up/down. During steady state, there will not be any current. The VDDSHV6 supply issue highlighted should not relate to VPP/VDD. Can you list the VDDSHV6 current consumption and how it changes over time? Can you help probe some of the IO lines on the VDDSHV6 to see if there is too much noise (Overshoots/Undershoots)?"
  • Hi Biser and Paul,

    thank you very much for your response. I really appreciate that I can discuss this latch-up issue with you. I have checked all 59 signals that are related to VDDSHV6 supply but I can't see anything that worries me. Most of these pins are used as outputs (to and LCD controller) , only few are used as inputs and they are connected to an unconfigured FPGA during startup. All VDDSHVx supplies and all peripheral devices are connected to the same 3.3V supply and that regulator is enabled/disabled with the VMMC supply of the PMIC (TPS65910A3) I use the following power sequence:

    - VDDS
    - VDDS_SRAMxx, VDDSPLLxx, VDDS_OSC
    - VDDA_1P8V_USBx, VDDA_ADC
    - VDDS_DDR
    - 3.3V (VDDSHVx, VDDA_3P3V_USBx and all peripherals)
    - VDD_MPU
    - VDD_CORE

    After the latch-up the boards uses approx 400mW more power than before and the input resistance, measurend at the unpowered VDDSHV6 supply, droppes from > 1M to 60 ...170R. The temperature of the AM335x rises from 50°C to over 60°C.

    Do you have any ideas, what the reason for the latch-up could be or what else I could check ? Are there any undocumented limitations between VDDSHV6 and any other supply ?

    Best regards
    Reto

  • Hi Biser,

    I have some new information about our latch-up problem.  The power concept on my board is based on the "TPS65910 Users Guide for AM335x processors" I have attached a block diagram of our design:

    2477.pwr_block_diagram.pdf

    Because the PMIC is not able to deliver enough power on its 3.3V outputs to supply all the peripherals (FPGA, PHys, LCD) we have added an additional step down converter (TPS54218) for the 3.3V supply. This regulator is enabled by the VMMC output of the PMIC. This additional 3.3V supply is used for all VDDSHVx supplies of the processor and for the VDDIO supply of the PMIC all the peripherals.

    Trying to reproduce the latch-up situation I have shorted this 3.3V supply for some miliseconds. When doing this strange things happen with the VDDS supply of the PMIC:

    After the short circuit, the VDDS supply rises from 1.8V to 2.3V (!!!) which is above than the absolute maximum rating of 2.1V and this could be the root for the latch-up problem.

    Questions:

    (1) Do you have an idea how I could modify the supply to prevent this situation ?


    (2) Annother issue concerns the PWRHOLD signal. We have connected that input of the PMIC with the PMIC_PWR_EN output of the AM335x. This works but my concern is that it is not save, because we are driving a 3.3V input with a 1.8V signal. Should we change that and use a level shifter or connect  PWRHOLD to VAUX33?

    Best regards
    Reto

  • Hi Reto,
     
    (1) I'm afraid I don't understand how/why the 3.3V supply should drop during normal operation.
    (2) The minimum high-level input voltage on PMIC PWRHOLD input is 1.3V (TPS65910A Datasheet, page 8) so there will be no problem there.
  • Hi Biser,

    (1) Yes you are right, that is something that will not happen during normal operation.  On the other hand I can't preclude this because this supply is connected to debug headers. As a matter of fact 4 out of 10 prototype boards suffer from a latch-up damage and I'm desperately trying to find the reason for that.  I'm not able to reproduce that latch-up and I do not understand what happens exactly.  At the moment all I can say is that these defective boards

    - all boards have been  "healthy" after production 
    - are still booting without strange behaviour regarding the function of the software
    - have an increased power consumption and the AM3359 is getting approx. 10°C hotter than on a "healthy" board
    - do have reduced input resistances at the VDDS and the VDDSHV6 supplies
    - are NOT having this strange increasing of the VDDS supply after a 3.3V drop that I've tried to explain above.
    Could you please review the block diagram and tell me if you think that something is wrong. Any comment on that latch-up issue is highly appreciated!

    (2) Thank you for the answer and sorry for that stupid question, I could have checked that myself.

    Best reagrds
    Reto

  • Hi Biser,
    are there any limitations or conditions regarding rise time ot the AM335x power supplies ? 

    Best regards
    Reto

  • Hi Reto,
     
    I'm not aware of anything outside the documentation. Some information can be derived from the TPS65910A datasheet, pages 29 and 31. From these pages the turn-on delay between power supplies is 2ms, so it can be concluded that this is an acceptable rise time.
  • reto,

    Is the problem solved now? Is it possible that the root cause lays in power down sequence instead of the power up sequence?

    In your design, 3.3V  VDDSHV is supplied by an external buck while 1.8V VDDS is supplied by 65910A3.

    The power up sequence is quite okay because the 3.3V output is only enabled when VMMC exceeds 1.2V (which is the threshold of ENABLE of 54218).

    But during power down procedure, 54218 can still work until the nominal 3.3V VMMC drops to 1.2V.

    335x requires that the VDDSHV can not exceed VDDS more than 2V otherwise serious consequences may be caused. But using a separate buck cannot 100% guarantee this given the bulk capacitor being placed at the input and output of the buck circuit.