MacBook M1 Pro 14" 2021 A2442 (820-02098) — U2020 getting hot, board not powering on

[slimmy182]

Hi all,

I’m working on a MacBook Pro 14” 2021, board 820-02098, no power.
I’ve been focusing on the PP1V8_AWAKE rail which seems problematic.
Here is what I’ve tested:

• • Symptoms:
  • • Board does not power up.
    • Power-in: ~5.1 V / 0.47 A (~2.45 W)
    • With thermal camera, U2020 was initially hot (>70 °C).
• • Measurements:
  • • Resistance to GND @ C2021 / C2030 / C2041 = ~4.0 Ω (meter probes zeroed).
    • Same reading in diode mode.
    • Voltage with board powered:
    • • PP1V2_AWAKE = 1.2 V (OK)
      • PP1V8_AWAKE = only ~1.55 V instead of 1.8 V.
• • Isolation steps:
  • • Removed bulk caps C2021, C2030, C2041, C2010 → resistance unchanged (~4 Ω).
    • Removed U2030 & U2040 (SN74AVC1T45 level shifters) → unchanged.
    • Removed U2020 → unchanged.
    • Removed LR501 / LR502 → codec side high resistance, but PP1V8_AWAKE side still ~4 Ω.
    • Injected 1.5 V / 3 A at C2041: current flows, but no clear hotspot. (did not sink the full 3 A – the power supply stayed in CV mode with around 0.4 A draw)
    • • Only U2010 (MX25U6472F SPI flash) warms slightly (~40 °C).
  • • U2000 (second SPI flash) not yet removed.
    • Other caps tested/removed → no change.
• • Current status:
  • • PP1V8_AWAKE undervolts to ~1.55 V.
    • Rail resistance still ~4 Ω.
    • Only U2010 shows activity under injection (light heating).
    
    
• • After removing U2010, the resistance on PP1V8_AWAKE → GND increased from ~4 Ω to ~8 Ω.
  • Power injection at 1.5 V/ 3 A at C2041→ ~0.15A (CV), no visible hotspot (thermal + IPA).
  • U2010 off-board: VCC–GND ≈ 6 Ω → clearly leaky; will replace.
  • U2000 off-board measured high resistance; reinstalled → rail still ~8 Ω.

 

[2informaticos]

"Injected 1.5 V / 3 A"
Can you explain how did that???
You can claim for Nobel prize!

1.5V divided by 4 ohm let you with just 375mA.
Read something more about Ohm law...

0.368 listed for diode mode on refference table.

OpenBoardData Project

Voltage injection can't cause important heat.
Remove CPU heatsink first, then use performant thermal camera.
Any chip, or capacitor showing a bit more heat signature like the rest, is suspect.

BTW, when you inject voltage, set current limit to max from start.
The board will take just the current required by the resistance to ground; you can't adjust it.

 

[slimmy182]

Thanks for the comment. We’re on the same page with Ohm’s law.

• Earlier, before removing U2010, PP1V8_AWAKE ≈ 4 Ω → at 1.5 V the draw was ~0.35–0.40 A (PSU stayed in CV).
• After removing U2010, the rail measures ~8 Ω → at 1.5 V the draw is ~0.18–0.20 A (also CV).
  Both figures match I = V/R.

For injection I set the voltage to the rail value (≤1.5 V) and the current limit high (3 A) so the supply doesn’t current-limit unless the load demands it — exactly as you suggest. Since the effective resistance is a few ohms, the PSU never hits CC. Heatsink has always been removed. With IPA + thermal cam, U2010 was the only part showing slight activity (~40 °C). No other part heats up.

Current status: removing U2010 doubled the resistance (4 Ω → 8 Ω). Off-board, U2010 reads ~6 Ω VCC–GND, so it was leaky. The rail is still ~8 Ω with U2000 present and U2020/U2010 removed.

Unfortunately, I don’t have access to a high-end thermal camera. What do you suggest I check next?

 

[2informaticos]

For 1.8V power rail, you can inject 2V without problems.
Will still be too low for heat generation.
Only good IR camera can give you some kind of information.

U7700 and all audio amplifiers are directly connected to 1V8_AWAKE.
Few chips more on page 12...

 

[slimmy182]

• Checked resistor dividers / pull-ups (R2020–R2025, R2030–R2032, RD215, RD216, RR664, RR734) → PP1V8_AWAKE side low, signal side high.
• Confirmed short not on SoC side of I²C lines (pin toward SoC always OL/high).
• Removed UR600 (IC on the rail) → no change.
• Began isolating speaker amp blocks:
  
  • Removed UR700 → resistance rose to ~12 Ω.
  • Removed UR730 → resistance rose further to ~32 Ω.
    
    • Checked its pads (pins 12, 18, 19, 23, 26, 27, 29, 30) → all OL/high.
  • Finally removed UR760 → resistance became very high (rail clean).
    
    • All its pads OL/high → maybe UR760 itself internally leaky?

Current status

Two confirmed bad parts:

1. U2010 (leaky SPI flash, ~6 Ω off-board).
2. UR760 (audio amplifier block, maybe internally leaky).

 

[2informaticos]

Board should turn on without amplifier chip, for test.

 

[slimmy182]

I replaced U2010 and U2020 with parts taken from a donor board.
Now I have:

• PP1V2_AWAKE = 1.22 V
• PP1V8_AWAKE = 1.77 V

However, the Mac still does not power on.

• With the battery connected: power adapter negotiates 20.63 V, 0 A, 0 W.
• With the battery disconnected: 5.192 V, 0.182 A, 0.996 W.

In both cases, the Mac is detected in DFU mode by Apple Configurator, but when I try to restore it I get this error:
Unable to restore system on this device.
Unexpected device state 'DFU' expected 'Recovery' (Probably forced into DFU mode externally)
[com.apple.MobileDevice.MobileRestore – 0xFAE (4014)]

Any advice on what to check next would be greatly appreciated.

 

[2informaticos]

Force off the machine; hold power button more than 5s.
Then try again DFU; better using external switch method.

DFU Mode Restore (Macs) - LogiWiki

We have Apple MacBook and iPhone Diode readings and general fault finding information compiled by the leaders in this area

logi.wiki

 

[slimmy182]

Force off the machine; hold power button more than 5s.
Then try again DFU; better using external switch method.

DFU Mode Restore (Macs) - LogiWiki

We have Apple MacBook and iPhone Diode readings and general fault finding information compiled by the leaders in this area

logi.wiki

Here’s the current status and all the checks done:

Power rails

• Always-on / Awake:
  • PP1V8_AWAKE ≈ 1.8 V (C2041) – stable
  • PP1V2_AWAKE ≈ 1.2 V (C2040) – stable
  • PP3V3_AON ≈ 3.3 V – present
  • PP3V8_AON ≈ 3.8 V – present
  • PPBUS_AON ≈ 12.3 V – present
• CPU awake:
  • PPVDD_ECPU_AWAKE ≈ 0.64 V idle, drops to 0 V during failed Revive
  • PPVDD_ECPU_SRAM_AWAKE ≈ 0.77 V idle, drops to 0 V during failed Revive
• Rails that appear only when Revive starts:
  • PP1V2_S2 ≈ 1.2 V (CD102/CD103) – comes up
  • PP3V3_S2 ≈ 3.3 V (CD150/CD151) – comes up
  • PP1V8_S2 ≈ 1.8 V – comes up
• SSD rails:
  • PP2V5_NANDx ≈ 2.5 V
  • PP1V2_NANDx ≈ 1.2 V
  • PP0V9_NANDx ≈ 0.9 V

SPI bus checks

• CS# (R2011 pin 2 / U2040 pin 4) → 1.8 V idle, oscillates low during Revive.
• CLK (R2025 pin 2) → ~0.2 V average during Revive (activity).
• MOSI (R2024 pin 2) → moves during Revive (activity).
• MISO (R2032 pin 2) → flat 0 V during Revive.
• Path traced: U2010 pin 2 → R2030 → U2030 pin 3 → U2030 pin 4 → R2032.
  • No activity already at R2030 pin 1/2 (direct ROM output).
  • R2032 ~33 Ω, continuity good.
  • WP_L (R2010) ~1.77 V stable.

Rework done

• U2010 (SPI NOR) replaced once from donor.
• U2020 (previously heating) replaced from donor.
• U2040 (level shifter for CS#) also replaced from donor.
• Confirmed no shorts on CS#/WP lines, pull-ups OK.
• Tried DFU with external switch method (SV113) → still same error.
• Board always detected in DFU, power negotiation stable (5.2 V / 20.6 V).

Current behavior

• DFU mode every time.
• Revive starts: CS#/CLK/MOSI active, but MISO dead at ROM output.
• CPU rails (PPVDD_ECPU_AWAKE / SRAM) collapse after failure.
• Error shown: 4014 or 4042.

Question

Given that CS#/CLK/MOSI are alive but MISO is flat already at the ROM output (R2030 pin 1/2), does it make sense to:

• replace R2032 with a fresh 33 Ω (just in case),
• replace the full pair U2000 + U2010 from a matching donor

…or is there another known weak point on 820-02098 that could kill MISO before the SoC sees it?

 

[2informaticos]

Dead chips connected directly to CPU could affected it...

 

[slimmy182]

Thanks for your reply. Could you please specify which chips connected directly to the CPU you would recommend checking on this board (820-02098)?
I already inspected the SPI ROM path (U2000/U2010, U2040, series resistors) and power rails, but if there are other ICs known to affect the CPU or DFU/Revive process on this model, I’d appreciate some guidance on where to focus.

Also, do you exclude that the problem could be related to U2010 coming from a donor board with different firmware content than my original U2000 (which I didn’t replace)? Could a mismatch between the pair cause the failed Revive/Restore?

 

[2informaticos]

I can't discard U2010 firmware issue.

You had one audio amplifier damaged; that is connected to CPU.