AM6442: Schematic review request - TPS6522053 unable to fully ramp up BUCK2/BUCK3 outputs (1V8, 1V1)

Hello James, 

Thank you for the query.

Did you share the PDF searchable schematics?

Regards,

Sreenivasa

Hi Sreenivasa, I've sent the searchable schematics in PDF form via a private message to you now. Thanks!

Hi Sreenivasa - it looks like I'm getting an unexpected voltage coming from the AM6442, out of the IO supply (the thread is over here  TPS65220: TPS6522053RHBR Failed to generate power supply rails )

Doing a cursory check, it does look like I have a failure where I tied a an IO supply to the incorrect supply rail - I expected VDDSHV4 to be tied to 3V3, but it is instead supplied from the 1V8 rail.
That said - we aren't at the point where the PMIC supplies 3V3 to the AM6442 yet - so yep, a bit weird.

Hello James, 

The PMIC may not be starting in case the residual voltage is present.

Can you probe the PMIC outputs to see if the PMIC tries to restart and then shutdown.

The pullup voltage referenced to any of the IO is expected to match the IO supply for IO group (VDDSHVx)

Regards,

Sreenivasa

So the PMIC does start - it tries three times (we go through it in the other thread with oscope shots and everything :D) and then stops.
Doing some more probing at various points just now - the PMIC does (briefly) turn on the enable for the 3V3 switch, providing the AM64 (along with all of other consumers and pullups) with 3V3 power in those pulses. 
My best guess would be that the pullups on the IOs associated with VDDSHV4 (tied to 3V3) are pulling up the SOC_1V8_IO rail. This should be testable if I remove pullups for I/Os associated VDDSHV4 (or perhaps just cut the traces for the I/Os, since with the wrong sourced voltage it isn't really going to be any help) - I would then expect the voltage to no longer be present on the SOC_1V8_IO rail. Does that seem reasonable?

Hello James, 

The rails before the residual voltage is observed is expected to come up.

residual voltage is likely to occur when the IO supply group is referenced to 1.8V and the IO pullup has 3.3V or if any of the IO inputs are available much before the SOC supplies ramp.

Regards,

Sreenivasa

Hello James, 

Which IOs are you seeing that is connected to 3.3V  for VDDSHV4?

Regards,

Sreenivasa

Hi Sreenivasa, the following IOs are involved with VDDSHV4. I've gone through and taken some actions, and actually about to turn on and see whether or not I would get voltage on SOC_1V8_IO here in the next few minutes. I suspect/expect that N20, N21, M20, P20, N18 are possibly the issues.

So, the voltage on SOC_1V8_IO is still present (keeping in mind that FB40 is removed from the board, the voltage isn't coming in from the PMIC 1V8). Here are some shots of the INT_3V3_SYS (from pin 8 of U59) vs SOC_1V8_IO (from pad2 of FB40). SOC_1V8_IO is about 2.2V still.



I suppose the next step would be to review all of the other IOs sourced from 1V8 banks and make sure that none of them are mistakenly pulled up to 3V3.

Hello James,

The 1.8V you are seeing is due to voltage feed.

James Guyton said:

I suppose the next step would be to review all of the other IOs sourced from 1V8 banks and make sure that none of them are mistakenly pulled up to 3V3.

Correct.

Regards,

Sreenivasa

Ugh - so the PHYs (DP83822IRHBR - U40, U41, U63) are operating off of 3V3, with 3V3 I/O - which means that quite a bit of VDDSHV1 and all of VDDSHV2 would be impacted.

For the sake of trying to just get the processor up and running on the board as of now, I'm connecting all of the VDDSHVX to 3V3, and then removing resistors that would pull up to 1V8 or otherwise connect to 1V8 devices (e.g. the WLAN SDIO line 0R and pullups)

VDDSHV0 - 3V3
VDDSHV1 - 3V3
VDDSHV2 - 3V3
VDDSHV3 - 3V3
VDDSHV4 - 3V3

VDDSHV5 - 3V3

(eventually, this will be reworked so that SHV0-4 are 3V3, and SHV5 is 1V8 towards the WIFI). I've removed the FB42, and connected the INT_3V3 so that all of the SOC_1V8 is now 3V3.

In combination, this looks to remove (most of? all of?) the backpowering - the rails from the PMIC are able to come up to their specified voltage, but the 1V1 sags shortly after it reaches 1V1 (about 2ms after reaching 1V1) - see oscope shots below.

The 1V1 is connected to the AM64X, LPDDR4, and a 2-port USB hub (TUSB8020BIPHP - U34) -  honestly I wouldn't expect this to hit current limiting, but unsure if that is what is going on or not. 

On a side note- the timing before the 1V1 sags is remarkably consistent (2.160ms).

Any thoughts on where to possibly go next?

Hello James,

Thank you for updating the progress.

Can you please confirm the MCU_PORz input (SOC cold reset input) is low while the supplies ramp,

Can you please measure the 1.1V after it sags?

Is the SAG present until the next power cycle or does it recover?

Regards,

Sreenivasa

Hi Sreenivasa - the drop is to 400mV - and it recovers for the beginning of the next cycle (ramp to 1V1, 2.160ms start to curve down to 400mV).
I'll look into the MCU PORz input here today and get some scope shots.

Hello James,

James Guyton said:

the drop is to 400mV - and it recovers for the beginning of the next cycle (ramp to 1V1, 2.160ms start to curve down to 400mV)

Cycle - did you mean power-cycle?

Regards,

Sreenivasa

The MCU_PORz is held low for the entire time (CH4).

Both a whole board power cycle, and the PMIC power-up attempts (right now, it is attempting three times to bring the rails up - the  dip in CH1 is the INT_3V3 dropping and coming back up due to the IO from the PMIC turning the supply off and back on).

Hello James,

I suspect the MCU_PORz does not go up since the PMIC is not starting.

Can you DNI the ferrite and check.

Regards,

Sreenivasa

I've pulled the register information for the PMIC - it looks like it has an issue with LDO2 (0V85). I'm going to try real quick to see how the 0V85 looks like, particularly in comparison to the 1V1. I don't see anything in particular that alarms me about the 0V85 in terms of what it connects to, so that will be interesting to see.

If that doesn't prove any particular illumination/insight, I'll pull the FB41 and see if that provokes some changes.

So the 0V85 (LDO2) looks like it is having some issues ramping up - it gets to a max of ~560mV, then drops to ~80mV - the timing coincides with the 1V1 drop as well.
The LDO2 should be fed from the 1V8, which doesn't show any particular signs of trouble. There's an interesting hitch present in the restart for the 0V85 on the 2nd attempt (and it doesn't reach the same max), but 1st and 3rd are pretty close.

Note - changed the vertical scale for CH3 CH4 in the scope shots.

The 0V85 is only connected to the AM64X, and should have 17.84uF of capacitors attached to it counting those at the output and at the load points.


I could pull FB41 just to see what is going on, but I would definitely not expect it to be impacting the 0V85 line.

Hi Sreenivasa,

No external inputs are connected during power up.

Right now, my game plan is to remove R263 (pulling the USB ~RESET high on U34), and pull ~RESET down to GND, check to see if there is an impact on the 1V1 and 0V85.

Next would be to remove FB41 and see if there is an impact on those two lines.

After that, I will likely pull FB6, FB5, and FB4 in that order, checking each time to see if it impacts the 1V1 or 0V85 lines. Another option before removing could be to try to see if the AM64X side of the FB rises before the PMIC side - might be worth a shot before I remove those ferrites.

Can you think of any objections to that plan? :D

Thanks,

James

Removing the FB41 looks to resolve the 1V1 and 0V85 slump!

Now the question is - why?

Looking further into the datasheet:

So these criteria should be met for U34 - and we weren't getting current limiting warnings from the PMIC. 

Hello James,

Thank you for the input 

Kallikuppa Sreenivasa said:

could pull FB41 just to see what is going on, but I would definitely not expect it to be impacting the 0V85 line.

I would recommend trying

I am glad the power-up issues seem to have been resolved.

Regards,

Sreenivasa

Hello James,

Can you update if the board continues with the power-up sequence and boot.

Please measure the MCU_PORz, PORz_OUT and RESETSTATz outputs.

Regards,

Sreenivasa

Hello James,

Regarding the USB query,

Can you start a thread with title TUSB8020B interface (do not add processor number in the title) and explain the USB connections and issue you are seeing for the USB hub experts to support.

Can you check if there is some wrong pullup or some pin mapping is wrong.

I will have a quick look tomorrow.

Regards,

Sreenivasa

Hi Sreenivasa - I can confirm that the MCU_PORz, PORz_OUT, RESETSTATz all go to 3V3.

Hello James,

Thank you.

James Guyton said:

I can confirm that the MCU_PORz, PORz_OUT, RESETSTATz all go to 3V3.

Not sure i understand your inputs. Can you please elaborate. Did you resolve the issue. 

I was suggesting you review the USB hub implementation.

Regards,

Sreenivasa

HI Sreenivasa -  responding to the request to measure the MCU_PORz input, PORz_OUT and RESETSTATz outputs - so it does appear that the processor continues with the power up sequence. I'll be trying in the next day or two to connect to it via a XDS110 debug probe and see how it proceeds there.

I've not resolved the USB hub implementation as of yet - in the process of opening a question on the forums right now. I'll link the topic here after it is created.
Thanks!

James

Link to TUSB question: TUSB8020B: interface power-up issue 

Hello James,

Thank you for the inputs and noted,

Regards,

Sreenivasa