DELL XPS 15 9510 LA-K411P (NVDC ISL9538C) NO BOOT / NO CHARGE

[reeluff]

Device history > Bit of liquid damage, that I cleaned up and sorted out all bad components.

Current state > No Boot. No charge. It negotiates 20v on all USBC ports, and will even PD charge out – so all of the USBC circuit is probably ok. I have 3.3V + 5V ALWP present and stable. PCH has its 3V,1.8V,1V. On the board, PCH,EC,ISL,PD chips are all powered on and active. Power button has 3V, board is being signalled by it but not responding. I have 20V USBC in OK, I have a 12.6V main power rail ok. The battery was undervolt dead, so had to manually charge each cell individually up to 11.4V total from 8.*V so that it would have voltage into the board when connected which it now does, though I suspect it could still be problematic.

Attached is schematic from previous gen XPS 15 9500, however it all looks the same to me. I have provided all voltage measurements on all mosfets and the ISL chip – with USBC and battery connected.

I have not looked at NVDC circuit before, and can not find proper documentation for the ISL chip – if anyone has more than the short form let me know. Do my measurements look ok, something not right?

The NVDC circuit, is that 6.9V correct which corresponds to the Phase 1+2 on the ISL chip, seems a bit odd.

[reeluff]

Job complete, fixed.

[mon2]

Upon a quick review, PROCHOT# = 0 so the processor is deemed to be hot.

[reeluff]

Thankyou, will have a think about and look down that pathway a bit - processor is definitely cold and doing nothing, not a good sign.

[mon2]

Review RTC_CELL_VBAT on the EC (VBAT). Something gimpy may be going on with the AC cable detection logic. You have the AC cable connected (ie. power adapter), yet the 2N7002 cluster of AC cable detect logic is broken. Pin #26 on the charger IC is low.

Do confirm that you have a valid battery voltage @ F5 on the EC because the EC is involved with this maze of 2N7002 mosfets. Designed in a way that only twins would understand.

What is the voltage to ground of 3.3V_BAT_LDO on the battery connector?

Review and follow the power up voltage sequence chart on page # 4 of the 9500 schematic.

[reeluff]

The EC is a bga MEC5107. I have no way of knowing where the associated circuit for pin F5 for RTC_CELL_VBAT is located. I probed around the whole area and could not find batt voltage present - however i do have battery voltage on main power line.

With battery only at battery connector i have 3.3V at 3.3V_BAT_LDO, but no CLK_SMB, DAT_SMB, SYS_PRES#. With USBC also present, I have 3.3V on LDO,CLK,DAT - only SYS_PRES# remaining low at 0V. SYS_PRES# seems involved with a battery switch, which the circuit is not on my board and PWR_SHIP_MODE. I concluded I think I am fine at the batt connector though I could be reading the schematic wrong, unless you know otherwise. I am not sure what that battery switch would be used for? Turning off the battery I assume. I have battery voltage on the main power rail, so I assume the battery is not turned off.

Any chance you have a boardview or datasheet for MEC5107. I did start going through the power sequence, but gets very difficult finding anything/ everything!

[reeluff]

I did find some irregularity with the NVDC mosfet circuit above, but it could just be my knowledge of N-channel and this type of circuit and ISL chip that needs to improve.

So all of the 4 power mosfets, no problems from ground to S/D/G. Probing across the mosfet between S/D/G in both polarities no problems except between GATE and SOURCE on the high side mosfets measure low resistance. But not consistently, I am not sure if something is being triggered by my probing or the circuit itself. Removing the 2 high side mosfets off board, there is no low resistance between S/G on the mosfet itself, but the same response does still occur on the board S/G unpopulated pads.

Is this a normal behaviour of this type of circuit, involving this ISL chip.

[mon2]

Post the mosfet resistance values of the removed mosfets. Each should be high.

Perhaps other mosfet leaks on the board. Check with resistance from this high side voltage feed from the adapter to each inductor on the board. Often a leaky high side mosfet means game over. No power in resistance checks. A low reading is due to a leaking mosfet.

[reeluff]

I removed all 5 mosfets from the circuit above, and they all measure high M/OL across S/G/Din all directions and polarity.

Measuring from PL1901, the main inductor in the circuit above with all the 5 mosfets still off the board - across to all other inductors on board, lowest reading is about 47k over to the 1.2v RAM inductor.

[Sephir0th]

My friends, the charging section can't be in question if half of the board is actually powered.
same applies to PROCHOT#. The voltage there is not relevant as long as the required pull-up voltage is not present, often tied to +VCC_ST.
I know from these designs, that the battery won't be charged if the PCH isn't in running condition.

You need to state where exactly the liquid damage was present and which tracks were affected following with a detailed visual and technical inspection of this area. And you need to compare the resistances of the +3VALW, +1.8VALW and +1.05VALW with known good values. This will be your only chance not ending up with a possibly dead Platform controller hub.

[reeluff]

Hello Sir.FairRepair -- I think you might be my number one youtube for repair, you know how to put in the hard work! Thankyou.

You are right, a lot of this involves having a known good board and proper documentation. Have neither.

I am currently troubleshooting what to do with a missing PCH_RSMRST# - that seems to be where my power sequence is stopping. The fear is as always, a faulty EC or firmware that can not be recovered, or indeed the PCH is always villain number 1.

[Sephir0th]

Thanks. For the start it would be helpful to share resistance to GND of the three from me mentioned power rails. Maybe we can suspect something from there already.

[reeluff]

1.8 v = 450ohm, 1.2v = 480ohm, 5v = 49k, 3v = 13k >> one curiosity with the 3/5v is after the board has had power, these rails stay very low ohms for quite a while until they recover.

I probed around the TPS51285B 3/5v controller and all seemed ok, except when measuring voltage on pin 2, VFB1 - the voltage feedback for the 5v the usb-c would power cycle and renegotiate voltage every time my probe touched the pin. Did not happen on the 3V feedback VFB2 on pin4. I will probably try swapping out this chip, and maybe the PD controller - but for now will leave as is as i made progress.

I decided to switch over to the dreaded bios/ EC firmware mission. Started with the easiest one, the BIOS - I rebuilt the bin i ripped from this board, and now have more life. Which quite honestly, surprised me.

I now have blasted past the PCH_RSMRST# sticking point, all the way to getting a DELL logo on the screen. I have keyboard backlight. The board is responding to the power button and turning on most of the time, curiously more consistent with just batttery. Just USB-c not powering on. With battery and USB-c I am getting a weird charging cycle. It will start charging the battery upwards of 1.8A, for about 10s, then drop back down low, then the cycle will repeat. The screen and backlight come on with a dell logo, but no warnings or response from keyboard, then after about 10s will power off. No fan spin, looks like i am missing the 3v but do have the 5V on the fan connectors.

I will attempt to read and write to the EC next via JTAG, but it is very likely I will just get older and greyer trying to get into this chip. Its still seems quite obvious something firmware related is off. Clearlly still something hardware too also, ISL/TPS51285B will be my first to swap out. Of course, still a possibility I have a PCH/CPU issue.

[Sephir0th]

Iiirc the TPS51285 is quite sensitive at the feedback lines and the behaviour you have observed might be therefore normal.

if you wouldn't have revived the board till some extent I would have suspected something wrong with the 1.8V (reads too low for my taste). But since this is 11th gen with +VCCIN_AUX amd +VCC_IN present, it can be okay, just missed the second 1.8V supply instead.

maybe the time will come but right now it looks like it could be something wrong with the current sensing lines. So likely worth to check PR1901, PR1902, PR1931 and PR1935,

Amd from there we need a proper detailed overview of all power rails, preferably written on a picture of the board.

[reeluff]

Any idea if this generation of DELL, using only USB-c for power in requires battery to be installed for the board to powerup?

On USB-c only, the board is power sequencing up to SIO_SLP_S4# OK, but no SUS_ON_EC // On battery only or battery+USB-c it is going all the way to the DDR_DRAMRST# signal OK, before shutting itself down.

Any idea why it is not happy without a battery - I normally expect a board to be more fussy with the battery than without it if experiencing a power fault.

I really dislike the move away from a dedicated simple, robust DC in jack - especially for a device like this running an 8 core intel i7-11800H + Nvidia GeForce RTX 3050Ti. Relying on USB-c only is horrible. So many chips having to communicate with each other running their own little internal firmware and processing cores causes a lot of grief. Considering power limits of USB power, I can understand if this device does require a battery installed to run so that it can pull power from battery and USB-c at the same time when it needs to. They copied apple, then apple went back to having a dedicated power socket again. Just checked, dell in current XPS 15 model running 13th gen i9 still powered only by USB-c only, i find it bonkers.

[mon2]

What are the specs of your usb type C power adapter? Recommend 100W (20v @ 5A) with either a captive type C cable or a known good active cable with e-market for 100W power delivery. Otherwise the 100W power adapter will operate in a throttled mode and then be unable to power this power hungry logic board.

[reeluff]

130W, DELL known good supply

[reeluff]

Job complete, fixed.

[mon2]

Good stuff. Do post the details of the repair for future readers.

[reeluff]

Sure, I spent many hours rebuilding the damaged circuit regions and programming the bios/ec/firmware.

[mido23]

Sure, I spent many hours rebuilding the damaged circuit regions and programming the bios/ec/firmware.

Hello, can I know the method of JTAG EC MEC 5107?and Is it possible get the file EC BIOS from the file MAIN BIOS? THNKS