MacBook Pro M1 A2338 256/16 820-2020 Turns On but No Charge, stuck 5V

[Daniel M]

Hello all,

I bought this MacBook brand new at launch. I have taken care of it since new and it suddenly failed on me recently.. it began to refuse to charge.

I first checked all the basic things before opening it, to no avail.

I have now opened it and taken the logic board out. I did a visual inspection and found no visible liquid damage or corrosion, or exploded caps, burnt components, etc. Cleaned the usb c connectors.

Here are my measurements thus far:



PBBUS_AON: 12V

PP5V_S2: 5.3V

PP3v8_AON: 3.8V (at L5800, L5820, or L5840)

PP3v3_S2: 3.3V at LC710

PP5v_S2: 5V at LC320

PPDCIN_AON_CHGR_R: 5V (at C5205,5204,5203,5202,5201,5206) with both ports)

PP3V3_UPC1_LDO (Near CD3217 chips): 3.4V

PP3V3_UPC1_Core (Near CD3217 chips): 3.4V

PPVBUS_USBC: 5V (if connected to the corresponding port. Only shows 5V per side if connected, other side will show 0v)



I'm stumped. I've reviewed:

https://repair.wiki/w/MacBook_Pro_A2...w_at_5V_repair
https://repair.wiki/w/MacBook_Pro_A2...a_at_5V_repair

Followed all steps (except for Check for DFU or Recovery Mode, and PP1v25_S2:, unable to reach lead with probe) and still haven't found the issue. Haven't found shorts.


Please help any way you can, I appreciate any input. Thank you!!

[mon2]

Hello and welcome.

You are able to use this laptop normally but just does not charge?

Does the desktop show the presence of the battery? Can you review the battery health? # of charge cycles?

Remove all power / disconnect the battery as well -> meter in DIODE mode. Red meter probe, yes RED to ground. Black meter probe to point to test.

Measure in DIODE mode the following points of interest:

I2C_SMC_PWR_3V3_SCL ; check @ pins 2 and 3 on the battery connector
I2C_SMC_PWR_3V3_SDA

The above are linked to the communication lines used by the battery BMS (battery management system) and also the ISL9240 buck / boost controller. We are checking if either of these lines are stuck. Post your measurement.

[Daniel M]

Hello, thank you greatly for your response.

Yes, the computer works on battery, and the battery shows to be in Good health. I checked before disassembling and the cycle count was around 320. When connected, simply nothing happens.. it doesn't say "Battery Is Not Charging" - nothing.

I didn't mention this: the one major change that happened is that I was going to sell it, so I did a factory reset. After resetting, I never charged it.. I just tested the system itself under battery and everything was fine. I didn't attempt to charge it because I didn't think anything of it.

Originally I had suspected that some rain mist had come through the window and damaged it, since I did notice a few tiny droplets of water on the keyboard. This was just before resetting it.. and at that time it was charging fine.

The water drops were tiny and I wiped them away with a microfiber cloth.

So originally I suspected water damage, but I found no water inside or corrosion.

Timeline:

Thursday night - removing all data and backing up, rain mist comes through the window, still charging
Friday - Charged all night, 100% battery, initiating reset. Sold the computer at 100% battery. Checked health etc. (Normally I always used al dente at 70)
Sunday - person I sold it to says they tried plugging in for the first time, not charging.

I had to basically buy the computer back from him.. though I don't know what happened.. it was a bad situation since I had already purchased an m3.. now I'm stuck with a bad laptop and a new M3 thet I need to pay fully.

Anyway, TLDR: suspected liquid damage but no evidence found, with a possibility of firmware corruption due to reset (if that's even possible?)

Proceeding to test as instructed..

[Daniel M]

Hello and welcome.

You are able to use this laptop normally but just does not charge?

Does the desktop show the presence of the battery? Can you review the battery health? # of charge cycles?

Remove all power / disconnect the battery as well -> meter in DIODE mode. Red meter probe, yes RED to ground. Black meter probe to point to test.

Measure in DIODE mode the following points of interest:

I2C_SMC_PWR_3V3_SCL ; check @ pins 2 and 3 on the battery connector
I2C_SMC_PWR_3V3_SDA

The above are linked to the communication lines used by the battery BMS (battery management system) and also the ISL9240 buck / boost controller. We are checking if either of these lines are stuck. Post your measurement.

Pin 2: 0.48 V
Pin 3: 0.46 V

[mon2]

Smbus lines are ok since you can read battery stats.

Check PP1v25_S2: Normal voltage ≈ 1.25V measuring point: Pin 2 of L77D0.

[Daniel M]

Smbus lines are ok since you can read battery stats.

Check PP1v25_S2: Normal voltage ≈ 1.25V measuring point: Pin 2 of L77D0.

Thanks! Okay - dumb question, how to I reach the pin of L77D0?

I flipped the board over and tested C77D8, C77D7, C77D5 and all tested 1.225V

[Daniel M]

BTW I should note - the power draw on the board is fluctuating.

On USBC: 5V first @ 0.2A, then it drops to 0.03A then my ammeter resets and the cycle repeats.

[mon2]

On USBC: 5V first @ 0.2A, then it drops to 0.03A then my ammeter resets and the cycle repeats.

Do you see this on each USB C port? Flip the type C power head by 180 degress to test the other side of the power adapter blade. Recommend that you unplug the adapter from the AC source -> flip around the target type C head and only then plug back the AC source. Type C ports are wimpy in design and cross-shorting is a serious event.

This is an important details and means you are power cycling. This may be due to a shorted part or a missing current sense loop circuit - both will raise an alert of an excessive current draw and the power rail will power down / cycle.

Can you confirm if your laptop is able to power up using only the external power adapter? Not 100% sure if this model is able to function without a battery but attempt to use only the type C adapter.

[Daniel M]

Do you see this on each USB C port? Flip the type C power head by 180 degress to test the other side of the power adapter blade. Recommend that you unplug the adapter from the AC source -> flip around the target type C head and only then plug back the AC source. Type C ports are wimpy in design and cross-shorting is a serious event.

This is an important details and means you are power cycling. This may be due to a shorted part or a missing current sense loop circuit - both will raise an alert of an excessive current draw and the power rail will power down / cycle.

Can you confirm if your laptop is able to power up using only the external power adapter? Not 100% sure if this model is able to function without a battery but attempt to use only the type C adapter.

One port does the cycle I described, and the other port does .2A then turns off, and repeats. This port is like a faster cycle.

I don't think the laptop will power on with just the charger since it is not pulling 19.5V, but currently I have the board taken out so I can't check

I flipped the connector over and tried again, both ports are behaving the same regardless of the orientation of the plug

[mon2]

Also, for the 20V power delivery contract to be selected, each CD3217 ('ACE controller') must be working.

CD3215 Bootup Sequence - LogiWiki

Confirm that you have PP1V5_UPC0_LDO_CORE present for each CD3217 controller. Only the port in use will output this LDO voltage rail of 1v5.

Also check the voltage to ground of:

PP1V8_S2
USBC0_3V3LDO_EN
USBC1_3V3LDO_EN

[mon2]

Just read your last post - study the CD3217 power delivery controller rails. Something is wrong here and till each is working correctly, the 20V power delivery contract will not be selected and the battery will not charge. Presently the IS9240 buck/boost regulator is working in boost mode to take the 5 volts (default of the Type C power adapter designs) and boosting it to 12v.

[Daniel M]

Also, for the 20V power delivery contract to be selected, each CD3217 ('ACE controller') must be working.

CD3215 Bootup Sequence - LogiWiki

Confirm that you have PP1V5_UPC0_LDO_CORE present for each CD3217 controller. Only the port in use will output this LDO voltage rail of 1v5.

Also check the voltage to ground of:

PP1V8_S2
USBC0_3V3LDO_EN
USBC1_3V3LDO_EN

PP1V5_UPC0_LDO_CORE - both 1.58V (didn't need to switch the connector)

PP1V8_S2 - 1.8V (tested at several places)
USBC0_3V3LDO_EN - 0V at TGB19
USBC1_3V3LDO_EN - 0V at TGC66

I need to try those measurements again - maybe I should test at a different place? This is an interesting find!

[mon2]

Remove all power. Meter in resistance mode.

Measure the resistance to ground of:

USBC0_3V3LDO_EN
USBC1_3V3LDO_EN

Assuming that the resistance to ground is not too low for the above, continue to check the voltage to ground of:

UF260 ; TBT boot rom - check for activity of this firmware flash device that is used by the PD ACE controllers

SPI_UPC01_MOSI
SPI_UPC01_MISO
SPI_UPC01_CLK

[Daniel M]

Remove all power. Meter in resistance mode.

Measure the resistance to ground of:

USBC0_3V3LDO_EN
USBC1_3V3LDO_EN

Assuming that the resistance to ground is not too low for the above, continue to check the voltage to ground of:

UF260 ; TBT boot rom - check for activity of this firmware flash device that is used by the PD ACE controllers

SPI_UPC01_MOSI
SPI_UPC01_MISO
SPI_UPC01_CLK

Both USBC0_3V3LDO_EN & USBC1_3V3LDO_EN test OL / Open to ground

[Daniel M]

Assuming that the resistance to ground is not too low for the above, continue to check the voltage to ground of:

UF260 ; TBT boot rom - check for activity of this firmware flash device that is used by the PD ACE controllers

SPI_UPC01_MOSI
SPI_UPC01_MISO
SPI_UPC01_CLK

SPI_UPC01_MOSI: 0.01 V
SPI_UPC01_MISO: 3.2V
SPI_UPC01_CLK: 0.01 or 0 V

This looks wrong, what could be happening here?

[mon2]

Review the direction of each signal in the schematics (arrow direction). Note that the cd3217 is the spi bus master so the cd3217 creates the clock. Back to reviewing the cd3217 that is mated to this spi firmware boot rom. No spi clock means no firmware means no 20v and no battery charging. Do inspect the resistors between the spi flash and the cd3217.

[Daniel M]

Review the direction of each signal in the schematics (arrow direction). Note that the cd3217 is the spi bus master so the cd3217 creates the clock. Back to reviewing the cd3217 that is mated to this spi firmware boot rom. No spi clock means no firmware means no 20v and no battery charging. Do inspect the resistors between the spi flash and the cd3217.

Hi Mon, sorry for my ignorance, but I got a bit lost. I tried to follow the path from SPI UPC01 CLK and it seems to go between UF260 and JF202. On the schematic I looked at for the CD3217, it lists SPI four times, but if I cross reference the pins, they are ground pins on board view.

So needless to say I got lost here.. never seen schematics so complex before (only ever really worked on power supplies and audio amplifiers). Any guidance would be greatly appreciated

[mon2]

UF400 is the SPI Bus Master. The bus master creates and drives the clock signal.

The bus master detail is confirmed by the direction of the arrow on UF400. Internally, the UF400 contains a microcontroller that has a bootrom that fetches firmware from an external SPI bus interfaced memory device (UF260).

SPI_UPC01_R_CLK -> RF295 (15 ohms) -> SPI_UPC01_CLK (netname) -> pin # 6 of UF260 (SPI_CLK) ; clock
SPI_UPC01_R_CS_L -> RF296 (15 ohms) -> SPI_UPC01_CS_L(netname) -> pin # 1 of UF260 (SPI_CS) ; chip select
SPI_UPC01_R_MOSI -> RF297 (15 ohms) -> SPI_UPC01_MOSI(netname) -> pin # 5 of UF260 (SPI_MOSI) ; master out / slave in
SPI_UPC01_R_MISO -> RF298 (15 ohms) -> SPI_UPC01_MISO(netname) -> pin # 2 of UF260 (SPI_MISO) ; master in / slave out

Remove all power. Meter in lowest resistance scale. Confirm the presence of each of the above resistors but do so by placing one meter probe directly to the pin on UF260 (believe it should be visible and can probe with a meter) and the other meter probe on the far side of the resistor that is connected to the flash. In summary, each and every resistor should offer a resistance of ~15 ohms. If OL or a large variance to the expected 15 ohms = suspect.

At this time, at least SPI_CLK is not working. Is it because the CD3217 is not being powered correctly or is it because the resistor @ RF295 is missing / damaged / corroded?

UF400 is a critical power delivery controller since it is the master. The other power delivery controller @ UF500 is a slave device to UF400. That is, UF400 must function first before UF400 can bootstrap to enable UF500.

Confirm the voltage to ground of:

PP3V3_UPC0_LDO ; this one is very important since this rail powers the firmware flash @ UF260
USBC0_CC1
USBC0_CC2

[Daniel M]

UF400 is the SPI Bus Master. The bus master creates and drives the clock signal.

The bus master detail is confirmed by the direction of the arrow on UF400. Internally, the UF400 contains a microcontroller that has a bootrom that fetches firmware from an external SPI bus interfaced memory device (UF260).

SPI_UPC01_R_CLK -> RF295 (15 ohms) -> SPI_UPC01_CLK (netname) -> pin # 6 of UF260 (SPI_CLK) ; clock
SPI_UPC01_R_CS_L -> RF296 (15 ohms) -> SPI_UPC01_CS_L(netname) -> pin # 1 of UF260 (SPI_CS) ; chip select
SPI_UPC01_R_MOSI -> RF297 (15 ohms) -> SPI_UPC01_MOSI(netname) -> pin # 5 of UF260 (SPI_MOSI) ; master out / slave in
SPI_UPC01_R_MISO -> RF298 (15 ohms) -> SPI_UPC01_MISO(netname) -> pin # 2 of UF260 (SPI_MISO) ; master in / slave out

Remove all power. Meter in lowest resistance scale. Confirm the presence of each of the above resistors but do so by placing one meter probe directly to the pin on UF260 (believe it should be visible and can probe with a meter) and the other meter probe on the far side of the resistor that is connected to the flash. In summary, each and every resistor should offer a resistance of ~15 ohms. If OL or a large variance to the expected 15 ohms = suspect.

At this time, at least SPI_CLK is not working. Is it because the CD3217 is not being powered correctly or is it because the resistor @ RF295 is missing / damaged / corroded?

UF400 is a critical power delivery controller since it is the master. The other power delivery controller @ UF500 is a slave device to UF400. That is, UF400 must function first before UF400 can bootstrap to enable UF500.

Confirm the voltage to ground of:

PP3V3_UPC0_LDO ; this one is very important since this rail powers the firmware flash @ UF260
USBC0_CC1
USBC0_CC2

Thanks!

All the resistors tested fine, until suddenly nothing was coming up out of pin 6. I think I may have obstructed or slightly damaged the contact with my probe.. see picture.



RF295: 15
RF299: 15
RF290: 15
RF294: 100

PP3V3_UPC0_LDO ; 3.28V
USBC0_CC1: 0V (using both ports)
USBC0_CC2: 3.3 briefly, then settling on 1.65V and cycling (only using one port, namely, the one closest to the edge)

[mon2]

The resistors are not the same as my earlier post. Can you double-check your work and table of resistors that were checked?

On the flash, you can flux and rework the flash device if you feel comfortable. Practice on a donor board if you are not comfortable with the process before attempting on the live component.