Switch drwaing 0,00A no short, where to start searching?

If Vex is an input I found a topic here:

cannot post links :frowning:

Maybe it will be useful to change all 3 mosfets and the small IC on the other side.

VEX is an power input and is fed from the same line as the VBUS @ the bq.

If I got it right, the m92t36 should switch at first the top mosfet of the three mosfets below the m92t36 to bring the voltage from the usb c port to the bq VBUS line.

I changed the top mosfet and all three mosfets on the downside. Also changed the small ic on the other side. Still nothing :frowning:

Hey dude,

Try checking those resistors abve the M92 IC, one doesn’t look to healthy, instead of measuring on the resistor directly measure from the IC to the cap. Also I’d check those darkened traces around the M92 IC and ensure none are damaged etc.

It’s entirely possible this board has internal via damage from over rework though :frowning:

You’re right, the resistor was faulty, infinite resistance. I changed them, checked all resistors and all traces. Still same behavior. Maybe change again M92? What dark traces do you mean? I have made 2 new pictures.


I have now connected a 15v usb-c charger. It loads 30mA for about 2 seconds then zero and so on. What about voltage injection in the point where the 5v are missing?

We have some luck, I changed the M92 again and now we have draw 0,45. But no fast charging no booting no backlight.

what about the bq24 are any of the caps around that shorting out?

:slight_smile:

Can the OP confirm that USB is now prompting the console to boot IE: your getting all your rails present surrounding the PMIC following plugging it in now?

Can you confirm the process, does it drop to zero than back to 30mA and hold or is it consistently cycling 30mA zero, 30mA zero etc?

Is this unpatched?

This is cycling between 30mA and zero.

This console is cfw capable

In my opinion the APU is faulty because: I have here the same console with blue screen of death and this have exact same behaviour. So I tried to reflow (not reballed) the APU on both consoles, but still same. The BSOD console is now exact same behavior as the other. The second console is also cfw capable as I remember.

would usually be indicative of a short or open somwhere

Can you post images of the console info section in Hekate incl battery/fuel gauge info

i don’t think so but you do significantly reduce it’s chances by reflowing the SoC without cause :frowning:

You haven’t tried swapping the EMMC modules around between these boards have you? as you can’t do that as you’ll likely blow update fuses

BSOD it’s more common it’s the fuel gauge, RAM, PMIC,or EMMC issue, I would also load up the Hekate payload on this one too and perform a full backup of the EMMC and ensure that your able to read, and also post and image of the fuel gauge stats here too, after you can load up the biskeydump payload and ensure the eMMC is a match with the SoC :slight_smile: