Another 0.4A Switch, fixed

Switch does not turn on. Current draw 0.4A. HAC-CPU-20. Patched Erika.

  • No prior rework. No liquid damage
  • Tested with known good battery
  • No shorts found
  • EMMC tested (backed up successfully with another switch)
  • No cracks on the BGA chips (MAX chips, EN chips)
  • 77621 has correct rails 3v8, 3v7, 1v8
  • PMIC bottom left corner inductor has resistance to ground of 1.2k/1.3k (good board has 0.5k/0.8k)
  • M92 pin5 3v3, pin6 3v3, pin 18 1v8 (pin 18 resistance to ground 7k, another good board is 12k). Pin14 and 15 has also unusual values (diode values and resistances)
  • Replaced M92 just in case. Still unusual resistance values.
  • Switch boots fine and charges normally

Question is how could I have diagnosed M92 to be the culprit?

1 Like

This is pretty typical, some boards will do this and it seems it’s just a fraction of a hair from tipping over to the more “typical” readings found on most other boards. The reason for the difference is, differences in memory (either brand or revision) / other subtle board and components differences and alternatively, even ambient temperature can make a big difference

Of course the other obvious one is maintaining consistent probe polarity relative to ground (which I’m sure you already know) … you’ll get wildy different readings in resistance with your red probe on ground and vice versa.

The other common one, mild liquid damage on, under and around the board, which will skew your readings. I’ve had cases where I’ll get skewed readings (usually more severe than your case) after rework (combination of mild liquid and now flux - acting as a carrier somewhat) and following ultrasonic the readings return to normal

You went through the motions perfectly, you checked most of your primary rails, you didn’t see any significant issues, you recognized it wasn’t stepping into a high current charge state and maintained only 0.4A - being that the M92 is USB management and needs to be working in order to supply high current you tried replacing it first. Sometimes they don’t fail short to ground, sometimes they fail on a non obvious line, for example it might have failed on it’s I2C block and in turn pulled down all other comms putting the whole thing in a braindead state or that section might have just failed open

1 Like

Thanks a lot Severence!

I knew there was something fishy with this Switch. It’s one of those units which keeps “burning” the M92. The Switch worked for few hours and then gave error 2101-0002.

Again, no shorts or anything suspicious around M92. The FET’s also look good and similar diode values compared to another same board rev.

Could it be caused by a bad batch of M92?

And I’m 99% sure the chip soldered properly.

Chip looks soldered fine to me

:thinking: if it ain’t the fets then next port of call might be to check the USB port, any signs (however slight) of skewed or bent pins or dirt/corrosion etc you might consider just replacing it to rule it out, same is true for an overly sloppy fit (which in theory could cause M92 failure).

Failing that, there is an IC on the reverse side of the board above or below the backlight IC which has a connection to the M92 (if I remembering right) maybe this has something to do with it :thinking: Sorry I can’t remember what this IC is doing off the top of my head… just a hunch.

I had a Problem with the Mosfet above M92 when I burned multiple chips.
I saw in the thermal cam that it went hotter than usually.

Thanks! Unfortunately the switch won’t boot anymore so I cannot see how the MOSFET behaves.

I removed the M92 but the LCD won’t turn on (no sound or anything from touching). It should go to error screen even without M92. I know the switch is on because the 1v8 rail activates after pressing power button. I’ve checked the USB port and replaced the fuel gauge. Not sure what is wrong with it…

1V8 being present isn’t an idication the console has booted, just means the main PMIC is still producing this rail on prompt

Is the CPU rail (Max IC below the SoC) being produced following prompt?

1 Like

Sorry, I meant that I know switch received the power on signal (starting the boot sequence) from the power button press

I receive the correct voltages from the CPU buck under the (3v7 and 1v8, 0v9). To what prompts are you referring to?

There are few rails which give a bit different resistances to ground when compared to another board (vs unpatched erista -20)
Black on ground
1v35 100k (vs Mohms)
1v1 1.4kohm (vs 130ohm)
0v8 CPU 50ohm (vs 300ohm)

This is good, means it probably is actually booting (into the OS) behind the scenes, which probably means you have a display/BL issue or … a GPU buck issue (unlikely) - though you could check the voltage here too just to make sure.

Just prompting to boot - IE: pushing the power button, don’t worry you’ve done it :slight_smile:

Yes, I think it’s trying to boot into OS but something is stopping it. I verified that it’s not in RCM mode.
The GPU voltage is 0v but i’m not sure if the test point is correct. The 0v8GPU resistance to ground seems to be fine (60-70ohm both polarities)

I soldered the M92 once again and it took it from a known working switch. No change. I’ve also made sure the LCD connector does not have shorts. Not sure how to test the BL IC…

Thermal cam does not show anything suspicous. BQ is warming as it should be, SoC and PMIC a little bit, M92 not at all (it warms when fast charging on a working switch).

image

I’m not sure about that image tbh - haven’t checked. I’d check it directly on the coils surrounding the Max GPU IC (near the EMMC) and see if it’s present.

If you find you have CPU voltage still but again don’t find the GPU rail is coming up (approx 0.8V to 1.4V) then I’d just go ahead and replace the GPU max IC just to rule it out

Thanks! However I didn’t find any low voltage rails from 77621 next to eMMC. I measured the values also from a working switch running a HOS. The coils were 0V from both sides.

You will see the GPU rail present on a working switch (note the coils are the larger three components and thie GPU rail is on one of them) but the rail will be put put into “standby” if the console is in sleep/standby mode, so make sure your either measuring during boot (the rail will come up following the CPU rail coming up) or after OS bootup and ensure the console isn’t in stanby/sleep (ie the LCD is on an active)

Also, afair this GPU rail isn’t present in RCM or Hekate etc

Sorry for wasting your time. I made sure that the Switch was not on sleep mode when measuring the rails. But seems to be I was wrong. I measured it again on a working unit and the GPU rail activates at around 2nd boot logo or on menu when not sleeping. It might activate before the boot logo but my multimeters are too slow recognize it and I don’t have an oscilloscope to verify it. GPU rail is not active on RCM nor Hekate.

Since this faulty switch is not booting, the GPU rail won’t activate. Based on this, I don’t think we can make an assumption that the problem is in the GPU buck IC.

Someone suggested me to bypass the BQ by powering the board using bench PSU at the 2R2 coil. Not sure if this would help.

Right it will typically come up towards the end of the second boot logo just before entering the OS.

Usually once the CPU rail (the one below the soC) comes up, it’s a pretty good indication it’s cleared the bootloader stage (afaik) and other misc checks (elsewhere on the system) have completed, to be missing the GPU rail would normally point to the regulator itself… or potentially the GPU section of the SoC itself.

I don’t recall if you mentioned if this switch is unpatched, but if it is, you can boot up L4T Ubuntu, if it fails to boot (and in turn this GPU rail isn’t present) then you have a high degree of certainty it’s the Max IC at fault, if L4T does boot on the otherhand, something else is potentially going on.

I don’t know what doing this would achieve tbh, usually faults with the BQ would result in no signs of life at all or first logo then dead… if it’s producing the SYS rail (which it is) then it’s unlikely to be at fault (though I am just guessing)

Good information. Thanks! I replaced the GPU buck. Took it from a donor and reballed it. No change to boot.

Unfortunately it’s patched erika (in the 1st post summary).

Just to summarize. The first (boot) problem was solved by replacing M92, then after few hours it did not boot anymore (error 2101 came once, usually related to M92). M92 replaced couple times and took from a working switch, no help. This switch gets close to be unfixable…

image
image

Shame :frowning: the only other thing I can think of which could potentially halt boot prior to the GPU rail coming up is maybe faulty Wifi IC… though it’s unlikely. Other possibility is the IC I mentioned earlier potentially being at fault (potentially causing the M92 to blow) it’s marked as DC0 near the backlight IC… might be worth swapping it out

After that, I’d say it’s probably SoC related, though I would be curious if you took this further and transferred the SoC to another board whether the problem dissapears, which would imply SoC joint issues or some other failure on the board

Have you tried putting light pressure on the SoC and ram while promting to boot to see if the symptoms change?

Replaced but didn’t help :frowning:

This Switch was in pristine condition and there were no signs of dropping it. I tried now giving some slight pressure to SoC and Rams but no effect on booting.

I have to call this switch to be a no-fix :disappointed_relieved:

Sorry man, sometimes thats the way it goes. My best guess would be (regardless of outward condition) would be SoC issues incl joint failure (not exclusive to impact damage) theyr’e just at the age now where these issues come to the surface, been seeing them myself and have seen quite a few recent topics here with similar issues.

Maybe save this board for an SoC swap to another board in the future just to rule the above out :+1: