EDV-Dompteur/Forum

Einleitung:

Dell-Netzteile kommen auf der 19V-Seite mit einem dreipoligen Stecker daher.
Das folgende Bild zeigt den Unterschied, im Vergleich zu einem herkömmlichen, zweipoligen Stecker:
Über den filigranen Mittelpin wird ein Datensignal geführt, basierend auf dem 1-Wire-Protokoll.

Das Mainboard fragt aus dem im Netzteil verbauten, seriellen 1kBit-EEPROM (DS2501, DS2502 ...) ein paar Daten ab, interessiert sich dabei aber offenbar nur für eine einzige Information: Der Angabe der Leistung (Watt) des Netzteils.
Diesen Wert vergleicht das Mainboard mit einem im BIOS hinterlegten Wert.
Stimmt beides überein, dann ist die Welt in Ordnung!
Stimmen die Daten aber nicht überein, dann mosert der Rechner, dass das Netzteil nicht erkannt wurde, bzw. nicht kompatibel ist.
Die Folge: Der Akku wird nicht geladen!

Manchmal klappt es mit der Kommunikation zwischen Rechner und dem EEPROM im Netzteil aber nicht so recht.
Mögliche Trivial-Ursachen:

1. Netztei schadhaft (Kabelbruch, oder Mittelpin im Stecker abgebrochen)
   
2. Stromeingangsbuchse schadhaft

Natürlich gibt es darüber hinaus ein paar kompliziertere Fälle, die aber zum Glück selten sind.
Und natürlich kann auch der Akku defekt sein, aber das ist eine ganz andere Baustelle. Im Moment geht es mir nur um jenen Fehler, wo der Rechner sich über das Netzteil beschwert.

Für fortgeschrittene Elektroniker:

Hier hat sich mal jemand ausgiebig mit der Problematik beschäftigt (vier Teile):
Hacking the Dell laptop power adapter
Hacking the Dell laptop power adapter — part II
Hacking a Dell power adapter — part III
Hacking a Dell power adapter — final (not really)

Die darin beschriebene Schaltung zur Nachbildung des programmierten EEPROMs basiert aber leider nicht auf dem unter Elektronik-Bastlern populären Atmel AVR (Arduino), sondern auf dem MSP430G2553.
- Das ist ja quasi Feind-Berührung!

In den Kommentaren des vierten Teils ist aber zum Glück auch folgender GitHub-Link zu finden:
Arduino code for hacking dell charger

Gut, den Arduino-Code hätten wir.
Fehlt noch die nötige Beschaltung. Hier hilft ein netter Russe:
Эмулятор Dallas DS2501 для зарядки ноутбука DELL на attiny13 на 90W и 130W

- Hee, lasst Euch doch von den kyrillischen Zeichen nicht abschrecken!
Da ist doch bloß die Schaltung abgebildet, nebst den nötigen Angaben, wie die Fuse-Bits zu setzen sind! Was wollt Ihr mehr?
Den direkt zu dieser Schaltung zugehörigen Code stellt der gute Mann zwar auch bereit ("Скачать" bedeutet "Download"), aber leider nur als fertig kompillierte Datei, nicht als Quellcode. Naja, mit dem zuvor schon verlinkten Quellcode von GitHub sind wir ja eh bereits bedient.

Die russische Seite verlinkt als Quelle der Weisheit übrigens auf das deutschspariche Mikrocontroller.net, wo die Sache ebenfalls behandelt wird:
Dell Notebook mit fremdnetzteil betreiben GELÖST

Am dortigen Startposing hängt als Attachment auch ein Basic-Quellcode (BASCOM). Damit dürfte nun wirklich jeder bedient sein!

Dell-Netzteile vollständig testen

Mit all diesem Wissen, einmal umgekehrt gedacht, lässt sich natürlich auch ein simples Testgerät bauen, um so ein Dell-Netzteil wirklich vollständig zu überprüfen, also inklusive Abruf der im EEPROM gespeicherten Daten.

Wenn ich mal gaaanz viel Zeit habe, stelle ich dazu eine einfache Lösung vor.
Was mir vorschwebt:

1. Dell-Buchse auf ESP32.
2. Beamen der ausgelesenen Daten aufs Smartphone, in Form von Hexdump und ASCII.
3. Zusätzlich eine OK-Meldung, wenn die Daten mit im Quellcode hinterlegten Referenzstrings übereinstimmen.

Gegenüber den Lösungen mit dem altmodischen ATtiny13, hat der ESP32 natürlich dicke Vorteile.
Kauft man einen mit aufgespieltem Bootloader, dann muss man den nur per USB anschließen, um per Arduino-IDE den Programmcode auf das Dingens zu übertragen.
Dann nur noch auf dem Smartphone eine IP-Adresse eingeben und das Netzteil in die Buchse zum Testgerät einstecken. Fertig!

Das war ja etwas theoretisch eben. Nun mal aus meiner eigenen Werkstatt:
Ich habe hier einen Dell XPS L321X auf dem Tisch, der den Akku nicht lädt, obwohl der Rechner prächtig läuft und im Gerätetest auch keinen Fehler anzeigt. Am Ende des Tests erscheint die frohe Meldung:

Success
All tests passed

Ungeachtet dessen, erscheint in der Ergebnistabelle des Testdurchlaufs aber folgende Zeile:

Der Rechner weiß also keine Details über das Netzteil, obwohl dessen Anwesenheit durchaus erkannt wird.


Ich habe mir das mal mit dem Logic-Analyzer angeschaut, was da auf der 1-Wire Datenleitung passiert.
Blickt bitte etwas unscharf, mit leicht zusammengekniffenen Augen, auf das erste Bild und achtet nicht auf die Zahlen, sondern einzig nur auf die grüne Signalform.
(Die Zahlenwerte stimmen nicht, weil ich da die Parameter noch nicht gut gesetzt hatte.)



Wie wir oben sehen, gibt es vier Datenblöcke (wenn nicht erkennbar, Bild anklicken).
Die ersten drei haben je 7 Byte und der vierte Block besteht aus 8 Byte.

Dargestellt sind im obigen und im folgenden Bild jeweils zwei Signalformen übereinander.
Die untere Form ist die pure Wahrheit - der aufgezeichnete Bitstrom. High- und Lowpegel.
Die obere Form in (beiden Bildern) ist dagegen der Output des 1-Wire-Interpreters meines Logic-Analyzers (der sich im oberen Bild noch verschluckt - egal).

Da zoomen wir jetzt mal rein und schauen uns den ersten dieser vier Datenblöcke genauer an:
(Nachfolgendes Bild anklicken!)



Nun ist auch der Startpunkt für den Interpreter korrekt gesetzt und die ganzen Timingwerte und Dateninhalte stimmen.
Wir erhalten, nach der einleitenden Statsequenz, sieben Byte mit folgenden Hexwerten:
CC F0 08 00 F8 30 34 ... und die letzten Bits verdaut der Interpreter nicht und unterschlägt daher das achte Byte, dessen pure Bitsequenz man unten sieht.

Wie schon erwähnt, haben wir im oberen Bild gleich vier solcher (identischen) Datenblöcke hintereinander. Wobei im vierten und letzten auch das achte Byte vom Interpreter verdaut wird. Dort lautet die Hexadezimalfolge:
CC F0 08 00 F8 30 34 35

Wie wir im vorigen Posting gelernt haben (sofern den Links gefolgt wurde), beginnt die Datenübertragung damit, dass der Master (also der Rechner) den im Ruhezustand anliegenden Highpegel für 480 Mikrosekunden auf Low zieht.
Anschließend geht der Pegel zurück auf High und der Slave (also das EEPROM im Netzteil) zieht anschließend den Pegel wieder auf Low, für mindestens 60 Mikrosekunden.
Schließlich folgt noch eine "Gedenkpause" auf High-Pegel, die hier 500 Mikrosekunden dauert.
Erst dann beginnt die Übertragung der einzelnen Bytes.
Man sieht diese einleitende Startsequenz in beiden Bilden sehr gut, finde ich.

Vor jedem der vier Datenblöcke, die man im oberen Bild erkennt, steht diese eben beschriebene Startsequenz:
- Zunächst ist das Signal High, dann laaaaaaanges Low, wieder High, laaanges Low, dann Gedenkpause auf Highpegel.
Erst dann folgen die eigentlichen Datenbytes.

Aaaber, da stimmt doch was nicht, wir haben im Startposting doch gelernt, dass da noch mehr Bytes kommen müssten!?!
Eben!
- Genau das ist das Problem!

Was passiert da eigentlich?
Nun, mit den ersten fünf Byte bin ich ja noch voll zufrieden:

CC bedeutet, dass der Master den fest eingebrannten ROM-Bereich überspringen möchte.
F0 bedeutet, dass der Master lesend auf das EEPROM zugreifen möchte.
08 00 ist die Adresse, ab der das Auslesen der Daten beginnen soll.
FB ist eine Prüfsumme aus den vorherigen drei Byte, die der Slave (also das EEPROM im Netzteil) selbst generiert und an den Master sendet.

Bis hierhin OK!
Tja, und dann folgen halt zwei Byte (30 34) ... und dann verschluckt sich die Datenübertragung.
Offenbar merkt der Master, dass irgendwas nicht stimmt, stoppt den Lesevorgang und wiederholt die ganze Prozedur, wie es die 1-Wire-Spezifikation ja auch vorsieht.
Insgesamt vier Mal versucht der Master sein Glück (das sind die vier Datenblöcke, im oberen Bild), bis er schließlich aufgibt.


Interessanterweise habe ich hier zwei Netzteile, die genau den gleichen Fehler produzieren. Eines davon ist ein originales Dell-Netzteil, das andere ist ein kompatibles, vom Fremdhersteller.
Mit beiden Netzteilen erhalte ich im Logic-Analyzer die gleichen Bitsequenzen.
Und beide Netzteile werden vom Rechner zwar als vorhanden registriert, jedoch als "unbekannt" gebrandmarkt.

Offenkundig antworten aber beide Netzteile auf die Leseanforderung des Masters, denn sie senden ja, nach Empfang des Lesebefehls und der Leseadresse vom Master, ganz brav die Prüfsumme (FB) an ihn zurück.

Mit anderen Worten: Der Fehler wird hier nicht an den Netzteilen liegen!
- Dabei war das mein erster Verdacht, weswegen ich das zweite NT überhaupt erst gekauft hatte.
Es liegt hier also am Rechner.
Aber die ganze Elektronik, einschließlich der Strombuchse und ihrem Mittelpin, ist ja offensichtlich in Ordnung, sonst würde nicht so viel plausibler Datenverkehr auf der Leitung stattfinden.
Immerhin antwortet das Netzteil in korrekter Weise, mit korreter Prüfsumme, auf die Leseanforderung des Masters, woraufhin dieser tatsächlich mit dem Auslesen des EEPRM-Speichers beginnt. Doch bei beiden Netzteilen wird die Verbindung nach den ersten zwei gelesenen Bytes unterbrochen, woraufhin der Master alles bisher geschehene neu anleiert - insgesamt vier Mal.

Fazit: Wir haben es hier mit einem Softwareproblem zu tun!
Und zwar rechnerseitig.
Hauptverdächtiger ist eindeutig der Embedded Controller. Denn der ist es, der mit dem EEPROM im Netzteil per 1-Wire kommuniziert.

Wahrscheinlich wird ein BIOS-Update Abhilfe schaffen, aber eventuell nur ein solches, das man per Windows, oder per USB-Stick, einspielt. Also kein solches, das man nicht per Programmiergerät ins BIOS-EEPROM kokelt.
Denn per Windows, bzw. per USB-Stick, wird mit guter Wahrscheinlichkeit auch der Embedded Controller neu programmiert (ganz sicher bin ich mir aber nicht, das ist geräteabhängig).
Schlimmstenfalls muss ich dem EC himself direkt per Programmiergerät auf die Pelle rücken. Das wird dann garantiert helfen.

Ich werde später vom Ergebnis berichten!