Waarom “no power” op Apple Silicon zelden één meting is

Je krijgt een MacBook met de klacht: “Hij doet helemaal niks.” Geen chime (bij Apple Silicon vaak sowieso geen indicatie), geen beeld, geen laad-LED, geen trackpad-klik, geen fan—volledig dood. De gebruiker heeft al “alles geprobeerd”: andere lader, andere kabel, een hele nacht aan de stroom, en soms zelfs “een reset”. Jij moet nu beslissen: is dit een laadpad-probleem, een power sequencing-probleem, een kortsluiting op een rail, of simpelweg geen geldige ingangsspanning?

Bij Apple Silicon is “no power” bijna altijd een volgorde-probleem: rails moeten in de juiste sequence opkomen, met de juiste drempels en “power-good” voorwaarden. Als één rail wegblijft of instort, kan het systeem al vroeg stoppen—zonder dat er iets zichtbaar is. Daarom heeft willekeurig prikken met een multimeter weinig waarde; je diagnose wordt pas sterk als je rails in context meet: welke rail hoort wanneer te bestaan, en wat is de afhankelijkheid?

In deze les leer je een rail- en sequence-denkmodel dat je snel helpt onderscheiden: “Geen ingang” vs “ingang oké maar sequence stopt” vs “rail wordt kortgetrokken” vs “logic/enable ontbreekt”.

De basis: wat bedoelen we met rails, states en “power-good”?

Een power-rail is een spanningslijn die een deel van het systeem voedt: bijvoorbeeld een always-on domein, een PMIC-uitgang, een geheugenrail of een core-rail. Rails zijn niet “allemaal tegelijk” aanwezig. Het ontwerp dwingt een power-up volgorde af om inrush, latch-up, brown-out en datacorruptie te voorkomen.

Drie begrippen die je steeds gebruikt:

  • Always-on (AON) / standby rails: rails die al aanwezig zijn zodra een geldige input (USB‑C/adapter/batterij) binnenkomt. Ze voeden o.a. detectie, power-management logica en wake-events.

  • Sequenced rails: rails die pas opkomen nadat voorwaarden kloppen (enable-lijnen, geldige input, geen faults, thermals, enz.).

  • Power-good (PG / PGOOD): een signaal (soms intern, soms meetbaar) dat aangeeft dat een rail binnen tolerantie is en stabiel genoeg om de volgende stap toe te staan.

Denk aan power-up als een toneelvoorstelling: AON zet het podiumlicht aan, de sequencer bepaalt wie wanneer opkomt, en PG is de regisseur die zegt: “Oké, volgende scène.” Als één acteur te laat komt (rail ontbreekt) of flauwvalt (rail zakt weg), stopt de hele show—en jij ziet alleen “geen power”.

Power-up volgorde als diagnose-instrument (niet als theorie)

De meest nuttige manier om sequencing te gebruiken in no-power diagnostiek is: je probeert niet meteen te repareren—je probeert te lokaliseren waar de volgorde stopt. Dat geeft je een “stop-punt” dat je kunt koppelen aan een domein: input/charging, AON, PMIC, SoC enable, geheugen, display/backlight, enz.

Een praktische manier om states te ordenen (hoog niveau, omdat exacte railnamen model-afhankelijk zijn) is:

  1. Input aanwezig: er komt energie binnen via batterij of USB‑C power path. Zonder dit is alles erna ruis.
  2. AON/standby actief: basislogica kan meten, detecteren en beslissen. Hier zie je vaak stabiele lage stroom of duidelijke korte-sluit symptoms.
  3. Enable + sequencing start: een controller/PMIC krijgt een “go” en begint rails op te bouwen.
  4. Main rails stabiel: meerdere rails komen op en blijven, vaak gevolgd door load-step veranderingen.
  5. SoC start / bootfase: je ziet typisch een stroomprofiel dat verandert (bijv. PD onderhandelt, daarna stapjes), al zonder beeld.

Belangrijk: je diagnose wordt sneller als je per stap één vraag stelt: “Welke voorwaarde is nodig om naar de volgende stap te gaan, en zie ik die?”. Meet je een rail die niet bestaat, vraag dan: “Hoort hij al te bestaan in deze state?” Meet je een rail die kort opkomt en wegzakt, vraag dan: “Is dit een protect/fault response of een overbelasting/kortsluiting?”

Veelgemaakte valkuil is “rail-jagen” zonder state-besef: je meet tien punten, vindt vijf die 0 V zijn, en concludeert “PMIC defect”. Dat is vaak onjuist: die vijf horen pas later te komen. De betere aanpak is: verifieer eerst de earliest-possible rails (ingang/AON), en werk dan pas forward naar rails die afhankelijk zijn van enables/PG.

Wat je met een multimeter wél en níet kunt bewijzen

Bij advanced no-power werk is een scope en power supply ideaal, maar als beginnende Apple Certified Technician heb je vaak eerst een multimeter en basis tooling. Daarmee kun je, als je slim meet, al veel onderscheid maken.

Het verschil tussen “0 V” en “niet ingeschakeld”

0 V op een rail kan betekenen:

  • Geen input / power-path onderbroken: dan is 0 V op vrijwel alles logisch.

  • Rail is sequenced en nog niet enabled: 0 V is dan normaal in een vroege state.

  • Rail probeert op te komen maar wordt direct afgeschakeld: met alleen een multimeter mis je de puls, en zie je “0 V”.

  • Hard short naar ground: de rail kan niet opbouwen, of zakt meteen in.

Daarom combineer je spanningsmeting met minstens één extra datapunt: weerstand/diode-mode naar ground (board unpowered) of stroomgedrag (als je een USB‑C meter of bench supply hebt). Op Apple Silicon-boards is “lage weerstand = kortsluiting” een gevaarlijke misvatting: sommige rails tonen van nature lage waarden door parallelle loads of meetpaden. Je zoekt dus naar “verdacht laag én consistent met symptoms”, niet naar een magisch getal.

Een rail beoordelen: drie snelle checks

  1. Is de rail logisch in deze state? AON hoort vroeg; core-rails horen later.
  2. Blijft de rail stabiel? Als je wél een stabiele waarde ziet, noteer die; instorten wijst op protect/overload.
  3. Is er een duidelijke short-indicator? Sterk afwijkende meting t.o.v. vergelijkbare netten (of t.o.v. ervaring) + thermische indicatie + direct shutdown is overtuigender dan alleen “lage ohms”.

Vier no-power klassen: waar je diagnose meestal op uitkomt

Onderstaande vergelijking helpt je no-power klachten sneller te rubriceren. Dat voorkomt dat je te vroeg de verkeerde hoek in gaat.

Dimensie Geen geldige input AON actief, sequence start niet Sequence start, stopt vroeg (fault/overload) Main rails oké, maar “lijkt dood”
Wat je ziet aan gedrag Geen tekenen van leven, geen laadgedrag, vaak 0 mA of geen PD-activiteit Kleine, stabiele standby-consumptie mogelijk, maar geen doorgroei Korte “pogingen”: stroompuls, klik/heat, daarna terug naar laag Stroom trekt op, blijft hoger, maar geen beeld of user-feedback
Wat rails doen Vrijwel alles blijft 0 V AON rails aanwezig; sequenced rails blijven 0 V Sommige rails komen kort op en vallen weg; PG faalt Meerdere rails aanwezig en stabiel; probleem ligt later in chain
Typische oorzaken Defecte adapter/kabel, poort, battery disconnect, power-path onderbreking Enable ontbreekt, sensor/fault-lijn blokkeert, PMIC krijgt geen startconditie Kortsluiting op een rail, overcurrent, defecte regulator/PMIC-uitgang Display/backlight pad, boot hang, randperiferie/firmware, (nog steeds) rail-dip onder load
Beste eerstvolgende stap Inputpad verifiëren: komt energie binnen? Zoek startvoorwaarden: detect/enable/PG in vroege domeinen Lokaliseer stop-rail: welke stap triggert shutdown? Bevestig “main power good” en concentreer op latere subsystemen

Deze tabel is je “routeplanner”. In 30 minuten wil je niet elk schema uit je hoofd leren; je wil sneller herkennen welk patroon je in handen hebt, en daarom gericht meten.

Power-rails lezen als oorzaak-gevolg keten

1) Always-on domein: het fundament dat je diagnose versnelt

Always-on is het domein dat de rest “mag aanzetten”. Als AON niet stabiel is, heeft het weinig zin om naar latere rails te kijken. In praktijk betekent dit: zodra er input is, moeten bepaalde basale rails stabiel zijn en niet instorten. Als je hier al dippen ziet, denk je eerder aan short/overload of een ingangsprobleem dan aan “de CPU is dood”.

Een belangrijk best practice is om AON te behandelen als een poortwachter: je meet één of twee representatieve AON-rails (model-afhankelijk) en noteert: aanwezig/afwezig, stabiel/instabiel. Daarna meet je pas verder. Dit voorkomt een klassieke pitfall: je meet een core-rail die 0 V is, terwijl de machine nooit voorbij AON is gekomen.

Typische misvatting: “Als AON er is, moet de Mac meteen opstarten.” Niet waar. AON is vaak aanwezig bij een device dat netjes in protect blijft door een fault. AON kan dus juist aangeven: input is er, maar het systeem weigert door te gaan. Dat is diagnostisch waardevol—want nu ga je op zoek naar de reden dat sequencing niet start of niet doorloopt.

2) Enables, faults en ‘power-good’: waarom één ontbrekend signaal alles stillegt

Sequencing draait op voorwaarden. Een rail kan perfect gezond zijn, maar nooit enabled worden omdat een controller ergens “nee” zegt. Dat kan zijn door een fault (overcurrent detect), door ongeldige input, door thermals, of door een ontbrekende wake/startconditie. In je metingen zie je dan: AON oké, maar stap 2 gebeurt niet.

Best practice hier is oorzaak vóór gevolg meten. Als een rail ontbreekt, vraag je: “Wie moet hem enablen?” en “Wat heeft die enable-lijn nodig?” Zonder schema is dat lastig, maar je kunt nog steeds logisch redeneren: altijd-on voedt control logica; control logica geeft enable; regulator zet rail; PG geeft terugkoppeling om volgende rails te starten. Als deze keten ergens breekt, stopt alles downstream.

De grootste valkuil is om “geen rail” te verwarren met “defecte regulator”. In werkelijkheid is een niet-enabled regulator vaak gezond. De misvatting “0 V = kapot” leidt tot onnodig boardwerk. Als je later wél ziet dat een rail heel kort opkomt en meteen afvalt, verschuift je hypothese richting protect/overload: enable gebeurt wel, maar de rail faalt op stabiliteit of load.

3) Vroeg stoppen: het typische patroon bij shorts of overload

Wanneer sequencing start en vervolgens vroeg stopt, zie je vaak een herhaalpatroon: een rail probeert op te bouwen, load stijgt, protect triggert, en het systeem reset naar AON. Met een multimeter kan dit lijken alsof alles 0 V is—omdat de “aan”-tijd te kort is. Daarom is context belangrijk: als je symptomen hebt van pulsing (bijv. kortstondige warmte, kortstondige stroompiek op een meter, of een herhaalde poging), dan moet je denken: er is activiteit, maar iets trekt het onderuit.

Best practice is om dan niet “alle rails” te meten, maar te zoeken naar de eerste rail die instabiel wordt. Dat is vaak dichter bij de root cause dan de rails die nooit aan komen. Als je één verdachte rail vindt, ga je board unpowered naar ground meten (weerstand/diode) om te zien of die rail plausibel zwaar belast is. Je combineert dit met observaties: wordt een component warm? Zakt de rail direct? Komt het steeds terug met een interval?

Veelgemaakte fout: te snel concluderen dat de SoC defect is. Apple Silicon SoC-failures bestaan, maar in no-power klachten zijn power-path, regulators, en shorts statistisch vaker logische eerste hypotheses. Je wilt pas naar “SoC” wijzen als je een sterke chain-of-evidence hebt: input oké, AON oké, enables aanwezig, maar een essentiële rail kan niet stabiel worden zonder aanwijsbare externe load of fault.

4) “Main rails zijn er” maar de machine is toch dood: waarom dit nog steeds power-sequence kan zijn

Soms meet je meerdere rails die netjes aanwezig lijken, maar de Mac geeft geen user-feedback. Dit is het verraderlijke gebied: je kunt denken dat het “geen power” is, terwijl het eigenlijk “geen boot/no display” is. Toch blijft sequencing relevant, omdat sommige rails alleen onder load instorten. Met een multimeter zie je dan een nominale spanning, maar tijdens een bootpoging kan die rail dippen en een reset veroorzaken.

Best practice is om je diagnose op te delen: power aanwezig versus functioneel opstarten. Als main rails stabiel zijn, verschuift je vraag naar: “Welke stap in de power-up/boot keten wordt niet gehaald?” Zonder extra tools blijft dat beperkt, maar je voorkomt wel dat je eindeloos in input/AON blijft hangen.

Typische misvatting: “Als er een paar rails zijn, dan moet het scherm aan.” Bij Apple Silicon kan het systeem intern actief zijn zonder directe beeldoutput (bijv. afhankelijk van displaypad/backlight of een boot hang). In de workflow van no-power diagnose betekent dit: eerst hardmaken of het echt een power-probleem is, of een later boot/display symptoom.

Na deze kernlogica kun je power-up volgorde het best onthouden als een simpele keten: Input → AON → Enable → Rail → PG → volgende rail.

[[flowchart-placeholder]]

Twee realistische diagnoseverhalen (zoals je ze in de werkplaats tegenkomt)

Voorbeeld 1: “Geen reactie op lader” blijkt een vroeg-stop in de sequence

Een klant brengt een MacBook binnen: geen beeld, geen tekenen van leven, en “laadt ook niet”. Jij start met het vermijden van de klassieke denkfout: “geen reactie = geen input”. Je verifieert eerst of er überhaupt energie binnenkomt en kijkt vervolgens of AON zich gedraagt als basisfundament. Je meet op representatieve punten (model-afhankelijk) en ziet dat er wél een stabiele standby-aanwezigheid is: niet alles is 0 V, en het board is niet volledig dood.

Daarna probeer je te bepalen of de sequence start. Met alleen een multimeter mis je soms de pulsen, maar je kunt signalen indirect lezen: zie je dat een rail heel even aanwezig lijkt als je meerdere keren aansluit? Merk je een subtiele warmteontwikkeling of een kort “probeer-moment”? Je concludeert: AON is er, dus het systeem “leeft”, maar de power-up stopt vroeg. Dat past bij een protect- of overload scenario: een regulator probeert, detecteert een fout, en valt terug.

Je loopt stap voor stap vooruit in de keten en zoekt naar de eerste rail die niet stabiel wordt. Vervolgens doe je een unpowered check naar ground op die rail: niet om op één weerstandwaarde te vertrouwen, maar om te beoordelen of de rail plausibel zwaar belast is ten opzichte van je ervaring met vergelijkbare rails. Het voordeel van deze aanpak is dat je niet meteen het power-path of de USB‑C ingang als hoofdverdachte blijft zien; je hebt nu een stop-punt in de sequence dat je vervolgonderzoek scherp afbakent. De beperking: zonder scope of stroomprofiel blijft het lastiger om “pulsing” hard te bewijzen, maar je hebt wel een richting die consistent is met oorzaak-gevolg.

Voorbeeld 2: “No power” is eigenlijk “main power oké, maar geen zichtbare boot”

Een tweede case: de gebruiker zegt “dood”, maar noemt ook: “Hij werd warm in mijn tas” en “soms voelt het trackpad anders.” Jij neemt dat serieus als signaal dat er mogelijk wél activiteit is. Je meet en ziet dat meerdere rails die niet in AON horen wél aanwezig zijn en blijven. Daarmee verschuif je je classificatie van “geen input” of “sequence start niet” naar: main rails zijn waarschijnlijk up.

Nu gebruik je power-up volgorde als afbakening: als main rails stabiel zijn, is het minder logisch om te blijven graven in het vroegste AON/ingangsgebied. Je redeneert dat de klacht “no power” in klanttaal kan betekenen: geen beeld, geen login, geen reactie op toetsen, of geen laadindicatie. In een serviceworkflow is dat verschil belangrijk: je documenteert dat “power rails aanwezig lijken” en dat de failure mogelijk later in de keten zit (bijv. een rail die onder load dipt, of een subsystem dat boot blokkeert).

De impact van deze aanpak is vooral organisatorisch: je voorkomt onnodige acties die gericht zijn op “aan krijgen” terwijl het apparaat al “aan” is op power-niveau. Je communiceert helderder: “Het apparaat neemt power en bouwt rails op, maar bereikt geen gebruikerszichtbare state.” De beperking blijft dat je zonder dedicated meetmiddelen minder zicht hebt op transient dips en power-good sequencing tijdens boot, maar je hebt wel de juiste diagnostische categorie gekozen—en dat is vaak 80% van de tijdwinst.

De kern in één strak diagnostisch beeld

Je beste diagnose bij Apple Silicon no-power klachten komt zelden uit één meetpunt. Je wint door rails in volgorde te interpreteren en steeds te vragen: “Welke stap zou nu waar moeten zijn?” en “Wat verhindert de volgende stap?”

Belangrijkste takeaways:

  • Classificeer eerst: geen input vs AON-only vs vroeg-stop vs main rails oké maar geen user-feedback.

  • Meet oorzaak vóór gevolg: 0 V op een laag in de keten zegt weinig als enable/PG ontbreekt.

  • Pas op voor multimeter-blindheid: korte pulsen en load-dips kunnen “0 V” lijken.

  • Werk naar een stop-punt: “hier stopt sequencing” is waardevoller dan “rail X is 0 V”.

This sets you up perfectly for USB‑C PD, laadpad & controlfuncties [35 minutes].

Last modified: Wednesday, 4 March 2026, 8:21 AM