MacBook Air M2 (A2681) Power Sequence: Every Rail, and the One With No Correct Voltage

Last checked: 7 September 2026.

On the MacBook Air M2 logic board (A2681, board 820-02536), the rail every no-power thread starts with — PPBUS_AON — has no single correct voltage. The open board database lists 13.5 V; eleven of the eighteen repair threads we read measure 12.0–12.3 V on the same net. Both are right, and a tech who condemns a board for not showing 13.5 V is chasing a fault that does not exist.

Below is the rail table by power domain, the ten-step order those rails come up in, and the three things that decide most cases. Apple publishes no schematic for this board, and the leaked 820-02536 file traded on forums is not used here: voltages come from an openly licensed database, bench behaviour from eighteen threads linked at the end.

The rails, by power domain

Voltage, diode and resistance to ground come from the OpenBoardData entry for 820-02536 (1,366 rows, 1,077 nets, 126 voltage readings). The last column is ours: how many of the eighteen threads mention that net — the gap between the rails that exist on paper and the ones that show up on a bench.

The diode figures are diode mode to ground, board unpowered — a fingerprint of what hangs off the net, so compare them against a known-good board, not a rule of thumb. And note the last row: 45 V sits on the backlight output, centimetres from rails running at half a volt.

The sequence, in ten steps

1. PPVBUS_USBC0 = 5 V. The charger delivers vSafe5V before any negotiation.
2. USB-C PD negotiation. The CD3217 controllers ask for 20 V. Nothing past this step happens without it.
3. PPDCIN_AON_CHGR and the PPHV_INT*_AONSW nets = 20 V into the charger.
4. PPBUS_AON — the system bus, through fuse F5200.
5. PP3V8_AON (3.8 V, three phases on PP3V8AON_PH1/2/3) — the first logic rail.
6. PP5V_MPMU_BSTLQ — the PMU’s 5 V boost, through inductor L8430.
7. PMU LDOs: PP3V3_AON, PP1V8_AON, plus the _MPMU and _SPMU pairs at 1.8 V and 1.2 V.
8. S2 standby (5.0 / 3.2 / 1.8 / 1.25 V), then S2SW: PP1V05_S2SW_VDD2H, PP0V855_S2SW_CIO, PP1V12_S2SW_AMPH.
9. S1: PP0V779_S1_SRAM, PP0V88_S1, PP0V5_S1_VDDQL.
10. AWAKE — the SoC actually running: PP1V25_AWAKE_IO, PP2V58_AWAKE_NAND_VCC, PP0V88_AWAKE_NAND_VDD, then the PPVDD_AWAKE_ECPU/PCPU/GPU cores.

The ordering is not a guess. One thread posted a measurement table from a board stuck in a restart loop, and the loop lays the hierarchy out: “PPBUS_AON 12 V … cycling every 11 s / PP5V_S2 5.19 V cycling every 11 s / PP3V3_AON 3.3 V cycling every 11 s … PP0V779_S1_SRAM 0.78 V present for a couple of seconds / PP1V25_AWAKE_IO 1.25 V present for a couple of seconds.” AON and S2 cycle; S1 and AWAKE appear briefly and collapse — the sequence climbing toward the SoC and giving up.

The part nobody covers

1. PPBUS_AON has no correct value

The database says 13.5 V. The threads say 12.0–12.3 V, consistently: “PPBUS_AON: 12.3 V”, “PPBUS_AON is 12 V”, “I also get 12 V on F5200 (PPBUS_AON)”, “without F5200, PPVBAT_AON_CHGR_REG is stable (12.26 V)”.

Neither is wrong, because PPBUS_AON is not a regulated rail — it is the bus tied to the battery. The A2681 pack is 3S lithium-polymer, 11.54 V nominal, rated by Apple at 52.6 watt-hours. Three cells near full charge sit at 13.2–13.5 V: the database figure. Part-charged — or no battery at all, with the charger holding the bus up — they land at 12.0–12.3 V, which is what a board on a repair bench almost always is.

So 12 V on PPBUS_AON with the battery disconnected is normal: write the battery state next to the measurement or the number means nothing. (The 11.54 V and A2669 pack figures come from replacement-part listings, not Apple; the 52.6 Wh is Apple’s own.)

2. Why the board stays stuck at 5 V

This is the most common symptom in the corpus — in the title of five of the eighteen threads: “stuck at 5V”, “5V 30-40mA”, “5V 0.15A”, “5V 0.42a”, “5V 0.05A~0.23A”. It means step 2 never completed.

The PD controller here is the CD3217. Repair Wiki documents it as a TI part based on the TPS65986, made exclusively for Apple, not sold through distribution, with firmware that differs per model and cannot be altered — so the only replacement is a donor from the same board in the same position. There is one CD3217 per charging port, one as Master (normally the DFU-capable port), the others Slave. The wiki puts it plainly: “A defective CD3217 is one of the two probable causes for a MacBook to not request 20V from the charger (the other one being a short somewhere).”

The CD3217 has no public datasheet, but its documented sibling explains the mechanism. TI’s TPS65987D datasheet (SLVSES1D) says the device “supports booting from no-battery or dead-battery conditions by receiving power from VBUS” through “an internal high-voltage LDO which is capable of converting up to 22 V from VBUS to 3.3 V”. That LDO is specified at 3.15 / 3.3 / 3.45 V, its undervoltage threshold UV_LDO3V3 is 2.2 / 2.325 / 2.45 V, and the controller’s own SPI flash runs from it.

Which closes the loop: if that 3.3 V sags below roughly 2.3 V, the controller resets before it finishes negotiating, the charger never goes above 5 V, and the board sits at 5 V forever with nothing wrong downstream of the connector. That is why “5 V and the CD3217 getting warm” is a diagnosis, not a vague symptom — one thread reports exactly that, answered with “if you are confident that it is the CD3217 that is getting hot then this PD controller is defective and must be replaced. Common fault.”

The free test that localises it, from another thread: “Plug your meter into every port… If one port behaves differently (e.g., 0 V instead of 5 V), the CD3217 for that specific port is likely the culprit.”

3. The most-cited component on this board is a fuse

F5200 appears in 8 of the 18 threads — more often than the PMU U8100 (7, Apple part 343S00554), inductor L8430 (4), or any CD3217. It is the fuse in PPBUS_AON, and one thread writes out the test: “Without power to the board, measure the resistance to ground on each side of F5200. If the fuse is not blown, this measurement should be the same on each side.”

Better than testing it is using it. Lifting F5200 separates the input side from the rest of the board — one thread reports “without F5200, PPVBAT_AON_CHGR_REG is stable (12.26 V) … so main power supply is discarded; resolder F5200 now.” That is board bisection with one component instead of ten measurements — the first thing to reach for when a current-limited supply shows a hard short on the bus (see bench power supply diagnostics).

The PP-plus-voltage convention Apple uses here is not unique to Apple: the same grammar shows up in Chrome OS reference designs, and the suffix always encodes the power domain. See the rail-naming grammar decoded from seven official schematics for the cross-vendor version of this table.

Which buck makes which rail

The same database lists the PMU’s switching nodes with their output voltages, which matches converter to rail — useful when you know which rail is dead and need to know where to probe. This mapping is our deduction from matching voltages, not a fact read off a schematic.

DFU is the last test, not the first

“Won’t enter DFU” appears in 6 of the 18 threads, and it is almost never a software problem: with PP3V3_AON or PP1V8_AON missing there is nothing alive to enumerate on USB. Work the rails first.

Apple documents the procedure. On the MacBook Air (M2, 2022) the DFU port is the leftmost one — which lines up with the Master CD3217 — and the keys are right Shift, left Option and left Control, held about ten seconds while pressing power. Apple also separates the two operations you can run: revive “updates the firmware and updates recoveryOS to the latest version” and does “not make any changes to the startup volume, the user’s data volume, or any other volumes”, while restore “erases and installs the latest version of macOS” and leaves “any data on any internal volumes … unrecoverable”. Revive first, always.

Limits, and the mistakes this table invites

• We have no bench. Nothing here was measured by us: the figures are the OpenBoardData entry, the behaviour quoted from the eighteen threads below. A reference, not a verdict.
• Diode readings are a fingerprint, not a spec. They vary with the meter’s test current, so a value a few hundredths off the table is not a fault — see multimeter specs that matter and the diode-mode guide.
• A rail at the right voltage is not a working rail. These are DC figures; one that is correct unloaded and collapses under the SoC still reads fine on your meter.
• Apple’s schematic is not public. The 820-02536 file traded on forums is a leaked internal document; we neither link nor quote it. Framework publishes its mainboard schematics under CC BY if you want a legal one to practise on — see how to read a laptop schematic and boardview.
• Apple documents module replacement only — whole board, whole battery. That is the same gap the EU spare-parts rules leave open: the legal lists stop at board assemblies too.

Sources

• Rail voltages, diode and resistance readings for board 820-02536: OpenBoardData Project. Derived from the OpenBoardData Project database, available under the Open Database License (ODbL).
• CD3217 origin, Master/Slave roles and firmware: Repair Wiki, CD3217 compatibility (CC BY-SA 3.0).
• PD controller LDO and undervoltage figures: Texas Instruments TPS65987D datasheet (SLVSES1D).
• Battery capacity and charging: Apple, MacBook Air (M2, 2022) Technical Specifications. Service procedures: Apple Self Service Repair manual index.
• DFU port, key sequence, revive vs. restore: Apple, revive or restore a Mac with Apple silicon.
• The 18 threads counted and quoted, all on board 820-02536 / A2681 — Rossmann Group boards: 65307, 65223, 65632, 65729, 65787, 65815, 65824, 65915, 66009. Badcaps: 3176529, 3252225, 3582207, 3698364, 3778236, 3838059, 3844071, 3848268, 3852973.