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 
No
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?
I have measured 0.5A while using Android
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?
What is your resistance to ground at pin 6 of M92 with the EMMC connected?
I have 140kohm which I think it’s normal, no?
That’s fine
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:
Thank you for your support.
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.
The good point is that it now fast charges 
Sorry I meant the fuel gauge/battery info shown from Hekate, can you post a picture of this?
Also check that the Biskeydump payload produces valid BIS Keys
Check that your able to backup all EMMC partitions using Hekate
I did a backup of eMMC and BIS keys are ok. I do not see any issue on the eMMC side.
Regarding the gauge info here is the picture.
Does it show an issue with BQ?
Is it normal that I get no USB-PD profiles?
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.
Don’t worry about this, you can reach about 40C just idling in Hekate (moreso in Linux) I would boot L4T Ubuntu and charge the battery up greater than 1000mAH - connect heatsink and fan (don’t worry too much about applying fresh paste. Afterwhich point Hekate should click on and report proper battery stats.
Following I would reflow the Wifi IC and see if that restores any functionality in Ubuntu
Finally I have received a new bunch of Wifi chips. I have replaced the old one but Wifi is still not working. While probing around the Wifi chip I came across one trail which has a resistance to ground of 2.4 ohm. I have removed every component I could find connected to this line from balika011 board view but the resistance has not changed.
Apparently there is something else connected which leads to this resistance but I cannot find what. Do you have any idea of where this trail leads to, apart the components that I have highlighted in the pictures above?
As far as I can see, this is BT VDDIO/VDDO
Is the short to ground present with the WIFI IC removed?
Also can I ask what’s going on with this board? there is flux on every single component, it looks as though somebody has tried to reflow everything. I would take the opportunity to thoroughly clean the board of all contaminent attracting flux to avoid any other potential issues
The short is not present when the WIFI IC is removed. I have tested every Wifi chip I got from the lot and all of them turned out not to work on my Switch. Bluetooth is also not working.
So, I got a Wifi IC (a Cypress instead of a Broadcom, as the original one) from another board and I got Bluetooth back. However, like the original IC, WiFi is not working and a buzzing sound comes out of the Wifi IC when running Ubuntu or Android. I measured the resistance every component close to the WiFi IC and everything seems fine. From a voltage measurement point of view, Vout3p3 which powers on the WLAN and is generated internally stays at 0V. Could it be that the WLAN is disabled in the WiFi firmware? Do you reckon I should get a Broadcom instead?
I noticed that the eMMC was flashed with FW 7.0.4 but the switch had 13 burnt fuses. So, I updated to FW 10.2.0 and now only the first logo is shown when booting normally. I suppose the second logo is not shown because the WiFi is somehow not working.
Any idea? Thank you for your support.
Then it can only be the IC itself at fault or as a result of a bad install/reball, I’d check the corresponding pad/ball of this rail on the IC out of circuit to confirm if these chips are bad
Provided there is no shorts on any of the internally generated rails or VIN after install, if WIFI/BT functionality doesn’t work then it could also be a secondary issue of the chips not being programmed for Switch
I’m not to worried about the buzzing noise (provided none of the reliant rails are shorted) as this is typical even on good boards
I would just veify your getting continuity from the antenna to the 6-pin package (sorry no clue what it is… maybe an RF switch… no clue) and test resistance to ground readings on all six of it’s pins and verify they compare well a to known good board, after measure across each opposing pin… sorry I can’t be more detailed to the test procedure but it’s the best I can suggest without knowing what this component is
They’re both the same so won’t make a difference provided the installed FW on them is meant for Switch (pulled from donors and reballed or propely programmed by the seller/s)
If everything I mentioned above checks out with the IC installed and no rails are shorted or being dragged down in any way and the reball/install is good, then we’re left with the option of it being an SoC side issue… there is one way to semi-verify this in your case by checking to see if WIFI reg enable is on
If the point/s in blue (you’ll have to solder a fly lead upto this point as the EMMC has to be connected and the console prompted to boot) aren’t high then the SoC isn’t even telling the IC to turn on WIFI related rails, which would point to a bad or open line from the SoC being the issue