Mineur maison ne hashe plus ? La bible du dépannage 2026

Parcourez n’importe quelle communauté de minage domestique un jour quelconque et vous trouverez les mêmes messages : un Bitaxe qui démarre mais reste à 0 GH/s, un NerdQaxe qui redémarre toutes les deux minutes, un Gamma qui a perdu la moitié de son hashrate après une mise à jour du firmware, une machine qui affirme hasher pendant que le pool ne voit rien. Ces appareils sont du matériel open source exécutant un firmware open source sur du silicium industriel récupéré, et cette combinaison est puissante, bon marché et véritablement fragile d’une manière qu’un appareil électroménager n’est pas.

Ce guide est la référence que nous aurions voulu avoir chaque fois que nous avons aidé quelqu’un à en déboguer un. Il couvre les six domaines de panne qui expliquent presque toutes les unités mortes ou capricieuses, vous apprend à lire les logs comme le fait un atelier de réparation, et se termine par un tableau maître des symptômes et un dictionnaire des vraies lignes d’erreur que vous verrez. Il s’applique à toute la famille AxeOS : chaque Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), les gammes NerdAxe et NerdQaxe y compris les variantes ++ et Hydro, le NerdOctaxe, et par extension tout dérivé d’ESP-Miner, dont les nouvelles machines BM1373 traitées dans notre référence de l’ère BM1373.

Un principe avant tout le reste : diagnostiquez avant de toucher. L’ordre des opérations de ce guide existe parce que chaque étape élimine une classe entière de causes. Sauter directement au reflash du firmware alors que le vrai problème est une alimentation qui chute vous coûte une soirée et peut vous laisser avec deux problèmes au lieu d’un.

Pressé ? Les cinq correctifs qui règlent la plupart des cas

Avant de lire quoi que ce soit d’autre, essayez ceci dans l’ordre. Ensemble, ces gestes résolvent la majorité des signalements « mon mineur est mort » sans outil, sans log et sans ouvrir le boîtier.

1. CYCLE À FROID, CORRECTEMENT.
   Débranchez le CONNECTEUR d'alimentation (pas l'interrupteur
   de la prise). Comptez 60 secondes pleines. Rebranchez.
   Pourquoi : les défauts du régulateur SE VERROUILLENT et
   survivent à tout redémarrage logiciel ; seule une vraie
   coupure les efface.

2. VÉRIFIEZ CE QUI L'ALIMENTE VRAIMENT.
   L'USB-C fait tourner le tableau de bord mais NE PEUT PAS
   alimenter l'ASIC. Un mineur en USB-C seul affiche 0 GH/s
   et ~2 W indéfiniment. Vérifiez que la vraie alimentation
   (jack/XT30) est branchée et bien enfoncée, et qu'elle est
   à la BONNE TENSION (5 V contre 12 V : la mauvaise détruit
   la carte).

3. TAPEZ http:// EXPLICITEMENT.
   Les navigateurs basculent silencieusement en https:// et
   échouent. http://IP-DU-MINEUR, avec le préfixe, à chaque
   fois.

4. DONNEZ-LUI DU 2,4 GHz.
   Ces radios ne parlent jamais le 5 GHz. Sur un routeur
   mesh, créez un SSID uniquement 2,4 GHz ou un réseau IoT,
   WPA2-AES, et désactivez l'isolation des points d'accès.

5. DEMANDEZ AU POOL, PAS AU MINEUR.
   Le temps depuis le dernier share accepté sur le tableau
   de bord du POOL est le seul test honnête de présence en
   ligne. Plus de 10 minutes = mort maintenant, quoi qu'en
   dise l'interface du mineur.

Réglé ? Bien, fermez l'onglet. Pas réglé ? Le triage
ci-dessous trouve votre section en 60 secondes.

Trouvez votre problème rapidement

Vingt sections, c’est beaucoup. Trois façons de sauter à la vôtre :

Par la recherche : chaque chaîne d’erreur de ce guide est écrite mot pour mot, exactement comme le firmware l’imprime. Appuyez sur Ctrl+F (Cmd+F sur Mac), collez votre message d’erreur, et vous atterrissez dessus : c’est un choix de conception, pas de la chance.

Par symptôme :

Par style de lecture : la section suivante partage le guide en un parcours débutant et un parcours pro.

Choisissez votre parcours

Ce guide sert deux lecteurs très différents, et vous ne devriez pas le lire de la même façon.

Premier mineur, premier problème ? Suivez le chemin numéroté sans rien sauter : les deux règles de sécurité, l’autotest intégré, le triage de 60 secondes, puis uniquement la section vers laquelle le triage vous envoie. Chaque bloc de code est prêt à copier-coller, chaque terme que vous ne connaissez peut-être pas figure dans le mini-glossaire juste en dessous, et rien du parcours débutant n’exige d’ouvrir le boîtier ni de posséder un multimètre.

À l’aise avec un terminal et un multimètre ? Votre voie rapide : la section API pour récupérer les logs à distance et surveiller la flotte, le dictionnaire des lignes rouges pour passer directement d’une chaîne d’erreur à sa cause, le tableau des particularités par modèle, et la section atelier professionnelle en fin de guide, où vivent les schémas, la méthode des points de mesure et les ressources au niveau de la carte. Les sections marquées PRO supposent que vous savez lire un schéma et sonder une carte sous tension en sécurité.

Mini-glossaire pour débuter

Dix termes, dix secondes chacun, et le reste du guide se lit deux fois plus vite.

ASIC        la puce de minage elle-même, la seule pièce qui
            calcule réellement des hachages
ESP32       le petit contrôleur qui fait tout le reste :
            WiFi, tableau de bord, dialogue avec l'ASIC
AxeOS       le firmware + le tableau de bord web sur l'ESP32
VCORE       l'alimentation de ~1,0-1,3 V du cœur de l'ASIC,
            fabriquée sur la carte à partir de vos 5 V ou
            12 V d'entrée
VRM / TPS546  le circuit régulateur qui crée VCORE et
            protège la puce en se coupant sur défaut
stratum     le protocole par lequel votre mineur parle au
            pool
share       une preuve de travail que vous soumettez ; le
            pool les compte pour savoir que vous êtes vivant
% erreur HW résultats que la puce a calculés FAUX : le
            chiffre honnête de santé (rester sous 2%)
OTA         mise à jour « par les airs » via le tableau de
            bord, par opposition au flash par USB
NVS         la mémoire de réglages qui survit aux reflashs :
            c'est pour cela que la remise à zéro existe

Avant toute chose : deux règles de sécurité et un outil intégré

Les deux règles qui évitent les cartes mortes

Règle un : ne devinez jamais la tension. Les Bitaxe standard à une puce prennent du 5 V ; le GT, le Hex, le NerdQaxe++ et le NerdOctaxe prennent du 12 V. Les prises jack des deux familles sont physiquement interchangeables, et brancher une alimentation 12 V sur une carte 5 V la détruit définitivement en moins d’une seconde. Avant chaque branchement, lisez l’étiquette du bloc, pas la forme de la prise. C’est l’erreur la plus coûteuse de ce loisir.

Règle deux : un connecteur chaud veut dire stop. Tiède est un avertissement ; chaud, décoloré ou sentant le plastique veut dire couper tout de suite et remplacer le câble avant la prochaine mise sous tension. Tout le reste dans ce guide peut attendre demain. Pas ça.

Lancez l’autotest intégré

AxeOS embarque un autotest de mise sous tension dont la plupart des propriétaires ignorent l’existence. Il éprouve cinq sous-systèmes en séquence et signale la première panne à l’écran, ce qui en fait un diagnostic matériel gratuit de trente secondes qui vous nomme le domaine défaillant :

CE QU'IL TESTE (dans l'ordre)  EN CAS D'ÉCHEC, L'ÉCRAN AFFICHE
  rail d'entrée                  POWER FAIL
  régulateur de tension de cœur  VCORE FAIL
  bus de capteurs I2C            (se bloque pendant le test)
  retour tachymétrique du vent.  FAN FAIL
  détection de l'ASIC            ASIC FAIL
  courte salve de hachage        HASHRATE FAIL

COMMENT LIRE LE RÉSULTAT
  POWER / VCORE FAIL   -> section Alimentation. Le test
                          rejette une entrée s'écartant de
                          plus de 10% du nominal : mesurez
                          le bloc d'alimentation.
  ASIC FAIL            -> section Problèmes d'ASIC.
  FAN FAIL             -> ventilateur débranché, bloqué ou
                          fil tachymétrique mort.
  HASHRATE FAIL        -> puce détectée mais ne calculant
                          pas : en général alimentation
                          juste ou réglages ; revenez aux
                          valeurs d'usine.

SI LE TEST LUI-MÊME SE BLOQUE
  Écran figé sur SELF TEST plus de 30 secondes, ou boucle
  infinie SELF TEST -> redémarrage : sur AxeOS v2.12+
  maintenez le bouton BOOT 2 secondes pendant l'écran
  SELF TEST pour le sauter et atteindre le tableau de bord,
  puis diagnostiquez de là. Une boucle d'autotest après un
  flash signifie en général une mauvaise image pour la carte.

L’autotest se lance automatiquement au premier démarrage et peut être déclenché depuis les réglages. Faites-le après tout événement matériel : un transport, un remontage de dissipateur, un changement d’alimentation. Il transforme « quelque chose ne va pas » en un sous-système nommé avant même que vous ayez ouvert un seul log.

Ce que l’écran vous dit

Sur les modèles à écran, l’OLED est un instrument d’état, pas une décoration. Il fait défiler des écrans d’information toutes les quelques secondes ; le bouton BOOT avance manuellement et réveille un écran éteint par minuterie. Les états à reconnaître : l’écran de démarrage (le firmware vit), l’écran du point d’accès de configuration (non configuré ou identifiants WiFi perdus), l’écran d’adresse IP (votre porte vers le tableau de bord), l’autotest et les codes FAIL ci-dessus, un avertissement de surchauffe, et l’animation de bloc trouvé que nous espérons que vous croiserez un jour. Un écran éteint ne prouve pas que la carte est morte : vérifiez si la temporisation d’extinction s’est simplement déclenchée et si le pool voit toujours arriver des shares.

Le triage de 60 secondes

Avant d’ouvrir un seul log, répondez à cinq questions. Elles partitionnent tout l’espace du problème.

Q1  Quelque chose s'allume-t-il ? (LED, écran, ventilateur)
      NON -> DOMAINE ALIMENTATION. Allez à : Alimentation.
      OUI -> Q2

Q2  L'appareil atteint-il le tableau de bord AxeOS ou
    affiche-t-il une IP ?
      NON -> Q2a : diffuse-t-il son point d'accès de config ?
             OUI -> DOMAINE WIFI. Allez à : Réseau.
             NON -> DOMAINE DÉMARRAGE. Allez à : Firmware.
      OUI -> Q3

Q3  Le tableau de bord affiche-t-il un hashrate non nul ?
      NON -> Q3a : affiche-t-il un défaut d'alimentation, un
             bandeau de surchauffe ou 0 puce ASIC ?
             défaut alim. -> Alimentation
             surchauffe   -> Thermique
             0 puce       -> ASIC
      OUI -> Q4

Q4  Le POOL montre-t-il des shares acceptés depuis 10 min ?
      NON -> DOMAINE STRATUM. Allez à : Pool.
      OUI -> Q5

Q5  Hashrate, taux d'erreur et température sont-ils corrects ?
      NON -> Thermique ou overclock raté.
      OUI -> Rien n'est cassé. Fermez l'onglet.

Remarquez que Q4 interroge le pool, pas l’appareil. La fausse piste la plus courante du minage domestique consiste à déboguer un mineur dont l’interface semble parfaite alors que le pool ne l’entend plus depuis une heure. L’appareil et le pool voient chacun la moitié du tableau, et ce guide revient sans cesse à cette asymétrie.

Comment lire les logs

Tout le reste de ce guide va plus vite si vous savez lire les logs, cette section vient donc en premier. Il existe deux surfaces de log, et elles répondent à des questions différentes.

Le log web d’AxeOS

Ouvrez le tableau de bord à l’adresse IP du mineur et cherchez la vue de log. Elle montre le journal d’exécution en direct : trafic stratum, soumissions de shares, changements de difficulté, événements de température. C’est le bon outil quand l’appareil démarre correctement et que la question est ce qu’il fait maintenant. Sa limite : il commence une fois le réseau monté, il ne peut donc pas montrer un échec de démarrage, et il meurt avec le serveur web, il ne peut donc pas montrer un plantage.

La console série : la vérité

Pour tout ce qui touche au démarrage, aux plantages, à la détection de l’ASIC ou à l’association WiFi, il vous faut la console série. C’est la même sortie que lisent les développeurs, et elle commence à la toute première instruction.

1. Branchez un câble USB-C de DONNÉES (pas un câble de
   charge seule) entre le mineur et un ordinateur. Sur
   certaines cartes Bitaxe, une liaison native USB-C vers
   USB-C n'aboutit pas ; utilisez un câble ou adaptateur
   USB-A vers USB-C, qui force le 5V classique.

2. Ouvrez un terminal série à 115200 bauds, 8N1 :

   Windows :  PuTTY -> Serial -> COMx -> 115200
   Linux :    sudo minicom -D /dev/ttyACM0 -b 115200
              (ou : screen /dev/ttyACM0 115200)
   macOS :    screen /dev/tty.usbmodem* 115200

3. Appuyez sur le bouton RST de la carte (ou rebranchez
   l'alimentation). Le log de démarrage défile depuis le
   début.

Les lignes de log ESP-IDF portent une lettre de gravité : I pour information, W pour avertissement, E pour erreur. La plupart des terminaux affichent les lignes E en rouge. Un démarrage sain comporte zéro ligne E. Voilà tout l’art de la lecture de logs en une phrase : faites défiler le démarrage, trouvez le premier E et cherchez-le dans le dictionnaire en fin de guide. C’est la première erreur qui compte, car les suivantes sont en général des dégâts en cascade de la première.

À quoi ressemble un démarrage sain

Annoté et abrégé. Le vôtre différera dans le détail mais doit atteindre les mêmes jalons dans le même ordre.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- motif du reset. POWERON est normal. Des resets
           RTC_WDT ou BROWNOUT répétés ici sont votre
           premier signal d'alarme.

I (xx) main: Found device config: <modèle de votre carte>
        <- le firmware a identifié la carte. Un mauvais nom
           de modèle ici signifie mauvaise image de firmware.

I (xx) TPS546: Found TPS546D24A          (cartes à TPS)
I (xx) Power: VCORE set to 1150 mV
        <- le régulateur de cœur a répondu en I2C et le rail
           de l'ASIC est monté. Si ce bloc manque ou donne
           des erreurs, rien en aval ne peut fonctionner.

I (xx) bm13xx: Found 1 chip(s)
        <- LA ligne. Le nombre doit égaler celui des puces
           de votre carte : 1 en monopuce, 2 pour le GT,
           4 pour le NerdQaxe, 6 pour le Hex, 8 pour l'Octaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- réseau monté. Les échecs d'association impriment
           ici des codes de motif (dictionnaire plus bas).

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- le pool a accepté la connexion et envoyé du
           travail.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- l'ASIC renvoie des résultats. En une ou deux
           minutes vous devriez voir des shares au-dessus de
           la difficulté du pool soumis et acceptés.

Mémorisez l’ordre des jalons : motif du reset → configuration carte → régulateur → nombre de puces → WiFi → stratum → nonces. Le premier jalon qui échoue nomme la section du guide dont vous avez besoin.

Problèmes d’alimentation : la cause numéro un de tout

Si les pannes de mineurs domestiques avaient un classement, l’alimentation occuperait les trois premières places. Ces cartes font tourner du silicium en 3 nm et 5 nm à fort courant depuis des blocs grand public et par des connecteurs grand public, et les marges sont minces.

Connaissez votre architecture d’alimentation

Bitaxe monopuce (Max/Ultra/Supra/Gamma)
  Entrée :   5 V par jack (5,5x2,1mm) ou USB-C
  Courant :  jusqu'à ~5 A sur Gamma d'origine, plus en OC
  Régulateur : TPS546D24A buck numérique (anciennes cartes :
             DAC DS4432U + moniteur INA260) abaisse le 5V à
             ~1,1-1,3V de cœur ASIC à très fort courant
  Fenêtre :  le régulateur démarre vers 4,8 V et coupe sous
             environ 4,5 V

Famille 12 V (GT, Hex, NerdQaxe++, NerdOctaxe)
  Entrée :   12 V par connecteur XT30 ou jack
  Courant :  NerdQaxe++ ~8+ A à pleine charge ; Octaxe plus
  Risque :   échauffement du connecteur ; chute en charge

FAIT CRITIQUE : l'USB-C des cartes Bitaxe actuelles sert
UNIQUEMENT à l'ESP32 et au flash. Il ne peut pas alimenter
l'ASIC. Une carte en USB-C seul démarre, affiche le tableau
de bord, et hashe à exactement 0 GH/s en consommant ~2 W.
Cela imite précisément un régulateur mort et fait perdre des
heures chaque semaine dans toute la communauté.

Power Fault Detected : ce qui s’est réellement passé

Le régulateur TPS546 surveille quatre protections : surintensité, surtension, sous-tension, surtempérature. Quand l’une se déclenche, le régulateur se verrouille à l’arrêt et AxeOS affiche le bandeau de défaut d’alimentation. L’ASIC perd son rail ; l’ESP32, alimenté séparément, garde l’interface vivante. Deux faits gouvernent la solution :

• Le verrouillage survit aux redémarrages logiciels. L’état de défaut est conservé dans le registre d’état du régulateur lui-même jusqu’au retrait physique de la tension d’entrée. Redémarrer depuis l’interface web, appeler l’API de redémarrage ou presser le bouton reset de l’ESP32 ne l’efface pas. C’est un comportement documenté, pas un bug, et c’est aussi pourquoi il existe toute une classe de tickets GitHub : des cartes BM1370 bloquées à 0 GH/s consommant 5 W où l’endpoint de redémarrage ne répare rien mais un cycle d’alimentation répare tout.
• Le déclenchement est un symptôme ; la cause est en amont. Le régulateur protège une puce qui vaut plus que la carte autour d’elle. L’écrasante majorité des déclenchements récurrents remonte à l’alimentation d’entrée, pas au régulateur.

La séquence de correction, dans l’ordre :

1. CYCLE À FROID. Débranchez le connecteur d'alimentation
   lui-même (pas l'interrupteur mural). Comptez 10 secondes
   pleines. Certaines cartes réclament 60 secondes pour que
   les condensateurs de découplage se déchargent et qu'un
   état de maintien brownout de l'ESP32 s'efface. Rebranchez.
   Cela seul résout la majorité des défauts ponctuels.

2. RETIREZ L'USB-C. Si quelque chose est branché en USB-C,
   débranchez-le et vérifiez que la vraie alimentation
   (jack/XT30) est en place. Écartez le piège USB-C décrit
   plus haut.

3. MESUREZ EN CHARGE. Multimètre en continu sur le
   connecteur d'entrée PENDANT QUE LE MINEUR HASHE :
     cartes 5 V :  attendez 4,9-5,3 V soutenus.
                   Sous 4,8 V = l'alimentation est en cause.
     cartes 12 V : attendez 11,8-12,2 V soutenus.
                   Sous 11,4 V = l'alimentation est en cause.
   Une mesure à vide ne prouve rien : les blocs bon marché
   affichent 5,0 V parfaits au repos et s'effondrent à 4,4 V
   en charge.

4. ÉLIMINEZ LE CHEMIN. Branchez le bloc directement au mur :
   pas de multiprise, pas de rallonge, pas de chaînage. Les
   multiprises bas de gamme ajoutent une chute mesurable.
   Bougez le jack : si l'écran clignote, la prise ou le câble
   est usé.

5. AMÉLIOREZ L'ALIMENTATION. Spécification minimale honnête :
     cartes monopuce 5 V :   5 V / 5 A de qualité, dédiée
     classe NerdQaxe++ 12 V : 12 V / 10 A (120 W) minimum
   Les chargeurs de téléphone et les adaptateurs universels
   sont de loin la cause racine la plus fréquente de tout ce
   guide.

L’avertissement XT30

La famille 12 V pousse 8 ampères ou plus dans un XT30. Le connecteur est prévu pour ; les queues de cochon soudées à la main derrière lui souvent non. Inspectez : broches décolorées, connecteur tiède au toucher, soudures froides, sertissages lâches. Une jonction à forte résistance sous 8 A chauffe, s’oxyde, résiste davantage et chauffe encore plus : c’est le seul mode de panne du minage domestique qui finit en plastique fondu. Si le connecteur a déjà été assez chaud pour se décolorer, remplacez le câble, ne le réutilisez pas. Les NerdQaxe qui plantent avec une erreur d’alimentation et un code Guru Meditation remontent exactement à ce rail qui chute en charge.

Brownout : le plantage qui n’en est pas un

L’ESP32 possède un détecteur de brownout matériel. Quand le rail 3,3 V faiblit, il imprime Brownout detector was triggered et redémarre. Un mineur qui redémarre toutes les quelques minutes, surtout quand l’ASIC monte en pleine charge, n’a presque jamais un problème de firmware : c’est l’alimentation qui plonge au moment de la consommation maximale. La solution, ce sont les étapes 3 à 5 ci-dessus. Ne poursuivez pas le firmware pour une boucle de brownout.

Problèmes d’ASIC : la puce ne répond pas

La ligne du log de démarrage à surveiller est le nombre de puces. Le firmware énumère la chaîne d’ASIC par UART et imprime combien de puces ont répondu. Tout ce qui n’est pas le compte complet de votre carte relève de cette section.

Zéro puce détectée

Le tableau de bord affiche un compte ASIC de 0 ou le log montre un échec d’initialisation. Causes, par fréquence observée :

1. Régulateur verrouillé ou état de brownout maintenu. Une puce sans tension de cœur ne peut pas s’énumérer. Faites la décharge à froid complète de 60 secondes avant toute chose : débranchez le bloc principal, l’USB-C et tous les accessoires, attendez une minute entière, remettez sous tension. Cela seul règle une fraction notable des cas.
2. Mauvaise image de firmware. Flasher l’image d’une autre carte, même une seule fois, peut laisser une configuration d’appareil erronée en mémoire non volatile qui persiste aux reflashs. Si la ligne de modèle du log ne correspond pas à la carte physique, faites une remise à zéro d’usine complète puis flashez la bonne image. Une image BM1366 sur une carte BM1370 ne trouvera jamais la puce.
3. Événement mécanique. La séquence classique : l’unité a été déplacée, est tombée, a été expédiée, ou le dissipateur a été resserré, et elle n’a plus jamais hashé. Sous l’ASIC se trouve une matrice BGA de soudures ; la flexion les fissure. Une pression de montage inégale du dissipateur fait la même chose. Si la chronologie colle, c’est une réparation d’atelier (refusion), pas un problème de réglages.
4. Échappée d’usine. Une unité neuve qui n’a jamais hashé une seule fois a une probabilité disproportionnée d’avoir une soudure froide de fabrication. Ne passez pas un week-end sur le logiciel : faites la décharge à froid et la vérification du firmware, puis actionnez la garantie.

Compte partiel de puces : la signature multipuce

Un Hex qui annonce 3 sur 6, un NerdQaxe 2 sur 4, un GT 1 sur 2. Les cartes multipuces énumèrent les ASIC en chaîne, une seule puce morte ou déconnectée casse donc la détection à cet endroit de la chaîne : le nombre vous dit approximativement où se situe la rupture. Une carte à quatre puces affichant 2 a un problème à la puce 3. Les causes sont les mêmes que ci-dessus (marge d’alimentation, soudure fissurée) plus une propre au multipuce : une puce faible dans la chaîne qui décroche seulement à fréquence élevée. Si le compte complet revient aux fréquences d’usine mais que des puces disparaissent en overclock, vous avez trouvé le die le plus faible de votre loterie du silicium, et son plafond est celui de toute la carte.

Erreurs I2C : le bus de capteurs, pas le mineur

Une catégorie déroutante : le mineur hashe normalement pendant que Power, ASIC Temp et Input Voltage s’affichent en tirets, nuls ou zéros, et que le log montre des erreurs d’émission/réception I2C ou des dépassements de délai. Le chemin de hachage (UART vers l’ASIC) et le chemin de télémétrie (I2C vers le PMBus du régulateur, le capteur de température, le moniteur de courant) sont des bus distincts. L’un peut tomber pendant que l’autre tourne. Déclencheur connu : une bande de régression de firmware autour d’AxeOS v2.13/v2.14 où le chemin de lecture des capteurs échoue silencieusement sur une partie des unités. Également causé par tout accessoire partageant le connecteur I2C : un OLED ajouté ou un capteur externe au contact capricieux peut bloquer le bus pour les capteurs embarqués. Revenez à l’état d’origine, faites un cycle à froid, et s’il s’agit de la bande de firmware, avancez d’une version ou reculez d’une.

L’effet secondaire dangereux : sans retour de température, la courbe de ventilation ne peut pas fonctionner, le ventilateur se fige donc à une vitesse. Si la télémétrie est morte, considérez la protection thermique comme morte aussi et ne laissez pas l’unité sans surveillance tant que ce n’est pas réglé.

Problèmes thermiques : la chaleur est un budget, pas un événement

Les chiffres qui comptent

Temp. cœur ASIC   cible :      55-62 C soutenus
                  inquiétant : au-delà de 65 C constants
                  coupure :    ~75 C -> mode Overheat

Temp. VREG        tourne 10-15 C plus chaud que le cœur en
                  charge ; sur les cartes BM1370/BM1373
                  c'est souvent le capteur limitant, pas le
                  cœur

Mode Overheat     le hachage s'arrête, le ventilateur passe
                  à 100%, l'interface reste vivante ; sort
                  avec hystérésis quand la température
                  redescend vers 65 C

Diagnostic par motif

Surchauffe immédiatement à froid — problème de montage. Le dissipateur ne fait pas contact : pad thermique absent ou déchiré, pâte sèche ou absente, couple de serrage inégal, ou dissipateur desserré au transport. Une puce sans contact passe de l’ambiante à la coupure en quelques secondes. Remontez, appliquez un grain de riz de pâte de qualité, serrez les vis en croix uniformément.

Surchauffe après 10 à 30 minutes — problème de capacité. Le contact est bon mais le système n’évacue pas la chaleur aussi vite qu’il la produit. Les causes s’additionnent : ambiante au-dessus de 27 C environ, unité dans un meuble, un tiroir ou un boîtier fermé, entrée ou sortie d’air obstruée, tapis de poussière sur les ailettes, ou un overclock pour lequel le refroidissement n’a jamais été dimensionné. Donnez-lui 10 cm d’air libre des deux côtés, nettoyez les ailettes, et si cela a commencé après un changement de fréquence, ce changement était de trop.

Dérive lente sur des semaines — problème d’entretien. Mêmes réglages, température qui grimpe degré par degré : accumulation de poussière ou pâte thermique qui sèche. La pâte sur ces cartes est un consommable ; la remplacer tous les 6 à 12 mois est normal.

Surchauffe après une mise à jour du firmware — problème de courbe. Les courbes de ventilation et de chaleur changent d’une version à l’autre ; un exemple documenté autour de la v2.11 a décalé le comportement par défaut au point que les unités tournaient plusieurs degrés plus chaud et un peu plus lentement aux réglages d’usine. Lisez les notes de version, montez la vitesse du ventilateur d’un cran à la main, ou ajustez la température cible si votre firmware expose une régulation PID.

Le ventilateur lui-même

Un ventilateur qui annonce 0 tr/min à toute température est débranché, bloqué par un câble, ou mort. Un ventilateur qui hurle à 100% en permanence signifie soit une puce réellement chaude (voir ci-dessus), soit une télémétrie de température morte pilotant la courbe à l’aveugle (voir la section I2C). Les ventilateurs de rechange en 40 mm et 60 mm sont bon marché ; les modèles silencieux haut de gamme (le choix habituel de la communauté est un Noctua) descendent le bruit sous 40 dB et constituent la meilleure amélioration matérielle au rapport qualité-prix sur n’importe laquelle de ces unités.

Problèmes réseau : la vision du WiFi selon l’ESP32

La radio de chacune de ces machines ne parle que le 2,4 GHz. Ni 5 GHz, ni 6 GHz, sans exception, sans correctif firmware. Une énorme part des échecs d’installation se ramène à cette phrase qui se heurte au comportement des routeurs modernes.

Le problème des routeurs mesh

Les systèmes mesh modernes diffusent un SSID combiné unique et orientent les clients entre les bandes. L’ESP32 ne peut pas rejoindre le côté 5 GHz, et le band steering peut l’empêcher de se poser sur le 2,4 GHz. Les correctifs fiables ; la plupart des routeurs en supportent au moins un :

Option A  Créer un SSID uniquement 2,4 GHz (le mieux)
Option B  Utiliser la fonction « réseau IoT » du routeur :
          plusieurs fabricants l'ont ajoutée précisément
          pour des appareils comme ceux-ci
Option C  Désactiver le band steering / « smart connect »
          pour que les bandes apparaissent en SSID séparés

Puis vérifiez sur le SSID 2,4 GHz :
  Sécurité       WPA2-Personal, AES seul (pas TKIP, et les
                 réseaux WPA3 uniquement échoueront)
  Canal          fixe 1, 6 ou 11 en zone encombrée, pas Auto
  Largeur canal  20 MHz
  Isolation AP   DÉSACTIVÉE <- activée, le WiFi se connecte
                 mais le tableau de bord est injoignable
                 depuis votre LAN, ce qui ressemble
                 exactement à un appareil mort
  Filtrage MAC   désactivé, ou ajoutez la MAC du mineur

Lire les échecs WiFi dans le log série

La console série imprime un motif de déconnexion à chaque association échouée, et le motif nomme la solution :

AUTH_EXPIRE / auth failed      mauvais mot de passe (PSK).
                               Retapez-le ; attention aux
                               guillemets typographiques si
                               vous avez collé depuis un
                               téléphone.
NO_AP_FOUND                    SSID invisible en 2,4 GHz :
                               band steering, SSID masqué,
                               hors de portée, ou 5 GHz seul.
beacon timeout                 signal trop faible ou canal
                               encombré ; déplacez l'unité ou
                               fixez le canal.
ASSOC_TOOMANY                  limite de clients du routeur
                               atteinte.
Brownout detector triggered    pas du tout du WiFi : le pic
                               de consommation de la radio à
                               l'association fait chuter une
                               alimentation faible. Réparez
                               l'alimentation, pas le réseau.

Ce dernier point mérite d’être souligné : l’émission WiFi est le plus gros pic de charge instantané que produit l’ESP32. Une alimentation limite qui survit au repos meurt à l’association : une unité qui « plante en se connectant au WiFi » est donc souvent un problème d’alimentation déguisé en problème réseau.

Joignabilité sans échec WiFi

Deux fonctions de sécurité de routeur méritent une mention spéciale parce qu’elles bloquent les mineurs par conception. ASUS AiProtection et son équivalent sur certains modèles TP-Link classent le trafic stratum comme suspect et le rejettent silencieusement : le mineur rejoint parfaitement le WiFi puis n’atteint aucun pool. Si une unité se connecte au WiFi mais que toute connexion à un pool échoue, et que ce même pool fonctionne depuis un partage de connexion mobile, désactivez la fonction de protection du routeur ou mettez le mineur en liste blanche avant de toucher à quoi que ce soit d’autre.

Et une bizarrerie de navigateur qui génère des fausses alertes sans fin : AxeOS sert du HTTP simple sur le port 80. Les navigateurs modernes convertissent silencieusement les adresses nues en HTTPS, ce qui échoue, et le mineur semble mort. Tapez le préfixe explicitement : http:// devant l’IP, à chaque fois. Si cela échoue encore, essayez un autre navigateur et désactivez les bloqueurs de publicité pour les adresses locales.

Si le mineur a une IP mais que vous ne pouvez pas ouvrir le tableau de bord : isolation AP (voir ci-dessus), une bizarrerie de la liste de clients du routeur, ou mDNS. L’appareil s’annonce sous un nom .local ; quand plusieurs unités utilisent le même nom, le firmware moderne ajoute automatiquement un suffixe dérivé de la MAC, mais des caches mDNS périmés sur votre ordinateur peuvent encore pointer vers la mauvaise unité. Dans le doute, utilisez l’IP brute de la table DHCP du routeur et donnez à chaque unité un nom distinct.

Problèmes de stratum et de pool : le dernier kilomètre

L’appareil démarre, il hashe, et le pool est l’endroit où la vérité se décide. Dans cette section, la vue côté mineur et la vue côté pool doivent se lire ensemble.

Connexion refusée ou injoignable

Vérifiez dans cet ordre :
1. URL exacte : stratum+tcp://hôte:port - pas de https://,
                pas de barre finale, port présent et correct
2. DNS :        un autre appareil du même LAN résout-il
                l'hôte ? Certains routeurs d'opérateur et
                filtres DNS (ou bloqueurs type Pi-hole)
                avalent les domaines de minage en silence.
3. Port :       certains réseaux bloquent les ports sortants
                inhabituels. Testez via un partage de
                connexion mobile : si cela passe là-bas, le
                réseau domestique filtre.
4. Région :     essayez l'autre point d'accès régional du
                pool ; vous voyez peut-être une panne d'une
                seule région.

L’authorize échoue

Le pool a refusé la connexion. Sur un pool solo, le nom d’utilisateur est votre adresse de portefeuille plus le nom du worker, et l’adresse constitue toute l’identité : il n’y a pas de compte à mal saisir. Causes : une adresse avec une faute de frappe (un caractère suffit), une adresse de la mauvaise chaîne (voir ci-dessous), un nom de worker contenant des espaces ou des caractères spéciaux, ou un champ mot de passe que le pool attend non vide (mettez x).

L’adresse de la mauvaise chaîne : le tueur silencieux

L’erreur de configuration la plus dommageable du minage SHA-256 multichaîne, et elle peut échouer de deux façons différentes :

• Échec bruyant : le pool valide le format d’adresse par chaîne et refuse l’authorize ou chaque share. Agaçant mais sûr : vous le remarquez en quelques minutes.
• Échec silencieux : une adresse valide en format sur plus d’une chaîne, ou un pool qui ne valide pas en profondeur, accepte vos shares toute la journée, et ensuite le paiement ne peut pas vous parvenir. Sur un pool solo non dépositaire, les récompenses de bloc sont payées en coinbase direct à la chaîne de caractères d’adresse que vous avez configurée. Aucun ticket de support n’annule une coinbase versée à une adresse que vous ne pouvez pas dépenser.

La règle : l’adresse doit être native de la chaîne que vous visez, générée par un portefeuille de cette chaîne et vérifiée. Si vous faites tourner un même mineur physique entre plusieurs chaînes, tenez un tableau écrit chaîne vers adresse et revérifiez le champ nom d’utilisateur à chaque fois que vous changez l’URL stratum. Cela vaut plus que tous les autres conseils de cette section réunis.

Shares rejetés : lire les motifs de rejet

Les rejets ne sont pas un problème unique ; la chaîne de motif dans le log vous dit lequel des quatre problèmes vous avez.

"job not found" / stale       Vous avez soumis du travail
  par petites salves juste    pour un job que le pool avait
  après un nouveau bloc       déjà remplacé : normal aux
                              changements de bloc. Sous
                              ~1-2% au total : ignorez.
                              Durablement plus haut :
                              latence réseau ou perte de
                              paquets WiFi ; vérifiez le
                              RSSI, essayez la région de
                              pool la plus proche.

"above target" /              Le share n'atteint pas la
"low difficulty share"        difficulté assignée par le
                              pool. Cas persistants : un
                              décalage après un changement
                              de difficulté, ou des erreurs
                              matérielles qui corrompent le
                              résultat. Vérifiez le % erreur
                              HW.

"duplicate"                   Même nonce soumis deux fois.
                              Occasionnel : artefact de
                              renvoi inoffensif. Un flot
                              continu : état de panne connu
                              où l'ASIC boucle sur un nonce ;
                              la puce est coincée. Cycle
                              d'alimentation ; si cela
                              revient à vos fréquences
                              actuelles, réduisez l'overclock.

tout est rejeté               Configuration, pas malchance :
                              adresse de mauvaise chaîne,
                              nom de worker mal formé, ou
                              mauvais port (par ex. un port
                              à difficulté élevée prévu pour
                              les gros ASIC).

Pourcentage d’erreurs matérielles : le chiffre honnête

Le hashrate du tableau de bord est une affirmation ; le taux d’erreurs matérielles est un aveu. Il compte les résultats renvoyés par l’ASIC qui échouent à la vérification. Sous 2 pour cent, c’est sain. Un taux d’erreur qui monte avec la température signifie thermique ; un taux qui monte à température constante après un changement de réglages signifie que le point fréquence/tension dépasse le silicium de cette puce. Une puce à 5 pour cent d’erreurs peut afficher un hashrate flatteur pendant que votre hashrate effectif tombe discrètement sous ce que donnerait une fréquence plus basse. En réglage, optimisez les shares acceptés par heure, jamais le chiffre du tableau de bord. La méthode complète est dans la section réglage de la référence BM1373, et le contexte sur ce que signifie la difficulté de share dans l’explication du best share.

« Le mineur dit qu’il hashe mais le pool n’affiche rien »

Le symptôme le plus publié dans toutes les communautés, voici donc le chemin de résolution complet :

1. CÔTÉ POOL, temps depuis le dernier share accepté :
   plus de 10 minutes = la connexion est morte MAINTENANT,
   quoi que dise l'interface du mineur. Les moyennes du
   tableau de bord décroissent sur ~une heure et masquent
   les déconnexions fraîches. « Hashrate non nul » n'est PAS
   un test de présence ; « dernier share récent » l'est.

2. CÔTÉ MINEUR, log en direct :
   Des shares sont-ils SOUMIS ? Si l'ASIC trouve des nonces
   mais que rien n'est soumis, la socket stratum est
   coincée : redémarrez le mineur.
   Les soumissions donnent-elles des ERREURS ? Lisez le
   tableau des motifs de rejet.

3. IDENTITÉ : le tableau de bord du pool que vous regardez
   est-il filtré sur la même adresse de portefeuille ET la
   même monnaie que celles configurées sur le mineur ? Un
   nombre surprenant de cas sont un tableau BTC ouvert
   pendant que le mineur pointe sur BCH, ou la page d'une
   adresse de test de la veille.

4. FALLBACK : un pool de secours est-il configuré, et le
   mineur y a-t-il basculé en silence ? Votre hashrate
   arrive peut-être sur l'AUTRE pool. Vérifiez ses stats.

Configurez toujours le pool de secours

Tous les appareils de la famille AxeOS gèrent un pool de secours. Un mineur sans secours qui perd sa socket stratum à 2 heures du matin ne fait rien jusqu’à ce que vous le remarquiez, et la moyenne décroissante du tableau de bord s’assure que vous le remarquiez tard. Réglez le secours sur une deuxième région de votre pool pour qu’un incident régional n’immobilise jamais la machine. Les hôtes et ports par région pour chaque chaîne sont sur la page de connexion.

Problèmes de firmware : flasher, briquer, récupérer

L’OTA à deux fichiers et le demi-brique

Les mises à jour AxeOS arrivent en deux artefacts : le binaire du firmware et l’image de l’interface web (www.bin). Un mode de panne documenté est l’OTA qui se bloque pendant l’étape www.bin, laissant firmware et interface désynchronisés : l’appareil démarre et mine mais le tableau de bord est vide ou cassé. Ce n’est pas une brique. Allez directement à l’URL de récupération :

http://<ip-du-mineur>/recovery

et rechargez l’image web. Si l’appareil ne démarre plus du tout après une mise à jour ratée, le flasheur web USB (Chrome ou Edge, câble de données USB-C) réécrit l’image d’usine complète et récupère pratiquement toutes les briques logicielles. Trois règles rendent le flash ennuyeux au lieu d’effrayant :

• Faites correspondre l’image à la carte exactement, jusqu’à la révision. Le numéro de révision est imprimé sur le circuit imprimé lui-même et affiché dans la section Système d’AxeOS : un Supra 401 réclame l’image 401, pas la 402. Connaissez les deux types de fichiers de la page des versions : le complet esp-miner-factory-REV-vX.X.X.bin (bootloader + partitions + interface + firmware, pour le flash USB et la récupération totale) et le plus petit esp-miner.bin (firmware seul, pour l’OTA via le tableau de bord). Utiliser l’un à la place de l’autre est une recette classique de demi-brique. Image de Gamma sur un Gamma, d’Ultra sur un Ultra. Une mauvaise image peut laisser une configuration d’appareil erronée en NVS qui survit aux reflashs ordinaires ; le remède est remise à zéro d’usine plus bonne image.
• Ne flashez jamais par WiFi sur une connexion limite ou une alimentation limite. Le blocage pendant www.bin est corrélé exactement à ces deux situations.
• Connaissez votre cible de retour arrière. Les régressions arrivent : une bande de perte de télémétrie autour de v2.13/v2.14, un changement de courbe de ventilation autour de v2.11 qui faisait chauffer les unités, un chemin de mise à jour autour de v2.4.3 qui figeait certaines révisions matérielles jusqu’à ce que les utilisateurs reviennent en arrière. Avant de mettre à jour, notez votre version actuelle ; si la nouvelle se comporte mal, la précédente est à un flash web sur la page des versions du projet.

Boucles de plantage : lire une Guru Meditation

Une Guru Meditation Error est le kernel panic de l’ESP32. Le mot entre parenthèses est l’indice :

Guru Meditation Error: Core X panic'ed (MOTIF)

LoadProhibited /       bug de firmware touchant de la mémoire
StoreProhibited        invalide : notez votre version,
                       consultez le suivi de tickets, reculez
                       d'une version
IllegalInstruction     flash corrompue ou pile écrasée :
                       reflash complet par USB
Cache error /          suit en général des soucis de PSRAM
DoubleException        (plus bas)
Interrupt wdt timeout  une tâche est bloquée, souvent lié au
                       réseau ; cherchez un ticket connu sur
                       votre version

Un panic isolé : ignorez-le. Une boucle : déterminez si c’est le même motif à chaque fois (défaut firmware ou matériel : agissez selon le tableau) ou s’il s’entremêle avec des messages de brownout (alors c’est l’alimentation : arrêtez de lire des panics et allez réparer le bloc).

Pannes de PSRAM : la spécialité de la famille Nerd

Les NerdQaxe, NerdOctaxe et autres cartes construites sur le module ESP32-S3-WROOM-1 utilisent de la PSRAM externe. Une bannière de démarrage montrant une erreur de lecture d’ID PSRAM ou un échec d’initialisation, suivie d’un panic StoreProhibited dès que le firmware touche à la RAM externe, a cinq origines connues : modules contrefaits sans die PSRAM, firmware compilé avec le mauvais mode PSRAM (octal contre quad), soudure froide sous le module, brownout pendant la fenêtre d’initialisation, ou die vieillissant. Le triage pratique : écartez d’abord l’alimentation (comme toujours), flashez l’image exacte du fabricant pour votre carte (elle encode le bon mode PSRAM), et si l’erreur persiste avec une alimentation propre et le bon firmware, le module lui-même est en cause, ce qui relève de la garantie ou de l’atelier.

Overclock raté : récupération et prévention

La signature de la panne : fréquence ou tension augmentées, et maintenant l’unité plante, s’aplatit après quelques minutes ou quelques heures, se bride, ou une puce d’une carte multipuce disparaît. La physique est impitoyable sur un point précis : l’instabilité due à une fréquence trop haute met souvent du temps à apparaître. Un réglage qui survit à un test de 10 minutes peut échouer à la minute 40, quand la carte atteint sa saturation thermique, et c’est pourquoi toute affirmation de stabilité inférieure à 24 heures reste provisoire.

RÉCUPÉRATION (si l'unité démarre encore) :
  Interface web -> remettre fréquence et tension d'usine ->
  enregistrer -> cycle d'alimentation à froid (efface tout
  défaut verrouillé).

RÉCUPÉRATION (si elle boucle avant l'accès à l'interface) :
  Flashez l'image d'usine par USB : cela restaure les points
  de fonctionnement d'origine. Puis remise à zéro d'usine
  pour vider la NVS.

PRÉVENTION (toute la méthode en cinq lignes) :
  - un palier de 25 MHz à la fois, sans toucher la tension
  - 30 minutes minimum par palier, en surveillant le % HW
  - erreur au-dessus de 2% = redescendez d'un palier ; voilà
    le mur
  - seulement ensuite montez la tension par pas de 25 mV si
    vous acceptez la chaleur ; restez dans 1100-1300 mV
  - 24 heures au réglage final avant de le dire stable

Et une note honnête : sous-volter pour l’efficacité échoue exactement comme overclocker pour la vitesse, simplement dans l’autre sens : trop peu de tension pour la fréquence produit les mêmes erreurs et les mêmes blocages. La loterie du silicium s’applique aux deux extrémités.

Diagnostiquer par l’API : le raccourci de l’utilisateur avancé

Tous les mineurs de la famille AxeOS exposent une API REST sur le port 80, et cela change le visage du dépannage : pas besoin d’écran, pas de clics dans des tableaux de bord, et cela passe à l’échelle d’une unité à une flotte. La spécification complète vit dans le fichier openapi.yaml du dépôt ESP-Miner ; voici les appels qui comptent pour le diagnostic.

Les cinq appels de diagnostic

# Tout d'un coup : moyennes de hashrate, températures,
# tension, puissance, tr/min du ventilateur, shares,
# meilleure difficulté, RSSI WiFi, uptime, version, heap
curl http://IP-DU-MINEUR/api/system/info

# État de l'ASIC : modèle, nombre, fréquence, tension
curl http://IP-DU-MINEUR/api/system/asic

# La série temporelle qui alimente les graphiques
curl "http://IP-DU-MINEUR/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# LE SOUS-ESTIMÉ : télécharger les logs à distance.
# Pas de câble série, pas de PuTTY : récupérez le log par le
# réseau et filtrez les lignes rouges du dictionnaire.
curl http://IP-DU-MINEUR/api/system/logs

# Laquelle est laquelle ? Fait s'identifier l'appareil
# (écran/LED) : inestimable dans une étagère de boîtiers
# identiques
curl -X POST http://IP-DU-MINEUR/api/system/identify

Ce point de terminaison des logs mérite une phrase à lui seul : l’essentiel de la section console série de ce guide peut se faire depuis votre canapé avec ce seul appel, tant que l’appareil démarre assez loin pour servir du HTTP. Le câble série ne reste nécessaire que pour les pannes au démarrage et les boucles de plantage.

Lire /api/system/info comme un mécanicien

Six champs de ce JSON répondent à la plupart des demandes avant qu’elles ne soient formulées :

CHAMP (nom habituel)      CE QU'IL VOUS DIT
hashRate / hashrate_10m   l'affirmation : comparez au pool
temp / asicTemp           le budget 55-62 C de la section
                          thermique
vrTemp                    le côté régulateur : souvent le
                          vrai limiteur sur BM1370/BM1373
voltage                   le rail d'entrée TEL QUE LA CARTE
                          LE VOIT : un multimètre logiciel.
                          S'il tombe sous 4,9 V en charge =
                          l'alimentation, prouvé sans ouvrir
                          le boîtier
power                     watts consommés : 2 W sur une
                          unité « qui hashe » = piège USB-C
sharesAccepted /          le duo de vérité ; rejets qui
sharesRejected            grimpent = tableau des motifs
wifiRSSI                  plus fort que -70 dBm est sain ;
                          plus faible explique les shares
                          périmés
freeHeap                  qui rétrécit lentement sur des
                          jours = la classe de bug de fuite
                          mémoire ; notez la version,
                          consultez le suivi

Santé de la flotte en une boucle

Au-delà d’une unité, arrêtez de consulter des tableaux de bord. Cette boucle imprime un résumé de santé d’une ligne par mineur et signale les morts :

#!/bin/bash
# fleet-check.sh - adaptez les IP à votre essaim
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  INJOIGNABLE"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

Lancez-la depuis cron toutes les cinq minutes, envoyez-la vers la notification de votre choix, et une panne à 2 heures du matin devient une alerte à 2h05 au lieu d’une surprise au réveil. Les noms de champs varient légèrement selon les versions de firmware ; affichez le JSON brut une fois et adaptez.

L’API répare aussi

# Redémarrer sans toucher au matériel
curl -X POST http://IP-DU-MINEUR/api/system/restart
#   (rappel : cela n'efface PAS un défaut TPS546 verrouillé,
#    il faut toujours le débranchement physique)

# Ramener une expérience d'overclock à des valeurs saines
curl -X PATCH http://IP-DU-MINEUR/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# Corriger une config de pool mal tapée sans l'interface
curl -X PATCH http://IP-DU-MINEUR/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "VOTRE_WALLET.worker1"}'

Une réserve honnête : l’API n’a aucune authentification. N’importe qui sur votre LAN peut lire et reconfigurer vos mineurs. Sur un réseau domestique c’est en général acceptable ; sur un réseau partagé ou accessible aux invités, mettez les mineurs sur leur propre VLAN ou segment IoT : ce qui est commodément le même correctif que celui déjà recommandé dans la section WiFi.

Particularités par modèle : connaissez le caractère de votre carte

Au-delà des modes de panne universels, chaque famille de cartes a des comportements caractéristiques qu’il vaut mieux connaître avant d’en déboguer une.

Le tableau maître des symptômes

Le dictionnaire des lignes rouges

Les chaînes d’erreur que vous verrez vraiment, réunies au même endroit, écrites mot pour mot pour que Ctrl+F les trouve. Trouvez votre ligne, obtenez votre direction.

LIGNE DANS LE LOG                  SIGNIFICATION -> OÙ ALLER
---------------------------------------------------------------
Brownout detector was triggered    chute de tension -> Alim.
rst:0x.. (BROWNOUT_RESET)          idem, dans le bandeau de reset
Power Fault Detected               TPS546 verrouillé -> Alim.
TPS546 status / regulator fault    même famille -> Alim.
VCORE init failed /                le firmware ne peut pas
  device ID mismatch               programmer le régulateur :
                                   mauvaise image ou I2C ->
                                   ASIC + Firmware
i2c_master_transmit_receive err /  bus de capteurs mort -> ASIC,
  ESP_ERR_TIMEOUT near boot          sous-section I2C
Found 0 chip(s) / ASIC init fail   la puce ne répond pas -> ASIC
Chip count N of M                  rupture de chaîne en N+1 -> ASIC
Device has overheated /            coupure à 75 C -> Thermique
  Overheat Mode
VREG temp over limit               régulateur chaud -> Thermique
wifi: NO_AP_FOUND                  visibilité 2,4 GHz -> Réseau
wifi: AUTH_EXPIRE / auth fail      mauvais mot de passe -> Réseau
wifi: beacon timeout               signal ou canal faible -> Réseau
wifi_disconnect reason: N          cherchez N ; corrigez par motif
Stratum connection failed /        pool injoignable -> Stratum
  connect errno
authorize failed                   connexion refusée -> Stratum,
                                   vérifier adresse et worker
job not found (à la soumission)    share périmé -> Stratum
above target / low diff share      décalage de difficulté ou HW
duplicate share                    nonce coincé -> cycle d'alim.,
                                   puis réduire la fréquence
Guru Meditation Error: (MOTIF)     panic -> Firmware, lisez le
                                   mot du motif
esp_psram: PSRAM ID read error /   init PSRAM -> Firmware,
  Failed to init external RAM        sous-section famille Nerd
E (xx) esp_image: checksum failed  flash corrompue -> reflash USB
[www.bin / interface vide après]   URL de recovery -> Firmware

Maintenance préventive : le rituel mensuel de 15 minutes

Presque tout ce qui précède coûte moins cher à prévenir qu’à déboguer.

CHAQUE MOIS
  [ ] Poussière : ailettes et pales du ventilateur (air
      comprimé, en bloquant le ventilateur)
  [ ] Contrôle côté pool : tendance acceptés contre rejetés,
      et % erreur HW toujours sous 2
  [ ] Coup d'oeil aux températures : dérive par rapport au
      mois dernier ?
  [ ] Toucher physiquement le connecteur d'alimentation :
      tiède est un avertissement, chaud est un arrêt

TOUS LES 6-12 MOIS
  [ ] Remplacer la pâte thermique (c'est un consommable)
  [ ] Inspecter les broches XT30 ou jack pour décoloration
  [ ] Revérifier l'alimentation en charge au multimètre

À CHAQUE MISE À JOUR DE FIRMWARE
  [ ] Lire les notes de version AVANT de flasher
  [ ] Noter la version actuelle (votre cible de retour)
  [ ] Flasher sur une alimentation stable, si possible près
      du routeur
  [ ] Revérifier la config de pool après : les mises à jour
      peuvent réinitialiser des champs

TOUJOURS
  [ ] Pool de secours configuré (deuxième région)
  [ ] Noms de worker distincts sur toute la flotte
  [ ] Tableau écrit : chaîne -> adresse de portefeuille
  [ ] Réglages d'usine notés avant tout réglage

Quand c’est vraiment du matériel : ce qui est réparable

Vous avez fait le cycle à froid, la remise à zéro d’usine, le reflash de la bonne image sur une alimentation vérifiée, et le défaut persiste. C’est la définition d’un problème matériel. La carte réaliste des réparations :

• Réparable en atelier (air chaud, microscope, main sûre ou un professionnel) : TPS546 ou composants de l’étage buck défaillants, condensateurs céramiques fissurés, soudures froides sous l’ASIC ou le module ESP32 (refusion), connecteurs d’alimentation usés, ventilateurs morts. C’est de la routine pour tout atelier de réparation d’ASIC.
• Parfois récupérable : une carte avec un court-circuit franc sur le rail 5 V (quasi zéro ohm à la masse, hors tension) — n’appliquez plus de tension ; il faut d’abord trouver et supprimer le court.
• En général terminal : un ASIC ayant tourné sans contact avec le dissipateur plus de quelques secondes, les suites d’un emballement thermique, ou une puce alimentée avec la mauvaise tension de cœur pendant une réparation improvisée du VRM. Sur une carte monopuce, la puce représente l’essentiel de la valeur : passé un certain point, remplacer bat réparer.

L’aide communautaire vit sur le Discord OSMU et le suivi de tickets GitHub d’ESP-Miner : avant d’ouvrir un ticket, cherchez d’abord dans le suivi, car une part frappante des signalements « mon appareil est cassé » sont des tickets connus dont le correctif est déjà fusionné pour la version suivante. Au moment de signaler, un rapport complet obtient une réponse en quelques heures là où un rapport vague meurt en silence. Copiez ce modèle :

CARTE :     (modèle exact + révision, par ex. Gamma 602)
FIRMWARE :  (version AxeOS, du tableau de bord ou de
             /api/system/info)
ALIM. :     (tension, ampères, marque, et : mesurée en charge ?)
POOL :      (URL + port + monnaie)
SYMPTÔME :  (une phrase : ce qui se passe, depuis quand)
DÉCLENCHEUR : (ce qui a changé juste avant : mise à jour ?
             transport ? OC ? remontage du dissipateur ? rien ?)
ESSAYÉ :    (cycle à froid 60s ? remise à zéro ? reflash ?
             fréquences d'usine ? résultat de l'autotest ?)
LOG :       (collez le log de démarrage depuis le série 115200
             ou depuis curl http://IP/api/system/logs ; au
             minimum la première ligne E et dix lignes autour)

Ce modèle n’est pas de la bureaucratie : ce sont exactement les informations qu’un atelier de réparation collecte en premier, dans l’ordre où il les collecte.

PRO : la section atelier — schémas, points de mesure et multimètre

Cette section suppose que vous savez lire un schéma et sonder une carte sous tension sans court-circuiter des broches voisines. Si cette phrase vous fait hésiter, arrêtez-vous ici : tout ce qui précède cette ligne se résout sans ouvrir le boîtier, et une pointe de touche qui dérape sur une carte vivante en 3 nm transforme un problème en deux. Pour les autres, c’est ici que le matériel ouvert paie.

Pourquoi ces cartes diffèrent de tout autre mineur

Le matériel Bitaxe est sous licence CERN-OHL-S et conçu sous KiCad, et chaque schéma, chaque routage de circuit imprimé et chaque nomenclature est public. Cela veut dire que vous ne devinez jamais ce qu’est un composant ni où passe un rail : vous pouvez ouvrir le schéma exact de votre révision exacte, trouver le net et le mesurer. Aucun propriétaire d’Antminer n’a jamais eu ce privilège. Chaque dépôt matériel porte en outre une section que presque personne n’ouvre : la page HW issues avec les bugs connus, les reprises et les errata par révision. Avant de diagnostiquer toute panne au niveau de la carte, vérifiez si votre révision a un erratum documenté : une part frappante des pannes matérielles « mystérieuses » y est déjà écrite, avec la modification qui les corrige.

La méthode du multimètre : trois rails racontent toute l’histoire

Les pannes du chemin d’alimentation se localisent avec trois mesures en continu, prises dans l’ordre. Référence à la masse d’abord, respectez la séquence, et mesurez en charge là où c’est indiqué.

RAIL 1 - ENTRÉE (5 V ou 12 V selon la famille)
  Où :       connecteur ou pastilles d'entrée (voir schéma)
  Attendu :  famille 5 V :  4,9 - 5,3 V  PENDANT LE HACHAGE
             famille 12 V : 11,8 - 12,2 V PENDANT LE HACHAGE
  Bas seulement en charge -> bloc ou câble (la plupart)
  Affiche 0 avec un bon bloc -> protection d'entrée grillée
                                ou court en aval : mesurez la
                                résistance à la masse HORS
                                TENSION ; quasi zéro ohm =
                                court, cessez d'alimenter et
                                cherchez-le

RAIL 2 - 3,3 V (l'alimentation de l'ESP32)
  Où :       net 3,3 V selon le schéma (module ESP32)
  Attendu :  3,2 - 3,4 V stables
  Absent avec une entrée correcte -> le petit régulateur
  3,3 V ou ses passifs : explique « totalement mort, aucune
  énumération USB » avec un bloc prouvé bon

RAIL 3 - VCORE (l'alimentation de l'ASIC)
  Où :       sortie de l'étage buck TPS546 / net de cœur
  Attendu :  environ 1,0 - 1,3 V, correspondant à la valeur
             réglée dans AxeOS
  Absent avec entrée et 3,3 V corrects -> l'étage buck :
  défaut verrouillé (toujours cycle à froid d'abord), ou
  TPS546 / self / passifs environnants défaillants
  Présent mais mauvaise valeur -> programmation du régulateur
  ou communication PMBus : recoupez avec ce qu'AxeOS croit
  avoir réglé

MESURES DE CONFIRMATION
  Continuité connecteur d'entrée -> entrée du régulateur :
  trouve les pistes coupées et les soudures de jack fissurées
  Température de die du TPS546 au tableau de bord contre la
  main approchée : un régulateur dont on ne peut approcher au
  repos est en train de lâcher

Ces trois rails partitionnent toute panne d’alimentation : entrée mauvaise = en amont de la carte ; entrée bonne et 3,3 V mauvais = le petit régulateur ; les deux bons et VCORE mauvais = l’étage buck ; les trois bons = la panne n’est pas électrique, retournez à la section ASIC. Dix minutes avec un multimètre à vingt dollars remplacent des heures de spéculation.

Ce qu’un atelier peut et ne peut pas faire

ROUTINE (air chaud + microscope + main sûre)
  - remplacement du TPS546 ou de composants de l'étage buck
  - condensateurs céramiques fissurés (visuel : fissure fine
    traversant le corps ; électrique : court ou circuit ouvert)
  - refusion BGA sous l'ASIC ou le module ESP32 (la classe de
    panne après chute et après remontage)
  - remplacement de connecteurs (jack usé, XT30 cuit)

POSSIBLE AVEC DE LA PATIENCE
  - traquer un court sur le rail 5 V (caméra thermique ou
    l'astuce de l'évaporation d'isopropanol sur les zones
    suspectes)
  - échange du module ESP32-S3 (reflash nécessaire ensuite)

PAS RENTABLE / TERMINAL
  - remplacer l'ASIC sur une carte monopuce : la puce est
    l'essentiel de la valeur de la carte et les puces
    donneuses sont de toute façon récupérées ; une carte
    neuve gagne en coût et en certitude
  - tout ce qui suit un emballement thermique ou une entrée
    en polarité inversée sur tout le rail

Lire le schéma comme un technicien

Trois habitudes qui rendent les schémas ouverts réellement utiles. Premièrement, trouvez la page de l’arbre d’alimentation et tracez une fois sur papier le chemin de l’entrée jusqu’à VCORE avant de sonder quoi que ce soit : vous connaissez alors chaque composant capable de tuer le rail. Deuxièmement, notez les repères (R12, C34, U3) de l’étage buck : les messages de forum et les errata désignent les pièces par leur repère, et les retrouver sur votre carte prend quelques secondes avec le fichier de routage ouvert. Troisièmement, comparez les révisions quand une panne est propre à une révision : le journal des modifications entre, disons, un Gamma 600 et un 601 vous dit exactement ce que les concepteurs ont corrigé, ce qui est souvent exactement ce qui lâche sur l’ancien.

La bibliothèque de ressources open source

Toutes les sources primaires dans un tableau. Mettez cette section en favori : la moitié de la valeur du matériel ouvert tient à savoir où vivent les originaux, et chaque lien ci-dessous est la source officielle, pas un miroir.

À retenir

• Six domaines couvrent presque toutes les pannes : alimentation, ASIC, thermique, réseau, stratum, firmware. Le triage de 60 secondes vous dit dans lequel vous êtes avant que vous touchiez à quoi que ce soit.
• L’alimentation est la cause numéro un et l’imposteur numéro un : elle se déguise en plantages WiFi, panics de firmware, puces coincées et cartes mortes. Mesurez l’entrée en charge avant de croire à toute autre théorie.
• Un défaut verrouillé du régulateur survit à tout redémarrage logiciel. Débrancher physiquement pendant 10 à 60 secondes est une vraie étape de diagnostic, pas une superstition.
• L’USB-C alimente l’ESP32, jamais l’ASIC. Une carte en USB-C seul imite parfaitement un mineur mort à 0 GH/s.
• Apprenez la console série à 115200 bauds. La première ligne E d’un log de démarrage nomme votre problème plus vite que n’importe quel fil de forum.
• L’autotest intégré nomme le sous-système défaillant en 30 secondes, et l’API REST récupère les logs, la télémétrie et même le correctif par le réseau : servez-vous des deux avant de chercher un câble série.
• Ne branchez jamais une alimentation 12 V sur une carte 5 V. Les prises sont interchangeables ; les cartes non.
• L’ESP32 ne parle que le 2,4 GHz ; le band steering et l’isolation AP sont les deux fonctions de routeur qui cassent le plus d’installations.
• La vérité côté pool bat l’optimisme côté mineur : le temps depuis le dernier share accepté est le seul test honnête de présence, et 10 minutes est le seuil.
• L’adresse de portefeuille doit être native de la chaîne minée. Sur un pool non dépositaire, c’est la seule erreur sans retour possible.
• Le pourcentage d’erreurs matérielles est le chiffre honnête de performance ; le hashrate du tableau de bord est une affirmation. Réglez vers les shares acceptés et exigez 24 heures avant de qualifier un réglage de stable.
• Un connecteur d’alimentation chaud est le seul symptôme qui veut dire arrêter maintenant, pas déboguer plus tard.

Compilé à partir du suivi de tickets et des notes de version d’ESP-Miner, de la documentation ESP-IDF sur les erreurs fatales, de la documentation des ateliers de réparation de la communauté et des schémas de panne récurrents signalés dans les communautés Bitaxe, NerdAxe et NerdQaxe, au 20 juillet 2026. Le comportement du firmware décrit ici (verrouillage des défauts, seuils de surchauffe, URL de récupération, bandes de régression connues) reflète les versions d’AxeOS et d’ESP-Miner en vigueur à la publication ; consultez les notes de version de la vôtre. Ce guide est maintenu comme une référence vivante : si vous rencontrez un mode de panne non couvert ici, dites-le-nous via la page de contact et nous l’ajouterons.