USB‑C PD, laadpad & controlfuncties

Wanneer “no power” eigenlijk een USB‑C/charging‑beslissing is

Een klant zegt: “Hij is dood.” Jij sluit een USB‑C adapter aan en ziet… niets. Geen beeld, geen geluid, geen laadindicator. Bij Apple Silicon is dat moment verraderlijk: het kan écht “geen power” zijn, maar het kan óók betekenen dat de Mac geen geldige USB‑C PD contract krijgt, dat het laadpad (power path) de energie niet doorlaat, of dat controlfuncties (detectie, protectie, enable) bewust de boel tegenhouden.

Waarom dit nu belangrijk is: als je in deze fase meteen naar “PMIC/SoC defect” springt, sla je de oorzaak vaak over. USB‑C is niet zomaar “5 volt erop en klaar”—er zit communicatie, rolkeuze, protectie en gating tussen. In veel no‑power cases is je snelste winst: bewijzen of het board überhaupt een geldige ingang krijgt en of die ingang door de power path heen mag.

In deze les leg je een mentaal model aan voor drie dingen die je als technician moet kunnen scheiden:

• USB‑C PD onderhandelen (krijgen we een geldig contract?)

• Laadpad / power path (komt die energie daar waar hij moet zijn?)

• Controlfuncties (wie beslist “ja/nee” en waarom?)

De bouwstenen: PD, power path en “wie houdt de deur dicht?”

USB‑C Power Delivery (PD) is het protocol waarmee adapter en device afspreken welke spanning/stroom er geleverd wordt. Zonder PD kan er nog steeds basisstroom lopen (vaak 5 V), maar bij MacBooks is “genoeg om echt te starten/te laden” vaak afhankelijk van een correcte onderhandeling en de juiste rolverdeling. Denk daarom niet in “adapter werkt of niet”, maar in “contract ja/nee en contract passend bij de requested power”.

Het laadpad (power path) is het deel van de hardware dat beslist hoe energie naar het systeem gaat: van USB‑C naar systeemrails, naar de accu, of beide. In dat pad zitten typisch detectie, current‑sense, MOSFET‑gates en protectie. Zelfs met een perfect PD‑contract kan het power path de boel blokkeren als er een fault gezien wordt (overcurrent, undervoltage, temperatuur, kortsluit‑indicaties).

De controlfuncties zijn de “poortwachters” waar de vorige les al op hintte: enables, faults en power‑good voorwaarden bepalen of de machine voorbij “input aanwezig” komt. De key verbinding met power sequencing is: USB‑C/charging vormt vaak de allereerste voorwaarde voor de always‑on domeinen om stabiel te blijven en voor sequencing om überhaupt te starten. Je onderzoekt dus niet alleen “staat er spanning”, maar ook “wordt spanning geaccepteerd en doorgegeven”.

USB‑C PD: van “er zit een stekker in” naar een geldig power‑contract

PD is in diagnose vooral nuttig als denkraam: een no‑power klacht kan al misgaan vóórdat er iets op rails zichtbaar is, simpelweg omdat er nooit een acceptabel contract ontstaat. In de praktijk zie je dan gedrag dat lijkt op “geen input”: weinig tot geen stroomopname, geen duidelijke warmte, en geen opbouw van vervolgrails. Het gevaar (pitfall) is dat je dit verwart met een dood board, terwijl het eigenlijk een communicatie- of rolprobleem is tussen adapter, kabel, poort en de PD‑controller.

Belangrijk om te snappen: PD is een onderhandeling met voorwaarden. Niet elke kabel is gelijk, niet elke adapter kan elke modus, en niet elke port‑combinatie gedraagt zich identiek. Een borderline kabel kan bijvoorbeeld nog wel 5 V “present” hebben, maar instabiel zijn voor data/CC‑communicatie; het resultaat is een device dat nooit verder komt dan een minimale state en daarom “dood” oogt. Een best practice is daarom om PD altijd te benaderen als: (1) detectie → (2) advertentie → (3) acceptatie → (4) leveren. Als één stap faalt, is je downstream meting vaak misleidend: sequenced rails blijven uit omdat de startvoorwaarde nooit gehaald is.

Een tweede typische misconceptie is: “Als er 5 V op USB‑C staat, dan is input oké.” Voor Apple Silicon is 5 V vaak slechts het begin; de machine kan alsnog weigeren te starten als het vermogen niet toereikend is of als de power path protectie triggert wanneer er load gevraagd wordt. Dit is precies de multimeter‑blindheid uit de vorige les: met een multimeter zie je misschien wel 5 V, maar je ziet niet of de boel onder load inzakt of of het contract steeds reset. Daarom combineer je PD‑denken met sequencing‑denken: Input aanwezig is pas “waar” als het ook stabiel en bruikbaar is voor de volgende toestand (AON en verder).

Laadpad / power path: energie mag pas door als de voorwaarden kloppen

Het laadpad is waar “USB‑C levert iets” verandert in “het board krijgt bruikbare energie”. Conceptueel kun je het pad zien als een reeks deuren: een deur voor inbound power, een deur voor accu‑koppeling, en soms een deur voor system‑rail voeding. Controlfuncties bepalen of die deuren open gaan. Als ergens een faultconditie optreedt, kan het pad bewust sluiten: dat levert het symptoom “no power”, terwijl er technisch gezien wél een adapter aanwezig is.

De diagnostische waarde zit in oorzaak-gevolg: als PD wél lijkt te lukken maar het board blijft “AON‑loos” of valt direct terug, dan verschuift je hypothese van “geen contract” naar “contract oké, maar power path blokkeert/klapt in.” Dit past naadloos in de rubricering uit de vorige les: je zoekt waar de keten stopt—nu alleen nog eerder in de keten dan veel technici verwachten. Een pitfall is om te snel naar latere rails te meten; als het laadpad de energie niet doorlaat, zijn die metingen voorspelbaar 0 V en geven ze je geen nieuwe informatie.

Een derde misconceptie: “De accu is alleen relevant als je op batterij test.” Op MacBooks kan een accu‑state (te diep ontladen, protectie, disconnect) invloed hebben op hoe het power path zich gedraagt aan de adapter. Sommige designs verwachten een bepaalde batterijstatus of laten bepaalde rails pas opkomen als de battery interface coherent is. Je hoeft hiervoor geen schema uit het hoofd te leren; je gebruikt wel het juiste denkmodel: adapter input en battery input zijn twee bronnen, en het power path beslist hoe ze elkaar beïnvloeden. Als je één bron uitsluit (bijv. alleen adapter) en gedrag verandert drastisch, is dat diagnostisch vaak waardevoller dan twintig railmetingen “later in de show”.

Controlfuncties: dezelfde keten, maar nu toegepast op USB‑C/charging

Controlfuncties koppel je het best aan de oorzakelijke keten uit de vorige les: Input → AON → Enable → Rail → PG → volgende rail. In USB‑C/charging context betekent dat: voordat AON stabiel blijft, moeten er beslissingen vallen over valid input en faults. En voordat het laadpad energie kan doorgeven, moeten bepaalde “alles is veilig” signalen (fault‑lijnen, current‑limit logic, thermal checks) positief staan. Het gevolg: je kunt een board hebben dat technisch leeft (AON probeert), maar door een control‑beslissing steeds terugvalt—en met een multimeter lijkt het alsof er niets gebeurt.

Best practice: behandel controlfuncties als “waarom zegt het systeem nee?” in plaats van “welk onderdeel is defect?” Als je ziet dat er pogingen zijn (korte stroompuls, kortstondige warmte, herhaalbaar patroon), dan is je hoofdvraag: komt dat door protectie (bewust uit) of door onvermogen (kan niet aan)? Hier zit een klassieke valkuil: technici verwarren “protect shutdown” met “dood IC”. Protect shutdown is juist vaak een teken dat het systeem functioneert en zichzelf beschermt. Je bent dan op zoek naar de eerste oorzaak die protectie activeert: een overload, een rail die instort, of een input die niet stabiel is.

Nog een pitfall is “0 V = geen enable.” Soms klopt dat (enable blijft laag), maar soms is enable wél hoog en schakelt het pad razendsnel weer uit. Zonder scope mis je die puls. Daarom blijft de discipline uit de vorige les gelden: je probeert niet meteen te repareren; je lokaliseert het stop‑punt. Bij USB‑C/charging is dat stop‑punt vaak een van deze drie:

• Geen geldig contract (PD faalt)

• Contract oké, maar power path blokkeert

• Power path opent, maar protectie sluit door load/fout

Snel onderscheid maken: PD-probleem, power-path blokkade, of vroeg-stop door fault

Onderstaande tabel helpt je om observaties te vertalen naar een werkhypothese. Zie het als praktische “triage” vóór je de rest van het board verdenkt.

Twee werkplaatsvoorbeelden: hoe je PD en laadpad “in de keten” leest

Voorbeeld 1: “Laadt niet, dus geen input” blijkt een PD/CC‑probleem

Je krijgt een MacBook met “doet niks en laadt niet”. De klant zegt dat andere apparaten “wel laden” op dezelfde adapter, dus iedereen denkt: adapter is oké, board is dood. Jij pakt het sequencing‑model erbij en stelt een andere eerste vraag: krijgt deze Mac een bruikbare input‑voorwaarde, of faalt de onderhandeling? Je wisselt gecontroleerd één variabele per keer (andere kabel, andere adapter, andere poort), omdat PD een keten is waarin elk onderdeel kan degraderen zonder volledig “kapot” te zijn.

Stap voor stap kijk je naar het patroon: met kabel A gebeurt niets; met kabel B zie je wél een korte reactie (bijv. een minieme stroomopname of een gedrag dat net anders “aanvoelt”). Dat verschil is goud: het vertelt je dat het board waarschijnlijk niet volledig dood is, maar gevoelig is voor de kwaliteit van de PD‑communicatie. In termen van de vorige les: je probeert “Input aanwezig” waar te maken, maar je ziet dat die voorwaarde niet stabiel gehaald wordt. Je noteert dit als: symptoom is consistent met PD handshake/CC pad, niet met “PMIC defect”.

De impact: je bespaart tijd en voorkomt onnodige board‑interventies. De beperking: zonder meetapparatuur voor PD‑states zie je de onderhandeling niet letterlijk; je werkt daarom hypothese‑gedreven met gecontroleerde variatie. Je eindigt met een scherpere conclusie dan “no power”: “no power door geen bruikbare USB‑C PD input in deze configuratie”. Dat is precies het soort taal dat je diagnose reproduceerbaar maakt voor collega’s en escalaties.

Voorbeeld 2: PD lijkt oké, maar het laadpad klapt dicht bij load (protect/overload)

Een tweede case oogt hetzelfde (“volledig dood”), maar nu merk je iets anders: bij aansluiten is er soms een korte “poging” en daarna weer stilte. Dat past bij het patroon uit de vorige les: sequencing start en stopt vroeg, maar omdat de puls kort is misleidt een multimeter je snel naar “alles is 0 V”. Jij vertaalt dit nu naar USB‑C/charging taal: PD kan best lukken, maar zodra het board load vraagt, triggert een protectie of een overload en sluit het power path.

Je pakt het aan als stop‑punt analyse. Eerst bevestig je dat dit geen pure PD‑fail is door te kijken of het gedrag consistent verandert met poort/kabel—bij een pure handshake‑fail is het vaak hard “nee” zonder pogingen. Daarna ga je in je hoofd de deur‑metafoor langs: input komt binnen, AON probeert, een deur gaat even open, en dan grijpt protectie in. Dat maakt je volgende stap gericht: je zoekt niet naar “random rails”, maar naar de eerste stap waar stabiliteit ontbreekt. Je combineert observaties (pulsing‑achtig gedrag) met unpowered checks zoals “is er een rail die plausibel zwaar belast is?”—niet als magisch ohm‑getal, maar als consistentie met het protect‑patroon.

De winst: je onderscheidt “geen power” van “protect shutdown”. Organisatorisch helpt dit enorm: je kunt rapporteren dat het systeem actief probeert te starten en daarom waarschijnlijk niet in de categorie “geen input / volledig dood” valt. De beperking blijft dat je zonder scope de exacte puls niet ziet; je bouwt je chain‑of‑evidence op via herhaalbaarheid, gedrag onder variatie, en het sequencing‑stop‑punt. Dat is precies de discipline die no‑power diagnose bij Apple Silicon sneller en minder gok‑gedreven maakt.

De essentie om mee te nemen (en hoe het past in je workflow)

USB‑C/charging diagnose is geen los eiland; het is de vroege voorkant van dezelfde oorzaak‑gevolg keten: Input → AON → Enable → Rail → PG. Als je dit goed leest, voorkom je twee dure fouten: een board “dood” verklaren dat alleen geen contract krijgt, of eindeloos rails meten terwijl het power path de deur dicht houdt.

Belangrijkste takeaways:

• PD is een voorwaarde, niet alleen een stekker: zonder bruikbaar contract kan het hele board “0 V” lijken.

• Power path is gating: zelfs met input kan het systeem bewust blokkeren door protectie/valid checks.

• Controlfuncties verklaren ‘pogingen’: pulsing of vroege stops wijzen vaak op protect/overload, niet meteen op een “dode” PMIC/SoC.

• Meet en redeneer oorzaak vóór gevolg: als de input/doorlaat niet klopt, zijn downstream railmetingen meestal ruis.

This sets you up perfectly for Accu, bescherming & communicatie [30 minutes].