Waarom “no power” soms gewoon “slaapt” is

Je krijgt een MacBook binnen met de klacht: “Hij doet helemaal niks.” De klant zegt dat hij gister nog werkte, vandaag geen beeld, geen geluid en het lijkt alsof er geen reactie is op de aan/uitknop. Jij sluit een USB‑C adapter aan, ziet weinig of wisselende stroomopname, en de verleiding is groot om direct te denken aan PD, power path of een defect logic board.

Maar bij Apple Silicon komt een verrassend deel van dit soort tickets neer op toestanden: het systeem kan in sleep, in een mislukte wake, of “logisch dicht” staan doordat de lid-chain (de keten die bepaalt of de klep open/dicht is) of andere wake‑voorwaarden niet kloppen. Dan lijkt het voor de klant “dood”, terwijl de power-keten misschien wél (gedeeltelijk) leeft.

Deze les leert je hoe je sleep/wake, lid‑chain en indicatoren gebruikt als diagnostisch instrument. Het doel is niet “gokken”, maar razendsnel bepalen: probeert het systeem te ontwaken en faalt het, of komt het niet eens tot die stap? Daarmee voorkom je dat je vroeg in het traject dure board-hypotheses kiest, terwijl het gedrag eigenlijk een state/trigger-probleem verraadt.

Taal die je team hetzelfde laat meten: sleep/wake, lid-chain en indicatoren

Sleep is een toestand waarin het systeem grotendeels “uit” lijkt, maar AON (Always‑On) blijft actief zodat wake-events herkend kunnen worden. Bij Apple Silicon is dit geen simpel “S3 zoals vroeger”; het is een gecontroleerde toestand met voorwaarden en checks. Daardoor kan “geen reactie” betekenen: geen wake‑event, wake‑event wel gezien maar direct afgebroken, of wake lukt maar display blijft uit.

Wake is het moment waarop het systeem van AON naar meer rails/enables gaat: het vraagt kort of langer om extra power, controleert safety/fault condities, en probeert door de sequence te gaan. Dit sluit direct aan op het ketenmodel uit eerdere lessen: Input → AON → sequencing → rails → power-good → SoC boot. Sleep/wake is vooral het stuk “tussen” AON en het écht opstarten: je ziet vaak korte pogingen (pulsjes) of juist een compleet gebrek aan poging.

Lid-chain is de groep signalen/sensorinformatie die bepaalt of de klep open is en of wake überhaupt logisch is. Denk aan: “is lid open?”, “is er een wake‑trigger toegestaan?”, en “moet het systeem in clamshell-achtig gedrag blijven?”. Je hoeft geen specifieke sensors te memoriseren om er diagnostisch voordeel uit te halen: het gaat om het principe dat een verkeerde lid-status een perfect no‑power masker kan zijn.

Indicatoren zijn alle indirecte signalen die je vertellen in welke state de machine zit: stroomopnamepatronen, herhaalbaarheid van pogingen, subtiele warmte, trackpad-klikgevoel (haptics), externe display-reactie, en consistent gedrag bij herhaald aansluiten. Belangrijk: dit is geen “gokken op gevoel”; dit is het observeren van een toestandsmachine zonder scope. Je gebruikt indicatoren om te bepalen of je met geen poging, korte wake‑pogingen met protectie‑terugval, of wake zonder zichtbare output te maken hebt.

Sleep/wake als diagnosehefboom: “geen poging” versus “wel poging”

Sleep/wake-diagnose begint met één harde vraag: zie je evidence van een wake‑attempt? Dat klinkt eenvoudig, maar hier gaat het vaak mis doordat technici alleen “spanningen op rails” willen meten. Bij Apple Silicon kan een wake‑attempt zo kort zijn dat je multimeter downstream vooral 0 V laat zien, terwijl er wel degelijk een enable/rail‑puls was. Dat is precies de valkuil die je eerder zag: 0 V is vaak gevolg, niet oorzaak, zeker als bescherming de sequence snel terugtrekt.

Als je wél pogingen ziet, interpreteer je het als: AON is aanwezig, input is acceptabel genoeg om een poging te doen, en de control logica durft te starten. Dan denk je in termen van protect shutdown, overload, undervoltage onder load, of een fault die tijdens wake-checks opduikt. Je vervolgstap is niet “random rails meten”, maar het stop‑punt lokaliseren: waarom valt de poging terug naar AON? Dit is precies de oplossingsgerichte mindset uit de vorige les: protectie is vaak een teken van leven.

Als je géén pogingen ziet, schuift je hypothese naar: wake‑event wordt niet gegenereerd of niet geaccepteerd. Hier komen lid-chain en state-voorwaarden in beeld. Een apparaat kan “dood” lijken omdat het logisch in sleep blijft en geen geldige wake‑trigger krijgt (of denkt dat de klep dicht is). Het gevaar is dat je dit verwart met “geen input/geen AON”, terwijl het in werkelijkheid een state lock is. Daarom is gedragstest en herhaalbaarheid essentieel: hetzelfde “niets” bij verschillende prikkels (adapter, power button, lid open/dicht, externe periferalen) vertelt je iets over de toestandsmachine.

Een tweede pitfall is tunnelvisie: “als PD goed is, moet hij booten.” PD kan prima slagen, maar wake kan alsnog geweigerd worden door interne voorwaarden of door protectie tijdens de eerste sequenced rails. Je bewaakt dus altijd de keten: PD/ingang zegt alleen dat energie beschikbaar is, niet dat de machine besluit die energie door te zetten naar full wake.

Lid-chain: hoe een ‘dichte klep’ een perfect no‑power masker wordt

De lid-chain is diagnostisch interessant omdat hij aan de voorkant van “menselijke interactie” zit: de gebruiker opent de klep en verwacht een wake. Als de machine intern “lid closed” denkt, kan hij zich gedragen alsof er geen power is: geen wake bij openen, soms ook minder respons op toetsen/trackpad, en een zeer minimalistisch energieprofiel. Voor de klant is dat indistinguishable van “kapot”.

Wat maakt dit bij Apple Silicon extra verraderlijk? De power chain is een toestandsmachine met gates. Lid-status is zo’n gate: het beïnvloedt of wake-events als geldig worden gezien en of bepaalde output (zoals display) logisch wordt geactiveerd. Daardoor kun je in een situatie belanden waar AON prima draait, maar de machine geen zichtbare indicatie geeft omdat hij niet “mag” of “wil” waken. Als je dan alleen op rail-metingen vertrouwt, kun je in cirkels blijven meten zonder duidelijke conclusie.

Best practice: behandel lid-chain als een beslissingsvoorwaarde, net zoals je PD en power path als voorwaarden behandelt. Je zoekt naar consistentie: verandert het gedrag wanneer je de gebruiker-interactie simuleert (lid open/dicht, power button timing), of blijft het exact hetzelfde? Een lid-chain probleem geeft vaak state-consistent gedrag: de machine blijft zich “alsof dicht” gedragen, ongeacht hoe vaak je probeert te waken.

Veelgemaakte misvatting: “als het display zwart is, is het no power.” Lid-chain issues kunnen ook leiden tot wake zonder zichtbaar beeld (bijvoorbeeld omdat het systeem niet naar het interne panel schakelt of omdat backlight/beeld niet geactiveerd wordt terwijl de rest wél wakker is). Daarom koppel je lid-chain altijd aan indicatoren: stroomopnamepatroon, warmtepunten, en eventuele tekenen van activiteit. Je hoeft daarbij geen schema te memoriseren; je moet vooral leren welke observaties jou vertellen dat de machine ‘in leven’ is maar in de verkeerde state zit.

Indicatoren die je mag vertrouwen (en wat ze wél/niet bewijzen)

Indicatoren zijn jouw “scope-loze telemetrie”. Ze zijn krachtig, zolang je ze niet als bewijs van één specifiek component gebruikt. Het doel is state-classificatie: in welke fase van de keten zit het gedrag? Vooral bij no‑power tickets is dat winst, omdat je daarmee voorkomt dat je te vroeg het logic board “verdacht” maakt.

Hier is een praktisch overzicht van indicatoren en hun betekenis in termen van de keten. Let op: elke indicator is probabilistisch; je zoekt combinaties en herhaalbaarheid.

Indicator Past het best bij… Waarom (keten-denken) Waar mensen zich vaak in vergissen
Herhaalbare korte stroompulsen bij aansluiten of power button Wake-attempt → protect shutdown AON start een poging, sequenced rails komen heel even op, dan grijpt een fault/safety check in en alles valt terug. “Ik meet 0 V, dus er is geen enable.” De enable kan gepulst hebben en alweer weg zijn.
Vrijwel vlakke, lage stroom zonder ritme of poging Geen wake-event / gate dicht óf geen bruikbare input Ofwel komt het systeem niet voorbij de eerste voorwaarden, ofwel wordt wake niet getriggerd/ingeaccepteerd (bijv. lid-chain). “Board is dood.” Je hebt nog niet bewezen of het ‘geen poging’ is door input, of door logische voorwaarden.
Gedrag verandert met lid open/dicht (soms wel tekenen, soms niet) Lid-chain / wake-voorwaarden Een state-voorwaarde beïnvloedt of wake logisch is; variatie met lid is een sterke hint naar die keten. “Random probleem.” Variatie is juist informatie: welke prikkel verandert het state-besluit?
Warmte die kort verschijnt op vaste plek en dan weer weg Wake-attempt met snelle shutdown Een rail of load komt heel even op; protectie trekt terug. Warmte is tijd-afhankelijk en past bij pulsing. Warmte als “bewijs van defecte chip.” Het bewijst vooral activiteit, niet de root cause.
Externe tekenen van activiteit zonder beeld Wake gelukt, output niet (displaypad/lid/beeldpad) De keten kan verder zijn dan je denkt; no-power is dan mislabeling. “Geen beeld = geen power.” Je moet state en output loskoppelen.

Een belangrijke discipline: documenteer indicatoren als patronen, niet als losse feiten. “Pulsing elke X seconden” (of: “altijd dezelfde poging bij elke reconnect”) is veel waardevoller dan “hij doet niks”. Dit helpt ook in teamoverdracht: collega’s kunnen direct herkennen of ze moeten zoeken naar gating, protectie, of output‑issues.

Een compacte beslisroute: state eerst, rails daarna

Wanneer je sleep/wake en lid-chain meeneemt, verandert je volgorde van denken. Je gaat niet meteen diep in sequenced rails; je classificeert eerst de state, zodat je metingen betekenis krijgen. Hieronder is een eenvoudige route die past in de ketenbenadering uit de eerdere lessen.

  1. Bevestig input als uitgangspunt: zonder bruikbare input is sleep/wake analyse ruis. PD/ingang is je “energie beschikbaar?”-vraag, niet je “boot?”-vraag.
  2. Zoek evidence van AON/attempt: pulsen, herhaalbaarheid, subtiele warmte, of enige vorm van “probeert iets”.
  3. Koppel attempt aan interpretatie: attempt → denk protect/fault; geen attempt → denk wake-trigger/gates (waar lid-chain een hoofdverdachte is).
  4. Pas dán gerichte metingen: als je hypothese protect shutdown is, meten op willekeurige downstream rails zonder timing-context levert nauwelijks nieuwe informatie. Je zoekt het eerste stop-punt in de sequence, niet alle 0V’s.

[[flowchart-placeholder]]

Dit is ook de brug naar oplossingsgericht werken: je kunt nu betere vragen stellen en sneller isoleren. Bijvoorbeeld: “Was hij dichtgeklapt in een tas?”, “Gebeurde het na lang slapen?”, “Is er ooit een moment geweest dat hij ‘wakker’ leek zonder beeld?” Dat zijn geen ‘klantpraatjes’, maar hypothese-data voor state-diagnose.

Voorbeeld 1: “Helemaal dood” na een weekend blijkt een mislukte wake-state

Een MacBook komt binnen: klant zegt dat hij hem vrijdag dichtklapte, maandag doet hij “niks meer”. Met adapter aangesloten zie je een lage, grotendeels vlakke stroomopname. De klant heeft al meerdere adapters geprobeerd en noemt het “no power”. Dit is precies waar je sleep/wake-denken tijd wint: je zoekt eerst naar poging versus geen poging, en pas daarna naar componenten.

Stap voor stap kijk je naar het patroon. Je herhaalt aansluiten en probeert een wake-trigger (power button, lid bewegen) en let op herhaalbaarheid. Stel dat je af en toe een minieme puls ziet maar niet consistent: dan past dat bij een systeem dat wel uit AON wil komen, maar snel terugvalt. In keten-termen: input is “goed genoeg om te proberen”, AON leeft, maar wake checks of vroege sequencing breken af. Je gaat dan niet meteen “display-rail” of “SoC” roepen; je rapporteert: wake-attempt aanwezig, early abort.

De impact van deze interpretatie is groot voor je workflow. Je voorkomt dat je dit als “geen input” classificeert en uren verliest aan PD-herhaling. Je zet het ticket in de categorie protect/shutdown of wake-fail en documenteert indicatoren (“korte poging bij elke tweede reconnect”, “warmte kort op vaste plek”). De beperking: zonder scope weet je niet exact welke enable eerst valt, dus je blijft strikt: je claimt geen component, alleen het stop‑punt in de state machine.

Voorbeeld 2: Zwart scherm bij openklappen, maar wel tekenen van leven — lid-chain als verdachtmaker

Een andere case: klant zegt “geen power”, maar beschrijft ook dat hij soms een heel subtiel trackpad-gevoel heeft en dat de machine warm kan worden in de tas. Bij jou op de bank blijft het scherm zwart bij openklappen. Als je alleen op “beeld” zou varen, label je dit als no power. Met de indicator‑bril doe je iets anders: je splitst wake en output.

Je observeert of er aanwijzingen zijn dat wake wél gebeurt: herhaalbare stroomopname die hoger is dan pure AON, lichte warmte die blijft (niet alleen een tik), of gedrag dat verandert met lid open/dicht. Als het gedrag duidelijk correleert met lid-actie—bijvoorbeeld: bij “lid open” zie je een poging of hogere opname, bij “lid dicht” zakt het terug—dan wijst dat op lid-chain/wake-voorwaarden als meespeler. In keten-termen: input+AON zijn aanwezig, wake-logic reageert op lid-status, maar het resultaat is inconsistent of de output blijft uit.

Het voordeel is dat je nu veel scherper kunt communiceren en isoleren. In plaats van “no power” noteer je: device lijkt te waken zonder zichtbaar beeld óf wake wordt beïnvloed door lid-status. Dat is technisch bruikbare informatie voor verdere diagnose en escalatie, en het voorkomt onnodig “board dead” narratief. De beperking blijft dat indicatoren geen schema zijn: je gebruikt ze om de juiste tak van de diagnoseboom te kiezen, niet om het defecte onderdeel te raden.

Je checklist voor ‘slaap vermomd als no power’

  • Kijk eerst naar pogingen: pulsing en herhaalbaarheid zijn vaak het verschil tussen “gate dicht” en “protect shutdown”.

  • Behandel lid-chain als een gate: een verkeerde lid-status kan wake blokkeren of output sturen, zonder dat de power-keten truly dood is.

  • Gebruik indicatoren als state-telemetrie: combineer stroompatronen, warmte en prikkel-respons (lid/power) om je ketenfase te bepalen.

  • Vermijd de 0V-valkuil: downstream 0 V kan perfect passen bij een korte wake‑attempt die door protectie wordt teruggetrokken.

Jouw repeatable diagnosekompas

  • No power = vaak een state-probleem: door sleep/wake als toestandsmachine te benaderen, onderscheid je “inert” van “probeert maar valt terug”.

  • Lid-chain bepaalt of wake logisch is: een ‘dichte klep’-status kan alle zichtbare tekenen van leven maskeren, zelfs met gezonde AON.

  • Indicatoren zijn geen bijzaak: herhaalbare stroompulsen, warmte en prikkel-respons geven je zonder scope tóch betrouwbare fase-informatie.

  • Meet pas diep als je fase klopt: eerst classificeren (input/AON/attempt), daarna pas rails en power-good gericht interpreteren.

Als je dit consequent toepast, ga je sneller van “hij doet niks” naar een scherpe, overdraagbare diagnose: waar in de keten stopt het, en is dat omdat de machine niet wíl waken of omdat hij niet kán waken? Dat is precies het verschil tussen eindeloos meten en doelgericht oplossen.

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