Diagnostic et Réparation d’un Dispositif Électronique : Mon Expérience

Introduction à la Réparation Électronique

Cet article aborde divers aspects de la réparation électronique, y compris le diagnostic matériel, l’analyse de fiches techniques de fabricants de puces, et l’ingénierie inverse de firmware. Si cela vous intéresse, continuez à lire !

Inspiration des Chaînes de Réparation

Récemment, j’ai pris plaisir à visionner des chaînes de réparation d’électronique sur YouTube. Il y a quelque chose de fascinant à voir un appareil défectueux redevenir fonctionnel simplement en remplaçant un condensateur défectueux coûtant quelques centimes ou un circuit intégré endommagé. Parmi mes chaînes préférées, on trouve « Réparez-le » et « Électronique Facile ».

Mon Projet de Réparation

Ces vidéos m’ont motivé à me lancer dans la réparation. J’ai donc exploré eBay à la recherche de dispositifs défectueux. Étant familiarisé avec le fonctionnement des encodeurs et décodeurs vidéo, j’ai décidé de tenter de réparer une carte de capture HDMI. J’ai trouvé un appareil Elgato Game Capture HD60 S USB 3.0 qui ne semblait pas fonctionner.

Diagnostic Initial

À son arrivée, j’ai confirmé que l’appareil ne réagissait pas lorsqu’il était branché. J’ai ouvert le boîtier pour examiner son fonctionnement interne. En mesurant les tensions sur la carte, il était évident qu’un composant tirait trop sur les rails d’alimentation. À ce moment-là, je ne savais pas encore à quel point la situation serait complexe.

Utilisation de la Caméra Thermique

En touchant les composants, j’ai pu identifier ceux qui chauffaient, mais j’ai également utilisé ma caméra thermique pour capturer des images intéressantes.

Identification des Composants Défectueux

J’ai repéré un petit circuit intégré dans le coin supérieur gauche de la carte, identifié par le marquage « fiVJVE ». Ce composant semblait être un régulateur de tension, car il était proche d’une inductance de 2,2 µH. En mesurant les broches, j’ai constaté que la tension d’entrée était de 5V, mais la sortie était anormalement basse.

Un autre circuit intégré « fiVJVE » était présent sur la carte, mais il manquait un composant. Bien qu’il ne chauffait pas, il produisait également une tension faible, ce qui m’a amené à suspecter un problème.

Analyse Thermique Approfondie

En examinant d’autres zones de la carte, j’ai découvert un autre composant qui chauffait, identifié par le marquage « PFNI ». Cela m’a conduit à me demander ce qui pouvait causer ces dysfonctionnements.

Recherche des Composants

Pour identifier ces circuits intégrés, j’ai utilisé des moteurs de recherche spécialisés. Bien que je n’aie pas trouvé de correspondance exacte pour « fiVJ », j’ai découvert qu’il s’agissait probablement d’un Fitipower FP6121-IS9P, et après quelques recherches, j’ai pu confirmer qu’il s’agissait du FP6373A.

Identification du Régulateur de Tension

Le circuit PFNI s’est révélé être un inverseur de tension TI TPS60403DBV. Tous ces composants avaient en commun qu’ils fonctionnaient avec une entrée de 5V, mais leurs sorties présentaient une faible résistance à la terre, ce qui m’a amené à penser qu’un excès de tension avait pu endommager l’appareil.

Injection de Tension pour le Diagnostic

Pour comprendre pourquoi le régulateur FP6373A ne chauffait pas, j’ai décidé d’injecter une tension sur son rail de sortie. En utilisant une alimentation de laboratoire, j’ai injecté 2,7V dans le circuit, ce qui m’a permis d’identifier rapidement le FP6373A comme la source du problème.

Conclusion

Il semble que, lors de son fonctionnement normal, le régulateur se mettait en mode de protection, ce qui entraînait une coupure de son rail de sortie. En injectant directement de la tension, le régulateur ne pouvait pas se désactiver, ce qui a provoqué une surchauffe. Cette expérience m’a permis d’apprendre beaucoup sur le diagnostic et la réparation des appareils électroniques.

Réparation d’un Dispositif Électronique : Un Voyage de Dépannage

Récemment, j’ai entrepris de résoudre un problème avec un appareil électronique en utilisant une caméra thermique. Cela s’est avéré être une expérience enrichissante. Au départ, j’avais des doutes sur la responsabilité du circuit intégré TI, mais après avoir constaté que deux autres puces sur le rail de 5V étaient également endommagées, j’ai décidé de remplacer les trois en même temps pour voir si cela résoudrait le problème. Malheureusement, le FP6373A n’était pas disponible chez les distributeurs américains habituels, mais j’ai réussi à le trouver sur LCSC pour seulement 0,17 $ l’unité, tandis que le circuit intégré TI était également disponible à 0,58 $. Cela semblait presque trop simple : remplacer trois puces pour moins d’un dollar, même en petite quantité. Cependant, les frais de port étaient bien plus élevés que le coût des pièces elles-mêmes !

Une fois les pièces arrivées de Chine, j’ai pu procéder à leur remplacement. J’ai toujours une certaine appréhension à l’idée de déranger les résistances et les condensateurs voisins lors de l’utilisation de l’air chaud, c’est pourquoi j’utilise du ruban Kapton pour protéger les autres composants.

Remplacement des puces

Le processus de soudure des nouvelles puces s’est déroulé sans trop de difficultés, bien que les broches de masse aient absorbé une quantité considérable de chaleur. Il semble que la conception de ce circuit imprimé n’offre pas un bon dégagement thermique pour les masses. J’ai accidentellement soulevé un pad pour l’un des régulateurs, mais comme il n’était pas connecté à quoi que ce soit (le signal « PG »), cela n’a pas causé de dommages. C’est d’ailleurs cette absence de connexion qui a facilité le soulèvement. De plus, la chaleur absorbée par la broche de masse m’a induit en erreur, me faisant croire que je pouvais appliquer la même chaleur sur les autres broches.

Soudure des nouvelles puces

En plus du pad soulevé (broche du milieu à droite), on peut voir ici les difficultés rencontrées pour souder la broche de masse (broche du milieu à gauche). Elle ne voulait vraiment pas chauffer. J’aurais probablement pu chauffer l’ensemble de la carte pour faciliter le travail de mon fer à souder, mais bon, elle est connectée.

Quoi qu’il en soit, après avoir remplacé les trois puces, l’appareil fonctionnait ! Aucune des nouvelles puces ne surchauffait, le HD60 S apparaissait comme un périphérique USB lorsqu’il était branché, et il fonctionnait parfaitement pour capturer et transmettre un signal HDMI. J’étais ravi d’avoir réussi à le réparer, mais un problème subsistait : aucune des lumières indicatrices ne fonctionnait. Il y a sept LED blanches et sept LED rouges, chacune ayant un rôle spécifique pour indiquer le statut de l’appareil. Par exemple, les lumières blanches sont censées clignoter deux fois lors de la première connexion.

Cela a été un peu décevant. J’avais en quelque sorte réparé l’appareil, mais pas complètement. Que faire maintenant ?

Analyse Approfondie du Circuit Imprimé

Je suis donc retourné à la planche à dessin. J’ai examiné de plus près le circuit imprimé pour comprendre le fonctionnement des LED. La puce concernée est l’IT1504, fabriquée par Innochip. En consultant sa fiche technique, j’ai découvert qu’il s’agissait d’un circuit intégré pilote de LED à 16 canaux. La communication se fait via une interface de données série qui ressemble beaucoup à SPI. Il s’avère que de nombreux circuits intégrés pilotes de LED de divers fabricants, tels que Toshiba et ST, utilisent également ce même schéma de communication. Au début, cela m’a semblé étrange, mais il semble que ce soit assez standard. C’est une variante de SPI où l’on envoie un certain nombre d’impulsions d’horloge pour choisir la commande à exécuter.

Analyse de la puce IT1504

J’ai surveillé les broches d’entrée de données pertinentes sur l’IT1504 à l’aide de mon oscilloscope, et j’ai pu constater qu’il y avait effectivement des données qui lui étaient envoyées. En suivant les pistes, j’ai découvert que l’IT1504 était contrôlé par un microcontrôleur Nuvoton M031LD2AE, qui est basé sur l’architecture ARM Cortex-M0.

Microcontrôleur Nuvoton

La présence de trafic SPI prouvait qu’il essayait au moins de faire quelque chose, donc j’ai supposé que le circuit intégré pilote de LED était probablement endommagé. Cela posait un problème majeur : comment trouver un remplacement pour l’IT1504 ? Il n’était en stock nulle part. LCSC ne l’avait pas, et bien sûr, aucun des distributeurs américains ne l’avait non plus. Je n’ai même pas trouvé de vendeurs sur AliExpress ou Utsource.

J’ai contacté Innotech, qui m’a surpris en répondant le lendemain et en proposant de m’envoyer quelques échantillons gratuits pour le prix de l’expédition, mais ils ont ensuite réalisé qu’ils n’avaient que des bobines complètes en stock, donc ils ne pouvaient pas m’envoyer d’échantillons. C’était gentil de leur part de vérifier, mais je n’étais certainement pas prêt à acheter une bobine complète de puces IT1504 juste pour résoudre ce problème.

Cela m’a poussé à effectuer une recherche approfondie sur Internet pour trouver des pilotes de LED susceptibles de constituer un remplacement équivalent. La fiche technique de l’IT1504 à ma disposition ne contenait pas toutes les informations sur les commandes, donc je n’étais pas sûr de ce que je cherchais exactement. Plusieurs pièces discontinuées d’autres fabricants bien connus semblaient similaires, mais je ne trouvais pas d’équivalents exacts. C’est alors que j’ai découvert quelque chose de vraiment étrange.

J’ai par hasard trouvé les produits de Macroblock, en particulier le MBI5040. La fiche technique semblait correspondre assez bien à celle de l’IT1504. En fait, peut-être un peu trop bien. Voici un exemple pour illustrer mon propos :

Comparaison des fiches techniques

Voici quelques autres comparaisons côte à côte pour bien illustrer le point :

Comparaison des spécifications

Ils sont presque identiques ! Tout est disposé dans le même ordre. Les spécifications de sortie de courant diffèrent légèrement, mais à part cela, ce sont exactement les mêmes produits, jusqu’aux diagrammes de blocs identiques. La formulation a été légèrement modifiée ici et là, mais ces deux fiches techniques proviennent clairement de la même source. Ces entreprises sont toutes deux basées à Taïwan. Peut-être que l’une d’elles a licencié le design de l’autre ? Ou peut-être y a-t-il eu de l’espionnage industriel ? Il y a définitivement quelque chose de louche avec les polices sur la page de description générale de la fiche technique d’Innochip. Les polices changent aléatoirement entre serif et sans-serif. C’est le genre de détail que l’on remarque en lisant un e-mail où l’on peut dire que la personne a clairement copié et collé en écrivant. Cela ne signifie pas nécessairement quoi que ce soit, mais j’ai trouvé cela étrange.

En fait, même les numéros de pièces sont presque identiques. Si l’on considère que la lettre majuscule « I » dans MBI5040 est en réalité le chiffre 1, on obtient MB15040 et IT1504.

Je n’ai aucune idée de quel produit est l’original ici, mais dans tous les cas, cette découverte a ouvert de nouvelles perspectives pour la réparation de mon appareil.

Résolution d’un Problème de Panneau LED sur la Carte de Capture HD60 S

Découverte d’une Solution Potentielle

Récemment, j’ai fait une découverte encourageante : j’ai identifié une puce qui pourrait remplacer l’IT1504, que je pensais défectueuse. En consultant la fiche technique du MBI5040, j’ai trouvé des informations sur les commandes, ce qui m’a permis d’explorer plus en profondeur le trafic SPI. J’ai réussi à me procurer quelques unités de MBI5040GF sur AliExpress et Utsource.

Remplacement de la Puce LED

Le remplacement de la puce LED s’est avéré être une tâche relativement simple. J’ai utilisé du ruban Kapton pour éviter tout accident lors de la manipulation.

Test de Fonctionnement

Après avoir terminé le remplacement, j’ai nettoyé les résidus de flux et j’ai connecté le HD60 S à mon ordinateur. La capture vidéo fonctionnait correctement, mais les lumières restaient éteintes. Cela m’a amené à me demander si les LED elles-mêmes étaient défectueuses. J’ai donc utilisé une alimentation de laboratoire et une résistance pour tester les LED individuellement, et elles se sont toutes allumées sans problème.

Une Découverte Surprenante

À ce stade, je manquais d’idées. La nouvelle puce n’avait pas résolu le problème, et les LED étaient en bon état. En effectuant des recherches sur Google, j’ai découvert que la défaillance des LED sur les cartes de capture Elgato HD60 S était un problème connu, partagé par de nombreux utilisateurs. J’ai trouvé plusieurs discussions sur Reddit où des utilisateurs exprimaient des préoccupations similaires.

Un Problème Fréquent

Il s’est avéré que j’avais également acheté une autre carte HD60 S « morte » sur eBay, qui fonctionnait parfaitement mais présentait le même défaut d’indicateur LED. Cela a renforcé l’idée que cette panne était assez courante.

Une Nouvelle Défi

Il semblait probable que les LED ne fonctionnaient pas même avant que les régulateurs de tension ne soient endommagés. Cela m’a conduit à un nouveau défi : comprendre pourquoi les LED ne s’allumaient pas et comment les réparer. J’avais maintenant deux unités présentant le même problème et connaissais au moins quatre autres personnes confrontées à cette situation.

Vérification du Circuit LED

Ma première étape a été de vérifier le circuit LED sur la carte. J’ai soulevé les broches d’entrée SPI de la puce MBI5040 et j’ai soudé des fils pour les tester. Cela m’a permis de connecter un Raspberry Pi Pico pour contrôler manuellement les LED en envoyant les commandes appropriées, comme indiqué dans la fiche technique du MBI5040.

Résultats des Tests

À ce stade, j’étais convaincu qu’il n’y avait rien de physiquement défectueux dans ma carte HD60 S réparée. Je pouvais contrôler les lumières sans problème, ce qui indiquait que le circuit fonctionnait correctement. Le microcontrôleur Nuvoton Cortex-M0 ne semblait tout simplement pas activer les LED.

Retour à la Puce d’Origine

J’ai décidé de remettre la puce IT1504 d’origine sur la carte pour confirmer mes soupçons. En utilisant du ruban Kapton pour isoler certaines broches, j’ai pu souder les autres normalement. Après avoir reconnecté les fils, j’ai répété l’expérience avec le Raspberry Pi Pico. Comme prévu, la puce d’origine fonctionnait également parfaitement.

Une Leçon Apprise

Bien que cela ait été frustrant, cette expérience n’a pas été totalement inutile. La fiche technique du MBI5040 m’a fourni des informations précieuses sur le contrôle des LED par le logiciel. Il devenait de plus en plus évident que le problème était lié au logiciel plutôt qu’au matériel.

Recherche de Solutions

J’ai décidé de contacter Elgato pour savoir s’il existait un problème connu avec les lumières d’état. Leur réponse a été peu encourageante, mais cela ne m’a pas découragé. J’ai choisi de me concentrer sur la compréhension du firmware du microcontrôleur Nuvoton M031LD2AE. Grâce à une expérience antérieure avec les microcontrôleurs Nuvoton, j’avais déjà un Nu-Link2-Me, ce qui m’a permis de progresser dans mes recherches.

Accès aux Broches de Programmation

En examinant la carte, j’ai découvert deux petits connecteurs JST, un de 4 broches et un de 6 broches. En traçant les connexions, j’ai rapidement réalisé que le connecteur de 4 broches était destiné à la programmation du microcontrôleur. J’ai pu le connecter avec le câble JST que j’avais sous la main, ce qui m’a ouvert la voie à de nouvelles explorations.

Exploration du Firmware de l’Elgato Game Capture HD60 S

Introduction

L’analyse des composants électroniques d’un appareil peut souvent révéler des informations fascinantes sur son fonctionnement interne. Dans cet article, nous allons examiner le firmware de l’Elgato Game Capture HD60 S, en mettant l’accent sur les découvertes réalisées lors de l’exploration de son microcontrôleur Nuvoton.

Connexion et Programmation

Il est probable que le connecteur JST à 6 broches situé à proximité soit destiné à la programmation du CPLD Altera MAX II présent sur la carte. Bien que cela semble logique, mon intérêt principal ne résidait pas dans le CPLD. J’ai tenté d’extraire le firmware du microcontrôleur Nuvoton à l’aide de l’outil de programmation NuMicro ICP, mais il s’est avéré que le contenu était protégé par Elgato.

Accès au Firmware

Heureusement, Elgato fournit la dernière version du firmware via son utilitaire 4K Capture. En consultant le fichier ElgatoDeviceCapabilities.json inclus dans le même répertoire, j’ai pu obtenir des informations précieuses. Ce firmware est spécifiquement conçu pour le modèle de l’appareil avec l’ID produit USB 118 (0x0076), qui correspond à mon appareil, connu sous le nom de « Game Capture HD60 S Rev.4 ».

Vérification de la Version du Firmware

Lorsque j’ai vérifié la version du firmware dans l’utilitaire 4K Capture, j’ai constaté qu’elle était déjà à jour. Bien qu’il soit possible d’activer un bouton de mise à jour du firmware, cela n’a eu aucun effet, car la version la plus récente était déjà installée.

Analyse du Fichier Firmware

Le fichier FW_HD60_S_MCU.bin ressemblait à un binaire de firmware Cortex-M0 standard. En l’examinant avec un éditeur hexadécimal, j’ai pu identifier le pointeur de pile initial et une série de vecteurs d’interruption, y compris le vecteur de réinitialisation. Cela a confirmé que le fichier contenait une table de vecteurs Cortex-M0 valide.

Exploration des Périphériques

L’utilisation d’un fichier SVD m’a permis d’identifier les différents périphériques utilisés, notamment des GPIO, un timer et un bus I²C. Le projet M031BSP de Nuvoton s’est avéré très utile pour identifier de nombreuses fonctions. Bien que j’aie effectué cette tâche manuellement, ce qui était peut-être un peu fou, cela m’a permis de comprendre les connexions entre les broches et le contrôleur LED.

Communication I²C

L’utilisation du bus I²C a été cruciale, car j’ai découvert d’autres puces sur la carte qui communiquent via ce protocole : l’ITE IT6802E et l’IT66121FN. L’IT6802E agit comme un récepteur HDMI, convertissant le signal HDMI entrant en un flux de données parallèle. En revanche, l’IT66121FN prend un flux de données parallèle et le renvoie sous forme de signal HDMI, essentiel pour la fonctionnalité de passthrough.

Recherche de Code et Débogage

En fouillant dans divers projets GitHub, j’ai trouvé du code de pilote ITE qui m’a aidé à identifier plusieurs fonctions et variables. Cela a enrichi ma compréhension du firmware. Après avoir acquis une bonne compréhension de la structure générale du firmware, j’ai décidé de déboguer le code. Bien que le microcontrôleur soit protégé, j’ai réussi à le désouder et à le remplacer par un nouveau modèle vierge.

Déblocage et Débogage

Après avoir flashé le fichier FW_HD60_S_MCU.bin sur le nouveau chip, j’ai constaté qu’il fonctionnait, mais se protégeait à nouveau, rendant le débogage impossible. En utilisant Ghidra, j’ai localisé la fonction responsable de la mise à jour des registres de configuration et l’ai modifiée pour laisser le chip déverrouillé. Cela m’a permis de déboguer le code et d’insérer des points d’arrêt pour comprendre pourquoi les LED n’étaient pas contrôlées.

Extraction du Bootloader

Cette quête de déblocage m’a conduit à envisager l’extraction du contenu protégé de l’ancien microcontrôleur, y compris un éventuel bootloader. J’ai tenté d’installer mon nouveau firmware déverrouillé comme mise à jour via le logiciel d’Elgato, espérant que cela désactiverait la protection et me permettrait de lire l’intégralité du contenu avec mon Nu-Link2-Me. Cela pourrait s’avérer utile comme sauvegarde ou pour obtenir d’autres indices sur le fonctionnement de l’appareil.

Conclusion

L’exploration du firmware de l’Elgato Game Capture HD60 S a été une aventure enrichissante, révélant des détails techniques fascinants sur son fonctionnement interne. Grâce à des outils comme Ghidra et des recherches approfondies, j’ai pu mieux comprendre les interactions entre les composants et le rôle crucial du microcontrôleur Nuvoton dans l’ensemble du système.

Résolution des Problèmes de LED sur le HD60 S : Une Exploration Technique

Introduction

Dans le cadre de mes efforts pour résoudre un problème de LED sur le HD60 S, j’ai découvert des éléments fascinants concernant le fonctionnement interne de l’appareil. En modifiant le fichier ElgatoDeviceCapabilities.json pour pointer vers mon firmware déverrouillé, j’ai pu installer une nouvelle version du firmware via l’outil 4K Capture Utility. Bien que l’outil ait signalé un échec de la mise à jour, cela m’a permis d’accéder à des informations cruciales.

Découverte de l’Architecture Interne

État Initial du Dispositif

Au départ, le HD60 S semblait être bloqué, ne fonctionnant plus comme carte de capture. Cependant, j’ai réussi à déverrouiller la puce Nuvoton, ce qui m’a permis d’extraire le contenu de la mémoire flash, y compris le bootloader et les configurations d’origine. Cela a été une étape clé, car cela m’a donné la possibilité de reprogrammer un nouveau MCU Nuvoton avec le firmware d’origine d’Elgato.

Analyse du Bootloader

En examinant le bootloader LDROM, j’ai constaté qu’il attendait des commandes de mise à jour au lieu de démarrer le firmware d’application lorsque la puce était en mode non protégé. Cela a expliqué pourquoi mon HD60 S ne fonctionnait plus après l’installation du firmware déverrouillé : il était coincé dans le bootloader.

Compréhension des Problèmes de LED

Exploration des Composants

En approfondissant mes recherches, j’ai réalisé que le problème des LED pouvait être lié à la communication entre les différents composants. Voici un aperçu de l’architecture :

  • Cypress/Infineon CYUSB3014 : Ce chip USB 3.0 ARM926EJ-S envoie des commandes au MCU Nuvoton via I²C et gère la communication avec l’ordinateur.
  • MCU Nuvoton ARM Cortex-M0 : Il configure et surveille les récepteurs et émetteurs vidéo, tout en contrôlant les LED.
  • Communication des Statuts : Le MCU Nuvoton renvoie des informations de statut au CYUSB3014.

Investigation des Commandes I²C

En me concentrant sur le chip Cypress, j’ai découvert qu’il y avait des fonctions qui envoyaient des commandes au MCU Nuvoton. Cela m’a permis de mieux comprendre comment les LED étaient contrôlées. En analysant le contenu de la mémoire flash SPI, j’ai trouvé des données qui semblaient être des images, ce qui m’a intrigué.

Découverte Cruciale

Identification des Pins GPIO

En examinant les pins GPIO inconnus dans le firmware du Nuvoton, j’ai découvert qu’ils étaient connectés à un commutateur bus PI5C3257. Ce commutateur détermine si le chip CYUSB3014 ou le MCU Nuvoton est connecté à la mémoire flash SPI. Cela a été une révélation, car j’avais initialement pensé que la mémoire flash était uniquement dédiée au CYUSB3014.

Réalisation des Fonctions SPI

Cette découverte m’a permis de décompiler de nouvelles fonctions liées aux transactions SPI, ainsi qu’à l’effacement et à l’écriture dans la mémoire flash. J’ai compris que les données que j’avais trouvées dans la mémoire flash étaient effectivement des images, mais pas dans le sens traditionnel.

Conclusion

Cette exploration technique m’a permis de mieux comprendre le fonctionnement interne du HD60 S et de progresser dans la résolution du problème des LED. Grâce à l’analyse approfondie des composants et à la découverte des interactions entre eux, j’ai pu avancer dans mes efforts de réparation. La complexité de l’architecture m’a ouvert de nouvelles perspectives sur la manière dont ces dispositifs fonctionnent et interagissent.

Analyse des Animations LED et Résolution de Problèmes sur HD60 S

Les animations LED sont composées de plusieurs trames, chaque trame étant constituée de 16 octets destinés à contrôler les 14 LED. Par exemple, une LED rouge s’illumine tandis que six des sept LED blanches exécutent diverses actions. Les deux derniers octets de chaque trame représentent un délai avant de passer à la trame suivante. Cependant, les premiers 16 octets semblaient étranges, suggérant qu’ils contenaient peut-être des données d’en-tête pour l’animation.

Exploration des Données SPI

J’ai également découvert un code qui tentait de lire des données au début de la section 0x300000, mais dans mon extrait de mémoire flash SPI, cette section était presque complètement vide :

Les pièces du puzzle commençaient à s’assembler. Le firmware du microcontrôleur Nuvoton vérifiait si les deux premiers octets contenaient la valeur 16 bits 0xAA55 :

Dans mes extraits de mémoire flash des unités avec des LED non fonctionnelles, cette section était remplie de 0x00. Le firmware ignorait tout le code de contrôle des LED car les données attendues n’étaient pas présentes à partir de 0x300000 dans la mémoire flash. J’ai confirmé que ces données manquaient sur les deux appareils HD60 S que j’ai testés.

Achat d’un Appareil Fonctionnel

Pour éviter de passer trop de temps à essayer de remplir artificiellement ces données, j’ai décidé d’acheter un troisième HD60 S, qui était confirmé comme étant entièrement fonctionnel. Malheureusement, il s’agissait d’une révision plus ancienne avec un PCB complètement différent, mais il était toujours basé sur le CYUSB3014. Il utilisait également un microcontrôleur Nuvoton, bien qu’il s’agisse d’un modèle différent. Cependant, il avait toujours un IT1504 pour le contrôle des LED, ainsi qu’une puce flash SPI Winbond, ce qui était prometteur.

Après avoir confirmé que ses LED fonctionnaient correctement, j’ai extrait la mémoire flash SPI. À ce stade, j’avais appris à extraire le contenu de la mémoire flash sans soudure en forçant le CYUSB3014 à démarrer via USB (en retirant un cavalier sur la carte) et en téléchargeant un chargeur de démarrage RAM fourni par Cypress capable d’extraire la mémoire flash SPI (cyfxflashprog.img). Voici le début des données valides à 0x300000 :

Ces données avaient beaucoup plus de sens. Le premier mot de 16 bits (little-endian) était 0xAA55, comme le firmware l’attendait. De plus, il contenait d’autres données d’en-tête, indiquant qu’il y avait 26 animations LED différentes, ainsi que des informations sur leur nature. Bien que je n’aie pas encore compris chaque élément de ces données, chaque animation a un résumé de 16 octets, commençant à 0x300008. Je pense que les 4 derniers octets de chaque animation représentent probablement un CRC-32 de quelque chose.

Analyse des Données de Correction

En outre, dans l’extrait de la puce, il y avait une section commençant à 0x3000B8 remplie de 0xE5. Cela correspond aux données de correction de points qui sont chargées dans l’IT1504. D’après la décompilation, ces données devraient en fait se trouver à 0x3007F8, ce qui est exactement l’endroit où elles se trouvent dans l’extrait valide :

Le 0x521114A7 qui suit est un CRC-32 des 16 octets de données précédents.

Corruption des Données dans les Appareils Défectueux

Une inspection plus approfondie a révélé que les données dans la mémoire flash SPI des appareils défectueux différaient considérablement. En fait, elles étaient différentes les unes des autres. Cela m’a amené à penser que les données d’animation étaient probablement corrompues. Par exemple, voici à quoi ressemble l’animation à 0x31E000 dans l’extrait du bon HD60 S :

Notez qu’il n’y a pas d’en-tête étrange en haut, comme dans l’extrait d’un autre appareil. Les données commencent immédiatement avec des informations d’animation cohérentes avec le reste des données environnantes. De plus, elles sont plus longues. Ces données sont beaucoup plus logiques. En revanche, elles étaient corrompues de deux manières complètement différentes dans mes deux appareils HD60 S avec des LED non fonctionnelles.

Réparation des Appareils Défectueux

Plusieurs (mais pas toutes) des animations dans mes appareils non fonctionnels commençaient par un en-tête étrange « AB 03 12 39 ». Je ne pense pas que cet en-tête soit censé être là. Peut-être qu’il y a eu un bug lors d’une procédure de mise à jour ? Le firmware Nuvoton a effectivement des fonctions capables d’effacer et de réécrire des données sur la puce flash SPI. Je me demande si ce code a été exécuté et a détruit les contenus d’origine.

Avec ces nouvelles informations, j’ai pris le contenu original de la mémoire flash SPI des deux appareils avec des voyants LED non fonctionnels et j’ai simplement remplacé toutes les données LED à partir de 0x300000 par les données de l’appareil fonctionnel. Ensuite, j’ai flashé cette nouvelle image « hybride » sur les appareils non fonctionnels. Il est important de noter que chaque appareil a son propre extrait de mémoire flash unique, le numéro de série USB étant intégré quelque part. J’ai donc préféré préserver les données de 0 à 0x2FFFFF pour chaque appareil individuel.

Je n’étais pas tout à fait sûr de ce à quoi m’attendre en essayant cela. Les bonnes données de mémoire flash provenaient d’une révision plus ancienne du produit avec un microcontrôleur Nuvoton différent, mais elles semblaient correspondre à ce que le firmware plus récent recherchait.

Résultats de la Réparation

Voici une image de ce que j’ai vu dès que j’ai alimenté l’un des appareils problématiques après avoir reflashé sa puce mémoire flash SPI :

Ça a fonctionné. Les lumières blanches ont clignoté deux fois, puis les lumières rouges ont brièvement clignoté une fois.

Je pense que le flash rouge signifie simplement que le signal a été perdu, car cela se produit également chaque fois que je débranche une source HDMI. Le modèle plus ancien ne fait pas ce flash rouge à chaque mise sous tension, mais peut-être que c’est juste une différence de firmware concernant la manière d’indiquer « signal perdu » immédiatement au démarrage sans rien de branché. J’ai vu des mentions en ligne selon lesquelles les lumières rouges signifient que le signal est protégé par HDCP, mais je pense que c’est un clignotement rouge plus long que j’ai également observé lorsque je branche mon iPhone comme source HDMI.

J’ai également remarqué que certaines des animations qu’Elgato dit qu’elles devraient se produire, comme lorsque je commence ou arrête l’enregistrement, ne se jouent pas sur ce modèle plus récent, même si elles fonctionnent parfaitement sur le modèle plus ancien.

Résolution des Problèmes d’Animation LED sur les Cartes de Capture

Introduction

Récemment, j’ai exploré les subtilités des animations LED sur les cartes de capture, en particulier sur le modèle HD60 S d’Elgato. Mon objectif était de comprendre pourquoi certaines de ces animations ne fonctionnaient pas correctement et de trouver une solution.

Analyse des Données d’Animation

En fouillant dans les fichiers d’animation, j’ai découvert que les données brutes se trouvaient dans le répertoire C:Program FilesElgatoGameCaptureAnimations pour les utilisateurs de Windows, ou dans /Applications/Game Capture HD.app/Contents/Resources/Animations sur Mac. En examinant les fichiers d’animation (01.ani, 02.ani, etc.), j’ai constaté que les données correspondaient parfaitement à celles de mon ancien appareil fonctionnel. Bien que les octets pour chaque LED soient désordonnés, un réarrangement approprié permettrait de recréer une copie exacte des données d’animation.

Problèmes de Mise à Jour du Firmware

Un autre aspect intéressant que j’ai remarqué concerne le processus de mise à jour du firmware. Lors de l’utilisation de l’utilitaire 4K Capture d’Elgato sur Windows, la mise à jour ne semble pas attendre suffisamment longtemps avant d’indiquer un échec. En revanche, sur Mac, le processus se déroule sans accroc. Si l’on débranche l’appareil trop tôt après un message d’échec, cela peut entraîner un flash incomplet, ce qui pourrait potentiellement « bricker » l’appareil. J’ai réussi à résoudre ce problème en augmentant la durée de mise à jour dans le fichier ElgatoDeviceCapabilities.json.

Solutions pour Réparer les LED

Pour ceux qui rencontrent des problèmes similaires avec les LED, la solution est assez complexe. Elle nécessite de commencer une mise à jour du firmware, de débrancher immédiatement l’appareil, puis de manipuler le circuit imprimé pour permettre au chip Cypress de prendre le contrôle. Ensuite, il faut télécharger un fichier spécifique en utilisant des outils du SDK CYUSB3014. Après avoir effectué ces étapes, il est possible de restaurer le firmware et de faire fonctionner à nouveau les LED.

Conclusion

En fin de compte, la solution à mon problème était étonnamment simple. Il m’a suffi de remplacer trois puces pour un coût total de moins d’un dollar. Tout le temps et l’argent supplémentaires investis dans ce projet étaient liés à un problème bien connu des LED, qui n’avait rien à voir avec ma réparation initiale. Bien que j’aie consacré plus d’efforts que nécessaire à cette tâche, j’ai maintenant une réponse claire sur les dysfonctionnements des LED sur certaines cartes de capture. Il semble que cela soit dû à un bug logiciel ou de mise à jour. Bravo à Elgato pour cette expérience enrichissante !

Show Comments (0)
Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *