Un HP Omen 16 con scheda madre JPR62 LA-M78AP è arrivato in laboratorio con un guasto particolarmente insidioso: il notebook non completava la sequenza di accensione e non arrivava al POST, nonostante una parte delle alimentazioni principali risultasse presente.

Il problema si era manifestato dopo un precedente intervento effettuato in un altro laboratorio, dove erano stati sostituiti tutti i thermal pad utilizzando anche compound Thermal Grizzly. All'apertura del notebook abbiamo riscontrato tracce del materiale finite in prossimità di innumerevoli componenti della scheda madre. È molto probabile che una contaminazione abbia provocato un corto momentaneo o una dispersione, danneggiando successivamente uno dei circuiti di controllo della motherboard.

Da qui è iniziata una diagnosi tutt'altro che immediata.

Il comportamento iniziale lasciava pensare a un problema nella gestione delle tensioni di standby. I 19 V di ingresso erano regolarmente presenti e le linee da 3,3 V e 5 V comparivano, ma in determinate condizioni cadevano dopo circa dieci secondi. Tenendo invece attivo il circuito di servizio della scheda e premendo il pulsante Power, le alimentazioni rimanevano stabili.

Il primo obiettivo è stato quindi capire se il comando di accensione venisse realmente ricevuto dal controller embedded, l’ENE KB9542Q, il microcontrollore che su questa piattaforma gestisce una parte fondamentale della power sequence. La risposta era positiva. Il segnale del pulsante Power arrivava correttamente all’ENE e il pin di reset del controller risultava stabilmente alto: il chip era quindi alimentato, fuori reset e apparentemente operativo. Ed è proprio questo che ha reso la diagnosi più complessa. L’ENE non era completamente morto. Al contrario, eseguiva correttamente una parte della sequenza: alcuni segnali iniziali, tra cui EC_ON e SPOK, venivano generati regolarmente. La scheda riceveva il comando di accensione e manteneva attive le linee di standby. La sequenza, però, si fermava subito dopo.

Diversi segnali fondamentali per proseguire l’accensione rimanevano fermi a 0 V. Tra questi PCH_PWR_EN, EC_RSMRST#, PCH_DPWROK, ESPI_RST# e PCH_PWROK. Di conseguenza non venivano abilitate correttamente neppure alcune delle tensioni successive, come le linee da 1,8 V, 0,82 V e 1,05 V. Inizialmente il sospetto si è quindi spostato sui regolatori downstream. Sono stati controllati diversi stadi di alimentazione, verificando ingressi, enable, resistenze verso massa e uscite sulle relative bobine. Uno dei regolatori, ad esempio, riceveva correttamente la tensione di ingresso ma non il segnale di enable. La sua uscita rimaneva quindi a 0 V. Questo dettaglio è stato importante perché ha permesso di escludere un guasto diretto del convertitore: il problema era a monte. Il regolatore non partiva semplicemente perché nessuno gli stava ordinando di partire. Anche la linea da 0,82 V si trovava nella stessa situazione: nessun corto evidente e segnale EN assente.

La ricerca è quindi tornata sulla sequenza logica. Sono stati verificati i reset RTC verso il PCH, entrambi correttamente rilasciati, così come il circuito che gestisce SPOK. Anche in questo caso non è emerso nulla di anomalo. Un’altra pista importante ha riguardato il segnale AC_PRESENT. Sulla scheda risultava basso, un comportamento apparentemente sospetto. Per capire se fosse il circuito esterno a tenerlo a massa oppure l’ENE stesso, il relativo pin del controller è stato fisicamente sollevato dalla piazzola.

La prova è stata molto significativa: con il pin scollegato, la piazzola sulla motherboard saliva regolarmente a circa 3,3 V, mentre il pin dell’ENE rimaneva a 0 V. Era quindi proprio l’embedded controller a tenere bassa quella linea. Questo avrebbe potuto indicare un problema nel riconoscimento dell’alimentatore, ma ulteriori misure hanno escluso anche questa possibilità. Il charger rilevava correttamente la presenza dell’alimentatore e il relativo segnale arrivava all’EC con valori coerenti. Ancora più importante, anche isolando il pin e lasciando salire AC_PRESENT a 3,3 V, la sequenza non avanzava: PCH_DPWROK, EC_RSMRST#, ESPI_RST# e PCH_PWR_EN rimanevano tutti a zero. AC_PRESENT era quindi un effetto del problema, non la causa.

A questo punto il sospetto sull’ENE diventava sempre più concreto. C’era però un’ulteriore difficoltà: non disponevamo dello schema esatto della LA-M78AP, ma di documentazione relativa alla vicinissima famiglia LA-M783P/LA-M782P. Molte connessioni coincidevano, altre no. Per questo ogni informazione ricavata dal CAD è stata progressivamente verificata direttamente sulla scheda attraverso misure di continuità.

Nel frattempo è stata individuata e letta anche la flash BIOS principale, una Winbond W25Q128 da 16 MB. La memoria è stata letta con programmatore RT809F due volte, ottenendo in entrambi i casi lo stesso checksum. Il dump risultava strutturalmente valido: Intel Flash Descriptor presente, regioni firmware coerenti, BIOS HP F.39 e identificativi corretti della piattaforma JPR62. Non c’erano quindi elementi per attribuire il problema a una corruzione evidente del BIOS principale. L’analisi del dump ha però portato a un risultato molto interessante. All’interno dell’immagine da 16 MB è stato individuato un blocco da esattamente 160 KB, contenente codice e riferimenti compatibili con il firmware dell’embedded controller: identificativi della piattaforma JPR62, stringhe relative alla gestione del PCH, sleep/wake, UCSI e diverse routine di controllo tipiche dell’EC. A quel punto il KB9542Q, e non soltanto i circuiti che dipendevano dalle sue uscite, diventava il principale sospettato.

Il comportamento dell’EC era ormai molto caratteristico: il controller era alimentato, riceveva il comando Power, usciva dal reset ed eseguiva una parte della sequenza, ma non riusciva a completarla.

La soluzione definitiva ha confermato il sospetto.

Il chip ENE KB9542Q è stato sostituito con un componente nuovo e la relativa memoria flash interna è stata programmata con il firmware da 160 KB corretto per questa piattaforma.

Dopo la sostituzione e la programmazione, la scheda ha ripreso a completare regolarmente l’intera sequenza di accensione e il notebook è tornato pienamente operativo.

Il caso è interessante soprattutto perché dimostra quanto possa essere fuorviante un embedded controller solo parzialmente danneggiato. Un EC completamente morto è relativamente semplice da individuare. Molto più complesso è un controller che riceve il pulsante di accensione, genera alcune alimentazioni e alcuni segnali corretti, ma si blocca pochi passaggi dopo.

Anche la storia precedente del notebook è stata determinante. Il guasto era comparso immediatamente dopo un intervento sul sistema di dissipazione e la presenza di compound termico finito nell’area dei componenti rende molto plausibile che un corto o una dispersione abbiano danneggiato l’embedded controller. Non è possibile stabilire retroattivamente quale contatto abbia provocato il danno, ma la correlazione temporale e le condizioni riscontrate sulla scheda sono difficili da ignorare.

La riparazione finale è stata: sostituzione ENE KB9542Q + programmazione del firmware EC da 160 KB.

Una soluzione apparentemente semplice, raggiunta però solo dopo aver escluso alimentazioni, regolatori, reset, riconoscimento dell’alimentatore, BIOS principale e segnali di abilitazione intermedi.