Hi guys, I just got a puzzling switch in front of me. First of all almost every IC has been changed or reflowed including MAX77802A, BQ, Wifi chip and M92. I am surprised that the USB-C port is still original lol. I am kind of stuck in my diagnostic at this point, here is what I have found so far:
The switch charges at 0.5A and at boot time only the Nintendo Logo is displayed. I can clearly hear some weird noises coming from the SoC (sounds like a buzzing similar to a Hard Disk).
Every reading around M92, PI3 and BQ in diode mode seems fine. However, when powering on, the pin in M92 marked as Alert# is low which normally means that there is an issue somewhere (if my understanding is right).
I tried Biskeydumpv9, briccmiiv2, Lockpick_RCM, memloader and Hekate and everything works fine, except for the fact that I can access the SD by using memloader but if I try using UMS in Hekate, it displays Connected but I cannot access the SD on my PC.
Atmosphere just shows a black screen after the logo
Linux works perfectly, but no Wi-fi device is found. I was able to test the RAM (No issues) and the GPU (no issues) using OpenGL and Vulkan.
I get the 1.1V output from the MAX77621 related to the CPU
I decided to test Android as well, I was able to connect to Wifi. I tried to run some GPU benchmarks in 3D marks and all are working fine but the most demanding ones. They do not show any output and were giving fatal errors, which lead to the console turning off. I noticed that I was getting 0.8V as output from the second MAX77621 but only for an instant and it was suddenly turning off. I decided to apply some pressure on the IC and noticed that I was getting the 0.8V more “often”. At that point I attempted the reflow it and now I can see the 0.8V rail for the whole booting sequence of Android. However, the Wifi is now gone, I have tried to reinstall android but no way to get the Wifi working again.
I have tried to reflow the SoC but with no success. Do you think I should reball it?
Do you think MAX77620A could have an impact in this situation?
Thank you in advance for your support. Any advice would be great.
Though, thinking about it, the only thing which the fault symptoms have in common is the SD card and Wifi IC sharing 3V3PDR as a common input, so may be worth checking your getting 3.3V at those two larger caps next to the Wifi IC and at the SD card port… following checking the voltage at these locations might also be worthwile measuring the resistance to ground on this rail to make sure nothings dragging it down, if the rail is present though then in all liklihood it’s probably the Wifi IC at fault causing the missing Wifi, though the issues with the SD would likely be unrelated at that point
Yeah same IC which likely means you have your 3.3V VIN here, so probably not your issue. As for the functionality, it’s not uncommon for one (WIFI/BT) to work and not the other
I’d swap the chip out as it’s almost certainly at fault
How do you think the wifi chip broke ? It was working on Android a before. Apparently the heavy GPU benchmark that I was running do not work on the switch. I have tested it on a fully working switch. So the GPU is fine… I will swap the wifi chip out but would that explain why atmosphere does not run? Would you run other benchmarks on the GPU?
Because aside from 3V3PDR (which you’ve still yet to check) the WIFIBT IC rails are largely independent from the rest of the board, so assuming it’s not something obvious like an antenna (or associated components) issue then this loss of WIFI or intermittent WIFI is generally consistent with a bad IC.
As to the reason why the chip might of failed, no clue, probably board flex and IC fracture or ball/joint damage, hard to know without an X-ray machine
Atmosphere is still reliant on HOS, if HOS refuses to boot due to a bad WIFI IC then so will atmosphere, though I can’t say for sure that that is whats holding it up (there maybe other reasons) it’s possible… one problem at a time , try changing the WIFI/BT IC and see if you can reliably see and connect to a network in ubuntu/android afterwards.
Just to add, it’s entirely possible the entire issue here is SoC side, but we’ll work our way backwards before we start going down that road
I have checked the 3.3V and 1.8V rails on the caps close to the wifi chip and they are present. I do not have any wifi chip at hand. I am going to order a bunch and report back. After reflowing the MAX for the GPU I can use UMS in Hekate to access the SD card from the PC .
Would the faulty Wifi chip explain why it is not fast charging (charging at 0.5A at the moment)? I have also noticed that the resistance to ground on the pin for the USB in M92 is around 380k with USB on one side and 20k (on the second pin) when the USB is on the other side. However the USB port seems fine and by using an USB-C tester every reading in diode mode seems fine. Could that justify the 0.5A drawn? Would you recommend to swap M92 for this kind of issues?
Maybe attempt a reflow first, though I imagine if this IC is the cause which is preventing boot then don’t imagine this will resolve but may be worth a try
GPU and in turn the Max IC which provides it’s rail is not related to SD functionality, so just a coincidence, something else is likely intermittent - either the SD connector pins on the board are loose/broken or the SoC which heat from your max reflow has possibly releived board/joint stress
I will just caution you about randomly reflowing chips and in particular the SoC which is incredibly sensitive to heat and without prior experience reflowing/reballing can result in it’s death, the SoC should always be the last port of call for any kind of rework
well if it’s preventing boot in HOS then yes as fast charging only begins once you begin to enter the OS, that being said I seem to remember that the latest L4T Ubuntu release supports fast charging so if your not getting greater than 0.5A in L4T (assuming the attery isn’t full) then likely points to M92, USB, BQ or fuel gauge issues, I would start by looking at and/or povide a picture of the Fuel gauge section in Hekate.
I don’t know which pin your talking about?
Check continuity instead
after you’ve verified the fuel gauge is good, yeah I’d swap the M92
Actually, since the SD was working even before the MAX reflow, also by accessing the data from the PC using memloader and was only failing in Hekate during UMS, I thought the console was somehow demanding more power in order to make the SD available on the PC + powering the LCD and Hekate and that is why it was failing. However I guess that the missing Wifi might not be a coincidence, I think there is a faulty chip (I believe it’s M92) in the power rail that makes the console partially work and here is why:
Without eMMC and battery the console should be drawing 0.4A and 0.28A with eMMC (tested on a working console). Instead it draws almost 0.5A without eMMC and ~0A with eMMC
The resistance to ground of pin 17 in the USB (the one going directly to M92) is around 20k whereas it should be around 250k (like for pin 8).
The ALERT# pin in M92 is low, which I believe it means that there is an issue somewhere in the power rail or in M92 itself.
I have checked for continuity from the USB pins and everything seems fine. I am tempted to swap M92 at this point. What do you think?
I would start by checking the battery/fuel gauge info (post a pic from Hekate if you can)
I’d check that you cn acess the EMMC in Hekate as 0A current draw when it’s connected implies a short on one of the lines or rails for it.
if the EMMC is not accessible and/or you can’t get the BIS keys with Biskeydump, then I would hazard all your issues fall back to SoC as you would then have SD, EMMC, WIFI, and braindead 0.5A current draw which all have direct relation with the SoC and would be the only thing in common with all your faults, in which case you can attempt reballing the SoC and putting it on another board (if the issue is via/pad issues below) but tbh I’d probably just reserve the board as a donor at this point given the SoC has already been reflowed which likely has finished it off
That being said, might be worthwhile swapping the WIFI IC first to see if the symptoms change, or reflowing and seeing if the symptoms change in L4tT Ubuntu:
I have measured the batter gauge by using an amp tester. In Hekate it shows around +75mA (but bounces between +50mA and +100mA) and it draws 0.5A.
After swapping M92, both pins 17 and 8 of the USB-C have now resistance to ground of 2MOhm which is perfect. Unfortunately the current drawn is the same as before but it now fast charges in Android (2A).
I have then noticed that the resistance to ground on M92 Alert# pin is 4MOhm, whereas it should be around 2MOhm (I have tested on another board). This pin goes directly to the SoC so the problem could be either M92, but since I just replaced it I do not think it is faulty, or from the SoC. Therefore, I believe there are some merged pads under the SoC. WiFi is still not working in Android. I have not reflowed the WiFi chip yet but at this point I think SoC reballing is what this board needs. If you think it might help I can reflow the WiFi chip but I would be surprised if that fixes the WiFi chip, the issue with the SD in UMS and the wrong resistance to ground on Alert# pin.
Fuel gauge seems fine afaict, though you might want to charge up the battery ext as while Hekate is reporting the battery as 6% full, in reality it’s much less than that (as it hasn’t clicked on yet that the battery is actually >1000mAH) so I’m pretty sure HOS wouldn’t even attempt to boot
Pretty sure it’s just because you’ve only got a 5V supply connected, if you connect the Nintendo charger you should see the 15V profile (you may have to hard reboot it I’ve fogotton) if it doesn’t show up then would point to M92 issues (probably install related)
I connected the Nintendo charger and I now get 15V and 5V profiles. The only things off are the temperature (according to the working switch, temp should be 30C in Hekate) and the battery capacity.
