Reparatur eines Elgato-HD60-S-HDMI-Capture-Geräts mit Ghidra
(downtowndougbrown.com)- Die per USB nicht mehr erkannte Elgato Game Capture HD60 S funktionierte für HDMI-Capture und Passthrough wieder normal, nachdem drei Power-ICs ersetzt wurden, die die Versorgungsschienen herunterzogen
- Per Wärmebild, Spannungsmessungen und SMD-Markierungssuche wurden zwei Fitipower FP6373A-Regler und ein TI TPS60403DBV-Spannungsinverter identifiziert; die Bauteile kosteten bei LCSC zusammen weniger als 1 Dollar
- Die Capture-Funktion war wiederhergestellt, doch die sieben weißen und sieben roten Status-LEDs blieben aus; per direkter Ansteuerung mit einem Raspberry Pi Pico zeigte sich, dass LED-Treiber und LED-Array selbst in Ordnung waren
- Die Analyse der Nuvoton-M031LD2AE-Firmware und des SPI-Flashs für den Cypress/Infineon CYUSB3014 mit Ghidra ergab, dass die ab 0x300000 erwarteten LED-Animationsdaten leer oder beschädigt waren
- Nachdem nur der LED-Datenbereich eines funktionierenden HD60 S in den SPI-Flash des defekten Geräts zusammengesetzt wurde, erwachten die Status-LEDs wieder; der verbleibende Fehler lag nicht in der Hardware, sondern im Software-, Programmier- bzw. Update-Pfad
Reparatur der Stromversorgung eines per USB nicht erkannten HD60 S
- Eine defekte Elgato Game Capture HD60 S USB 3.0, die bei eBay gekauft wurde, zeigte beim Anschließen keinerlei Reaktion am Computer
- Nach dem Öffnen der Platine zeigte eine Spannungsmessung, dass Versorgungsschienen nach unten gezogen wurden; mit einer Wärmebildkamera wurde der heiß werdende Chip gefunden
- Die problematischen Bauteile waren Power-ICs mit nur kleinen Markierungen
- Zwei mit
fiVJVEmarkierte Chips lagen in der Nähe von 2,2-µH-Induktivitäten und wurden daher als Schaltregler vermutet - Über eine SMD-Markierungssuche und Fitipower-Dokumentation wurde dies auf FP6373A eingegrenzt
- Ein mit
PFNImarkierter Chip wurde per Google-Suche als TI TPS60403DBV-Spannungsinverter identifiziert
- Zwei mit
- Alle drei Chips erhielten 5 V am Eingang und hatten niedrigen Widerstand auf der Ausgangsseite; als 2,7 V direkt in die Ausgangsschiene eines FP6373A eingespeist wurden, erhitzte sich dieser Regler
- Der FP6373A war bei LCSC für 0,17 $ pro Stück erhältlich, der TI-Chip für 0,58 $; die Versandkosten lagen deutlich über dem Bauteilwert
Nach dem Bauteiltausch verbleibendes Status-LED-Problem
- Nach dem Austausch der drei Power-ICs wurde der HD60 S als USB-Gerät erkannt, und HDMI-Capture sowie Passthrough funktionierten normal
- Die Statusanzeige des Geräts blieb jedoch weiterhin dunkel
- Es gibt sieben weiße und sieben rote LEDs
- Die weißen LEDs sollten direkt nach dem Verbinden zweimal blinken
- Der LED-bezogene Chip war ein IT1504 von Innochip, laut Datenblatt ein 16-Kanal-LED-Treiber
- Am Oszilloskop war an den Eingangspins des IT1504 serieller Traffic zu sehen, der SPI ähnelte
- Die Leiterbahnverfolgung auf der PCB ergab, dass der IT1504 von einem Nuvoton M031LD2AE ARM-Cortex-M0-Mikrocontroller gesteuert wurde
Suche nach einem IT1504-Ersatz und Prüfung der Schaltung
- Der IT1504 war über normale Distributionskanäle schwer zu bekommen, und Innochip konnte keine Samples schicken, weil der vorhandene Bestand nur in vollständigen Rollen verfügbar war
- Bei der Suche nach einem Ersatz wurde der MBI5040 von Macroblock gefunden
- Das MBI5040-Datenblatt war in Aufbau und Blockdiagramm nahezu identisch mit dem IT1504-Datenblatt
- Die Spezifikation des Ausgangsstroms unterschied sich leicht, Funktion und Befehlsschema waren jedoch sehr ähnlich
- Die Befehlsinformationen im MBI5040-Datenblatt halfen dabei, die LED-Steuerung zu verstehen
- Ein MBI5040GF wurde gekauft und anstelle des IT1504 eingebaut, doch die LEDs blieben weiterhin aus
- Einzeln mit Labornetzteil und Widerstand eingeschaltet zeigte sich: Die LEDs selbst waren in Ordnung
- Als ein Raspberry Pi Pico direkt an die Eingänge des MBI5040 angeschlossen wurde und Befehle sendete, ließen sich die LEDs vollständig steuern
- Damit galt die LED-Treiberschaltung und das LED-Array als physisch intakt
- Auch nach erneutem Einbau des ursprünglichen IT1504 funktionierte die Pico-Steuerung normal, der ursprüngliche LED-Treiber war also ebenfalls nicht defekt
Analyse der Nuvoton-MCU-Firmware mit Ghidra
- Eine Anfrage beim Elgato-Support zu bekannten Problemen oder Einstellungen bezüglich der Status-LEDs brachte keine praktikable Lösung
- Um die Firmware der Nuvoton-MCU zu prüfen, wurde der 4-polige JST-Stecker auf der Platine verfolgt; er erwies sich als Programmieranschluss für die MCU
- Leseversuche mit Nu-Link2-Me und dem NuMicro ICP Programming Tool scheiterten, da der Chipinhalt geschützt war
- Stattdessen wurde die Datei
FW_HD60_S_MCU.binin Elgatos 4K Capture Utility gefunden- Laut
ElgatoDeviceCapabilities.jsonist diese Firmware für Geräte mit USB-Product-ID 0x0076 bestimmt - Elgato bezeichnete dies als „Game Capture HD60 S Rev.4“
- Laut
- Die Binärdatei sah wie Cortex-M0-Firmware aus: Das erste Word
0x20000E70wirkte wie ein gültiger Stack-Pointer, die folgenden Words wie eine Vektortabelle mit Flash-Adressen - Die Firmware wurde in Ghidra geladen, und mit dem SVD-Loader wurde versucht, Register-Mappings zu laden
M031AE_v1.svdaus NuMicro_DFP wurde angepasst, damit es im Plugin geladen werden konnte- Nuvotons M031BSP half bei der Funktionsidentifikation
MCU-Austausch und Entsperrung für das Debugging
- Statt des ursprünglichen M031LD2AE wurde ein neuer leerer Chip eingebaut und mit der Elgato-Firmware geflasht; er funktionierte, wurde danach aber wieder geschützt und ließ sich nicht debuggen
- In Ghidra wurde die Funktion gefunden, die die Schutzkonfiguration aktualisiert, und so gepatcht, dass der Chip nicht gesperrt wird
- Nach dem Aufspielen der gepatchten Firmware konnte der Initialisierungscode mit OpenOCD und GDB debuggt werden
- Der Codepfad zur LED-Steuerung war in der Firmware vorhanden, wurde im normalen Ausführungsfluss jedoch übersprungen
- Als in GDB Register- und RAM-Werte erzwungen wurden, sodass der LED-Steuercode ausgeführt wurde, ließ sich die Beleuchtung einschalten
- Die Firmware enthält LED-Steuercode
- Das Problem war, dass dieser Code unter normalen Bedingungen nicht ausgeführt wurde
Bootloader und vollständiges Firmware-Backup
- Es wurde experimentell versucht, die Firmware mit deaktivierten Schutzbits über Elgatos Update-Pfad auf einem anderen HD60 S zu installieren, um den ursprünglich geschützten vollständigen Inhalt auslesen zu können
- Nach dem Update schien das Gerät nicht mehr als Capture-Karte zu funktionieren, der Chip war jedoch wie beabsichtigt entsperrt
- Dadurch konnten folgende Bereiche ausgelesen werden
- LDROM: Elgatos Bootloader der ersten Stufe
- Data Flash
- ursprüngliche Konfigurationsregisterwerte
- APROM-Anwendungsfirmware
- Der LDROM-Bootloader konnte per I2C Befehle und Daten empfangen und APROM neu flashen
- Wenn der Chip entsperrt ist, springt der Bootloader nicht in die Anwendungsfirmware, sondern wartet auf Update-Befehle
- Elgato nutzte die Sperr-/Entsperr-Bits offenbar als Signal dafür, ob der Bootloader warten soll
- Dieses Verhalten erklärt auch, warum das Gerät nach Installation der entsperrten Firmware hängen blieb
Verständnis der internen Struktur des HD60 S
- Im Gerät arbeiten zwei ARM-basierte Prozessoren zusammen
- Der Cypress/Infineon CYUSB3014-USB-3.0-Peripheriechip ist ein ARM926EJ-S und kommuniziert per USB 3.0 mit dem PC
- Die Nuvoton M031LD2AE Cortex-M0-MCU steuert die ITE-Videochips und die LEDs
- Die Nuvoton-MCU konfiguriert und überwacht die ITE-Chips über einen separaten I2C-Bus
- Der ITE IT6802E scheint ein HDMI-Empfänger zu sein
- Der ITE IT66121FN scheint dafür zuständig zu sein, einen parallelen Datenstrom als HDMI auszugeben
- Der CYUSB3014 sendet Befehle per I2C an die Nuvoton-MCU, und die Nuvoton-MCU gibt Statusinformationen an den CYUSB3014 zurück
- Der CYUSB3014 nimmt den Videodatenstrom vom IT6802E entgegen und leitet ihn per USB an den Computer weiter
- Auf der Platine befindet sich außerdem ein Altera MAX II CPLD, der offenbar daran beteiligt ist, die Videodaten in einer für den CYUSB3014 geeigneten Form bereitzustellen
SPI-Flash und Fund der LED-Animationsdaten
- Die CYUSB3014-Firmware war ungeschützt in einem Winbond W25Q32JVSSIQ 4-MB-SPI-Flash gespeichert
- Beim Blick in den SPI-Flash-Dump fanden sich ab Offset 0x300000 Datenblöcke, die wie kleine Bilder aussahen
- Nachdem fünf zuvor unbekannte GPIOs in der Nuvoton-Firmware verfolgt wurden, stellte sich heraus, dass diese Pins zu einem PI5C3257 quad 2:1 mux/demux bus switch von Diodes Incorporated führten
- Dieser Bus-Switch wählt aus, ob der CYUSB3014 oder die Nuvoton-MCU auf den SPI-Flash zugreift
- Zunächst wurde angenommen, der SPI-Flash gehöre ausschließlich zum CYUSB3014
- Tatsächlich übernimmt nach dem Boot des CYUSB3014 die Nuvoton-MCU die Kontrolle über den SPI-Flash
- Neu in Ghidra identifizierte Funktionen betrafen bitgebangte SPI-Transaktionen sowie Code zum Löschen, Lesen und Schreiben des SPI-Flashs
Die eigentliche Ursache des LED-Defekts
- Die Daten nach 0x300000 im SPI-Flash waren keine gewöhnlichen Bilder, sondern LED-Animationsframes
- Jeder 16-Byte-Block ist ein Animationsframe für die 14 LEDs
- Die letzten 2 Bytes jeder Zeile sind die Verzögerung vor dem Wechsel zum nächsten Frame
- Die Nuvoton-Firmware prüfte, ob die ersten 2 Bytes an der Startposition 0x300000 dem 16-Bit-Wert 0xAA55 entsprechen
- In den SPI-Flash-Dumps zweier Geräte, deren LEDs nicht funktionierten, war dieser Bereich leer oder beschädigt
- In einem Dump war der Bereich 0x300000 fast vollständig mit
0x00gefüllt - Einige Animationen begannen mit merkwürdigen Headern wie
AB 03 12 39
- In einem Dump war der Bereich 0x300000 fast vollständig mit
- Im SPI-Flash eines dritten, funktionierenden HD60 S befanden sich an 0x300000 der korrekte Header und die LED-Daten
- Das erste 16-Bit-Word war das von der Firmware erwartete
0xAA55 - Der Header enthielt Informationen zu 26 LED-Animationen
- Die in den IT1504 geladene Dot-Correction-Daten lagen bei 0x3007F8, und das folgende
0x521114A7war die CRC-32 der vorangehenden 16 Bytes
- Das erste 16-Bit-Word war das von der Firmware erwartete
LED-Wiederherstellung per SPI-Flash-Patch
- Im SPI-Flash des Problemgeräts wurden die gerätespezifischen Daten von 0x000000 bis 0x2FFFFF erhalten
- Denn die USB-Seriennummer war irgendwo in diesem Bereich enthalten
- Nur der LED-Datenbereich ab 0x300000 wurde durch Daten aus dem Dump des funktionierenden Geräts ersetzt, wodurch ein Hybrid-Image entstand
- Nachdem dieses Image auf das Gerät mit defekten LEDs geflasht wurde, blinkten die weißen LEDs zweimal und die roten LEDs leuchteten kurz einmal auf
- Obwohl das funktionierende Gerät eine ältere Revision hatte und auch ein anderes Nuvoton-MCU-Modell verwendete, passten die LED-Daten zu dem Format, das die neue Firmware erwartete
- Auch in den bestehenden Game Capture-Apps für Windows und Mac waren rohe Animationsdaten enthalten
- Der Windows-Pfad lautet
C:\Program Files\Elgato\GameCapture\Animations - Der Mac-Pfad lautet
/Applications/Game Capture HD.app/Contents/Resources/Animations - Wenn die Daten aus Dateien wie
01.ani,02.anientsprechend der LED-Reihenfolge neu angeordnet wurden, stimmten sie mit den Animationsdaten im funktionierenden Flash-Dump überein
- Der Windows-Pfad lautet
Einschränkungen des Update-Tools und des Wiederherstellungsablaufs
- Das Windows-Firmwareupdate von Elgatos 4K Capture Utility wartete nicht lange genug
- Es meldete einen Fehler, obwohl das Update noch lief
- Wartete man einfach weiter, blinkten die Geräte-LEDs und das Gerät startete normal mit der neuen Firmware neu
- Wenn das Gerät direkt nach der Fehlermeldung abgezogen wird, kann ein unvollständig beschriebener Flash zurückbleiben
- Nachdem der Wert
updateDurationSecinElgatoDeviceCapabilities.jsonvon 40 auf 80 erhöht wurde, war dieses Problem behoben - Elgato empfiehlt, Firmwareupdates für den HD60 S nicht durchzuführen, sofern der technische Support nicht dazu auffordert; außerdem ist die Funktion hinter einer speziellen Tastenkombination in den Einstellungen versteckt
- Der LED-Wiederherstellungsablauf ist komplex
ElgatoDeviceCapabilities.jsonbearbeiten, um Firmwareupdates zu erlauben- Direkt nach dem Start des Updates das Gerät abziehen, um zu erreichen, dass der Cypress-Chip den SPI-Flash kontrolliert
- Den PCB-Jumper entfernen, damit der CYUSB3014 per USB bootet
- Mit
download_fx3aus dem Cypress SDKcyfxflashprog.imgin den RAM laden - Mit einem modifizierten
fx3_spitestden gesamten SPI-Flash dumpen und den LED-Bereich patchen - Den Jumper zurücksetzen und mit 4K Capture Utility ein normales Firmwareupdate ausführen, um die Nuvoton-Firmware wiederherzustellen
- Am Ende bestand die ursprüngliche Reparatur aus dem Austausch von drei Chips für weniger als 1 Dollar, und das LED-Problem wurde als software-, programmier- oder updatebezogener Defekt erkannt, der bei manchen HD60-S-Geräten auftritt
1 Kommentare
Hacker-News-Kommentare
Es war schwer, den Zweck innerhalb der Gesamtstruktur zu verstehen, und manches war tief in mehreren Ebenen von Funktionsaufrufen vergraben.
So etwas passiert auch oft, wenn man direkt in den Source Code schaut. Die meiste Software ist übermäßig abstrahiert, und MCUs sind inzwischen so groß und so billig geworden, dass man selbst im Embedded-Bereich Dinge sieht wie zwei ARM-Kerne in einem HDMI-Capture-Gerät. Dieses Gerät hätte vermutlich nicht mehr als eine MCU gebraucht.
Als ich vor etwa 20 Jahren in Indien aufwuchs, war die Kaufkraft gering und Dinge waren teuer, daher wurde fast alles repariert oder überarbeitet und weiterverwendet.
Um Sachen funktionsfähig zu halten, nutzten wir viele Arten von jugaad, also allerlei provisorische Behelfslösungen, und Kleidung wurde wiederverwendet, wobei ein Schneider mit rafu-Flickarbeiten ihre Lebensdauer verlängerte. Das war besonders in Mittelschichtfamilien wie meiner üblich.
Mein Vater, der bei einem Bekleidungsexporteur arbeitete, sagte oft, dass Menschen im Westen Einwegprodukte und neue Dinge bevorzugen würden, egal ob Autos, Elektronik oder Kleidung. Damals konnte ich diese Denkweise nicht verstehen. Aber inzwischen, mit gestiegener Kaufkraft und dank China gesunkenen Preisen, neigen auch wir eher dazu, Dinge einfach wegzuwerfen und neu zu kaufen.
Ich habe großen Respekt vor Menschen, die nicht aufgeben und nicht einfach davon ausgehen, dass Neukaufen immer der leichtere Weg ist. Diese Hartnäckigkeit und Ressourcenorientierung verdient wirklich Anerkennung.
Wenn man es selbst reparieren kann und an die nötigen Teile kommt, ist das in Ordnung. Aber wenn man für die Erfahrung und das Wissen anderer bezahlen muss, ist das zumindest dort, wo ich lebe, ziemlich teuer, und es ist schwer, überhaupt jemanden zu finden, der etwas repariert. Man sieht viele leerstehende Läden mit alten Fernsehreparatur-Schildern davor.
Zum Glück bin ich halb im Ruhestand und werde stundenweise bezahlt, daher hat meine zusätzliche Zeit keinen Geldwert. Ich kann also einen Tag damit verbringen, einen Geschirrspüler zu reparieren, und wenn er ein paar Tage später wieder kaputtgeht, kann ich noch einen Tag darauf verwenden, ein neues Gerät einzubauen. Ein professioneller Installateur hätte das neue Gerät wahrscheinlich in einer Stunde eingebaut, aber ich musste wenigstens nicht auf einen Termin warten.
Erst in den letzten etwa 50 Jahren ist der Konsumismus stärker geworden, und Qualität wie auch Preise von Dingen wie Kleidung sind gesunken.
In letzter Zeit mache ich die Wartung meines Motorrads selbst; anfangs braucht man dafür eine gewisse Anfangsinvestition in Werkzeug, etwa für ein Werkzeug zum Lösen des Ölfilters, und man muss Teile und Verbrauchsmaterialien besorgen. Also Öle, Kupferdichtungen, Schrauben als Ersatz für alte Schrauben am Bremsflüssigkeitsbehälter und so weiter. Trotzdem landet man bei etwa €100 bis €150 statt bei den €1000, die die Werkstatt verlangt hat.
Meine Mutter kürzte Hosenbeine, als wir klein waren, und ließ sie später wieder aus, wenn wir gewachsen waren; wenn Knie oder Ellbogen durchgescheuert waren, setzte sie Flicken auf.
Dieses Umfeld hat mir gute und schlechte Gewohnheiten zugleich mitgegeben. Ich mache fast alle Reparaturen im Haus selbst, aber ich arbeite zu viel und habe deshalb nicht immer genug Zeit oder Energie. Es fällt mir schwer, andere zu bezahlen, obwohl ich es mir leisten könnte, und deshalb lasse ich kaputte Dinge oft viel länger liegen, als nötig wäre.
Vielleicht hätte ich mehr Geld, wenn ich diese Zeit statt für Wartung und Reparaturen in Side Projects gesteckt hätte.
Diese Leute brachten anderen die Grundlagen bei und halfen, wenn unerwartete Probleme auftraten. Das Wissen und eine Art grundlegende Lehre waren in die Gemeinschaft eingebettet.
Heute ist Reparatur etwas, das man allein macht. YouTube und Ähnliches helfen sehr, aber der gemeinschaftliche Aspekt ist verschwunden.
Ein bedauerlicher Nebeneffekt ist, dass Reparatur und Wiederverwendung weniger attraktiv erscheinen und Reparierbarkeit sowie lange Lebensdauer als Produkteigenschaften ebenfalls an Bedeutung verloren haben. Jetzt, da das Wirtschaftswachstum in den USA stagniert, besonders für die 99 %, wird sichtbar, was wir verloren haben. Es gibt kaum Dinge, die auf Langlebigkeit ausgelegt sind, und Unternehmen bieten entweder keine reparierbaren, langlebigen Produkte an oder können es nicht. Deshalb stoßen sogar Menschen, die sich bewusst bemühen, ihre Sachen zu reparieren, auf unzählige Hindernisse.
Interessant fand ich die Stelle, an der klar wurde, dass der Datenblock im Flash-Chip ein Bild war. Kein Bild im üblichen Sinn, sondern Daten, die verschiedene LED-Animationen beschrieben.
Ich habe einmal eigenständig ein ähnliches Format für Hue-Lampen-Animationen erstellt. Allerdings war es Text statt Binärdaten.
bulb1 bulb2dly R G B WW CW R G B WW CW100 10 25 20 0 0 25 10 20 0 0200 10 50 20 0 0 50 10 20 0 0Der erste Wert ist die Verzögerung in Millisekunden, bevor zur nächsten Zeile gewechselt wird; danach folgen die Helligkeiten der einzelnen LED-Kanäle auf einer Skala bis 100. Zeilen, die nicht mit einer Zahl beginnen, sind Kommentare, und zwischen den Kanälen kann beliebig ein oder mehr Leerzeichen stehen.
Es macht Spaß, ein ähnliches Binärformat in einem kommerziellen Produkt zu sehen. Eigentlich ist es ziemlich naheliegend, aber es trotzdem direkt zu sehen, ist interessant.
https://en.wikipedia.org/wiki/Piano_roll
Ein demütig machender Beitrag. Das ist echte Full-Stack-Entwicklung.
Ich würde gern sehen, wie Elgato auf diesen Beitrag reagiert.
Meiner Erfahrung nach sind Elgato-Produkte billig, aber schrecklich instabil. Dieser Beitrag zeigt sehr detailliert, warum.
Auch die Software hat alle Funktionen, die man sich wünscht, man kann eigene Plugins bauen, und der Prozess dafür ist dokumentiert. Das alles ist wirklich gut.
In der Praxis muss man aber das Key Light ständig aus- und wieder einschalten, und unter Windows auch die Stream-Deck-App immer wieder neu starten.
Ich frage mich, wie man bei solchen Projekten die Motivation aufrechterhält. Man muss immer wieder Teile bestellen und auf ihre Ankunft warten, und besonders bei Teilen aus China führt diese Warterei wohl dazu, dass viele Projekte aufgegeben werden.
Wenn ich richtig gezählt habe, hat der Autor mindestens dreimal bestellt. Trotzdem ist es wirklich faszinierend.
Wenn man keine Wärmebildkamera hat, kann man Isopropylalkohol auf das Board geben und schauen, wo er am schnellsten verdunstet.
Natürlich funktioniert das nur bei Niedervolt-Geräten.
Die Fähigkeit, der Wahrheit nachzugehen und ihr bis zum Ende zu folgen, macht uns auf gewisse Weise heilig und zeigt die menschliche Seite des Bauens und Verbesserns. Diese Person ist bei der Erforschung eines weltlichen Gegenstands einen sehr tiefen spirituellen Weg gegangen.
Dass Geräte sich uns widersetzen, ist so traurig, frustrierend und höllisch. Computer und Geräte sollten die Wahrheiten, aus denen sie bestehen, verstärken und ausstrahlen. Doch die Menschheit ist in ihren selbstgebauten Hüllen gefangen und in einem top-down geprägten Konsumismus, der Teilhabe und Lernmöglichkeiten verweigert. Gerade Computer werden oft zu exemplarischen Verschleierungsmaschinen, die Wahrheit und Verständnis verbergen. So viel Potenzial wird unglaublich verschwendet.
Ich hoffe, noch zu Lebzeiten einen Durchbruch hin zu offenen Maschinen zu erleben. Applaus für Doug.