Passer au contenu

Nous améliorons nos opérations pour mieux vous servir. Les commandes sont expédiées normalement depuis Laval, QC. Questions? Contactez-nous

Bitcoin accepté au paiement  |  Expédié depuis Laval, QC, Canada  |  Soutien expert depuis 2016

BITAXE_GT_HALF_CHIP Warning

Bitaxe GT – Dual BM1370 One Chip Not Starting

Bitaxe GT - One of two BM1370 ASICs fails to enumerate at AxeOS chain init; serial log shows 'Chain init: 1/2 chips found' or 'Chip 1 no response', dashboard reports ~50% of nameplate hashrate (~1.1-1.3 TH/s instead of ~2.4 TH/s), power draw ~12-14 W instead of ~22-28 W.

Warning — Should be addressed soon

Affected Models: Bitaxe GT (Turbo) - dual BM1370 topology, all current GT board revisions running ESP-Miner / bitaxeorg/ESP-Miner firmware. Symptom logic isolates cleanly to chip 1 of the two-chip UART daisy chain; chip 0 must enumerate first for the chain to start, so 1/2 reports always identify chip 1 as the silent position.

Symptoms

  • AxeOS dashboard loads normally but System Info -> Chip Count reads 1 instead of 2 on the Bitaxe GT
  • Total reported hashrate sits around half of nameplate - roughly 1.1-1.3 TH/s reported instead of ~2.4 TH/s expected at stock tune
  • Power draw at the wall reads ~12-14 W instead of the GT's nominal ~22-28 W at stock tune
  • Per-chip stats grid shows one chip reporting hashrate, the other reading 0 GH/s, N/A, null, or blank
  • Per-chip temperature reads sane (50-75 C) on the working chip, and 0 C, N/A, -1 C, or absurd value on the silent chip - that telemetry channel never came up
  • Serial console at 115200 baud shows a chain-init log line such as 'Chain init: 1/2 chips found', 'Chip 1 no response', or 'BM1370 init failed' for the second position
  • Boot log shows chip 0 enumerating with a hex response byte (Chip 0 response: 0xXX), then chip 1 returning a no-response or all-0xFF read
  • Heatsink heats unevenly across the two chip positions - the working BM1370 is warm/hot to the touch, the dead one is room-temperature even after 10+ minutes of running
  • Pool dashboard (Public-Pool, CKpool solo, Ocean, Braiins) shows the GT online and submitting shares but at clearly degraded effective hashrate vs historical baseline
  • Vin reads clean (4.95-5.20 V) at the barrel jack under load, ruling out gross PSU failure - but transient sag during chain-init still possible
  • Symptom appeared after a transport/drop/heatsink remount, OR appeared overnight after months of clean operation, OR has been present since the GT first powered on (factory QA escape)
  • Chip count: 1 is consistent across reboots (always the same chip silent), or it is intermittent (sometimes 2/2, sometimes 1/2) - the consistency pattern dictates which root cause is most likely
  • No visible package damage, no scorch marks, no discoloured solder around either BM1370 - the failure is handshake-level, not thermally catastrophic

Step-by-Step Fix

1

Full cold-boot with 60-second discharge. Unplug EVERYTHING from the GT - main barrel-jack PSU, USB-C, fan cables, any accessory. Wait a full 60 seconds. The GT's bulk input caps on the 5 V rail need real time to fully discharge before the next boot runs a clean chain-init sequence. A soft reboot via AxeOS can leave the dual-BM1370 UART chain in a hung state where chip 1 never re-enumerates because the chain is mid-frame. During the 60-second wait, note which PSU is in use - shared power strip with two miners on it, dedicated brick, the one that shipped with the GT, or a random-shelf-replacement? That question alone resolves a non-trivial fraction of intermittent 1/2 tickets and is the cheapest test in the shop.

2

Re-seat the barrel-jack power connector. A loose 5.5 x 2.1 mm barrel jack can make solid contact most of the time but lose the last 0.5 mm of grip under thermal expansion, dropping the 5 V rail momentarily and forcing the chain to re-init mid-hash. The GT is more sensitive to this than the single-chip Gamma because the dual-chip transient is bigger. Pull the connector fully out, inspect both halves for bent pins, oxidation, or debris, and reseat with firm pressure until it is fully home. If you have a spare 5 V / 6 A cable on hand, swap it in - barrel jacks are cheap and the failure rate on no-name cables is higher than people expect.

3

Open the serial console and confirm WHICH chip is silent. USB-C data cable PC-to-GT, serial terminal at 115200 baud, 8N1. Power-cycle with the main PSU, watch the boot stream, screenshot the chain enumeration lines (BM1370 chain init, Chip 0 response: ..., Chip 1 response: ..., Chain init: 1/2 chips found or equivalent). The first silent position is your fault site and the single most important piece of information for every subsequent step. Include this screenshot in any support ticket - D-Central, bitaxeorg Discord, OSMU wiki, GitHub - because it skips ten rounds of 'did you try X' with whoever is helping you.

4

Swap to a known-good dedicated 5 V / 6 A regulated brick. If you are running the GT from a shared DC supply, a cheap wall-wart, a USB-PD trigger cable, or a brick you have had on the shelf for five years, this is a likely cause of intermittent chip drops on a dual-chip board. Use a name-brand Mean Well or CUI brick, or a D-Central GT-validated PSU bundle. Plug in, power-cycle, re-check Chain init. A real fraction of 'one chip dropped overnight' reports trace back to a PSU that finally aged out of spec and can no longer source the GT chain-init transient cleanly.

5

Re-flash the correct GT firmware image via the Web Flasher. Open bitaxeorg.github.io/bitaxe-web-flasher/ in Chrome or Edge (WebSerial only works in Chromium browsers). CRITICAL: select the EXACT GT dual-BM1370 image AND match your board revision. Do NOT flash the single-chip Gamma BM1370 image - that build only expects one chip and will report Chain init: 1/1 or similar, which gets mistaken for 'second chip dead'. Flash, wait for completion (~60 seconds), full power-cycle (USB-C AND main PSU unplugged 30 seconds), reconnect, re-verify chain enumeration in the serial console.

6

NVS factory-reset after the re-flash. A previous wrong-image flash, a partial OTA, or an aborted firmware update can leave stale config in NVS that the correct GT firmware then reads and gets confused by. After Step 5: AxeOS dashboard -> Settings -> Restore Defaults (where the button exists in your firmware version), or via serial console issue the nvs_erase / factory-reset sequence appropriate for your build. Then re-flash the correct GT image once more and full power-cycle. This belt-and-braces sequence clears the last common software-state confusion before moving to hardware diagnostics - and on a dual-chip board it matters more than on a single-chip board because there is more state to corrupt.

7

DMM-verify the 5 V rail under a real chain-init transient. Open-circuit DMM is not enough for the GT - the dual-chip chain-init pulls hard on the rail for ~10 seconds at boot. Open-circuit at the barrel jack: 4.95-5.20 V. Under chain-init transient (you need to measure during the first 10 seconds of boot, not at idle): the rail must hold >= 4.85 V sustained with no audible chirp, no visible droop on a scope. A halogen-bulb dummy load or USB-PD load tester can simulate this for a clean static measurement. Voltage sag beyond 0.3 V under transient, oscillation, or any chirp from the brick = replace the PSU. This single measurement cuts a meaningful fraction of 'dead chip' diagnoses into 'bad PSU' cases.

8

DMM-verify per-chip Vcore while AxeOS is running at idle. Power the GT, let AxeOS come up (you will see the 1/2 chain), DMM on DC volts, probe each chip's Vcore test point against GND. Reference the skot/ESP-Miner hardware repo for exact test-point locations on your board revision; both rails are silkscreen-labelled on most GT revisions. Both should read in the ~1.20-1.30 V band, matching within +/- 30 mV. If chip 1's Vcore reads close to chip 0's: fault is at UART/handshake level (continue to Step 10). If chip 1's reads 0 V: chip 1's regulator or local filtering is damaged (Tier 3 inspection). If chip 1's reads abnormal but non-zero (e.g., 0.7 V, oscillating): marginal regulator (Tier 3 inspection).

9

Inspect the heatsink mount and PCB for flex. Power off, unplug everything, remove the heatsink carefully - the GT's heatsink covers both BM1370 chips with a single thermal interface, so uneven mount = uneven cooling = uneven thermal cycling. Check: thermal paste / pad distribution across both chips - is it evenly squeezed, or is one position obviously under- or over-pressured? Lay the bare board flat on a table - any visible PCB bow or twist under either chip? Screws all at similar tightness, or is one cranked tighter? Clean off old paste with 99% isopropyl, re-apply fresh paste (Arctic MX-6 or Kryonaut) in a thin even layer over both chips, remount with finger-tight-plus-quarter-turn on each screw. Re-power, re-check chain enumeration.

10

Cross-reference serial log fault position with physical chip layout. Identify which BM1370 is physically chip 0 and which is chip 1 on your GT board revision. The silkscreen typically labels them (U1/U2, BM1370_0/BM1370_1, or similar) and the chain-enumeration order maps to physical position - reference the bitaxeorg / skot ESP-Miner hardware schematics for the chain-order-to-silkscreen mapping on your revision. Identify chip 1 now, before Tier 3, because every subsequent step targets that one chip specifically.

11

Scope the UART chain signal between chip 0's output pin and chip 1's input pin. Put a 100 MHz-bandwidth or better handheld scope (Hantek 2D72, Owon HDS320S, or any decent 100+ MHz USB scope) on the chain trace during a boot cycle. Healthy: clean 3.3 V logic levels with recognisable UART framing - start bit, eight data bits, stop bit, all transitioning in the tens-of-nanoseconds range. Broken: no signal at all (trace damaged), severe ringing or glitching (damaged passives in the path, broken termination), or signal arrives at chip 1's input pin but no reply leaves chip 1's output (chip 1 itself is the fault). This single measurement distinguishes 'chip alive but not responding' from 'chip never received the command' - critical before committing to chip replacement vs trace patch.

12

Single-chip BM1370 reflow on chip 1 with adjacent-chip shielding. Mask chip 0 with aluminium foil cut to fit (leave a small gap for airflow) or Kapton tape; protect connectors, the EMC2101, the OLED ribbon, the ESP32-S3 module, and any through-hole parts from hot air. Preheat the board bottom-side to ~150 C on a proper preheater (Hakko / Quick brand - not a hot plate; even heating across the GT's PCB matters). Apply hot air top-side at ~310-330 C, moving in small circles over chip 1 for ~30 seconds. Do NOT stop on one spot for more than 3-4 seconds or adjacent 0402 caps will lift and tombstone. Cool in place on the preheater to ~80 C, then to ambient. Reflow recovers a large fraction of GT 1/2 failures where the cause is factory cold joint or thermal-cycling-induced crack.

13

Single-chip BM1370 replacement on chip 1. If reflow fails, the chip itself is dead and needs replacing. Desolder chip 1 with hot air + low-melt solder / Chip Quik, lift cleanly, clean pads with braid + flux, place a graded BM1370 replacement (D-Central inventory or a verified supplier with confirmed date code - mismatched date codes between the GT's two chips is anecdotally tied to slightly higher tuning variance but not failure), reflow down with a proper BGA thermal profile, inspect alignment under the microscope before powering. After reflow: fresh thermal paste, heatsink remounted with even torque on both chips, re-flash factory GT image, power up, verify Chain init: 2/2 in the serial console.

14

Diagnose intermittent Chain init drift with thermal-bake-out. If Chain init is inconsistent across reboots (sometimes 2/2, sometimes 1/2, sometimes only after warm-up or only when cold), suspect a marginal solder joint that opens at a specific temperature threshold. Controlled bench test: run the GT at full workload for 2+ hours, log chip count every 60 seconds via serial console or AxeOS API, watch for the transition timestamp. Once you know which chip drops and at what temperature, you can target the reflow at the right joint. If the fault is deeply intermittent and your bench cannot reliably reproduce it, ship to D-Central for scope-level diagnosis with proper thermal fixtures.

15

Re-flash firmware image after ANY Tier-3 rework. Hot-air work can briefly raise the SPI flash IC's temperature above its retention spec and corrupt data silently - a known failure mode after chip-adjacent rework on dense boards. After any chip-level rework on the GT, re-flash the correct dual-BM1370 firmware via the Web Flasher BEFORE full-load validation. Verify the dashboard reports both chips before declaring the repair complete. Common 'the repair did not take' failure mode: hardware is fine, leftover rework-induced flash corruption is masking it. Always re-flash, always verify chain enumeration, always confirm 2/2 before declaring done.

16

Stop DIY on BGA rework if you do not have a real preheater + controlled-temperature hot-air station + rework microscope. BM1370 is a BGA package - iron-only rework is not a path. Without a preheater, the thermal gradient across the GT's PCB rips pads off and turns a $95 CAD repair into a $290 CAD board scrap. Without controlled hot-air temperature, you will char the FR-4, blow adjacent passives on chip 0's side, or melt the OLED ribbon. Without a rework microscope, BGA alignment is guesswork and solder bridges are guaranteed. Ship the GT. D-Central bench has the full BGA rework stack - Hakko preheaters, Quick / Hakko hot-air stations, stereo microscopes, reflow ovens, and BM1370 graded inventory on the shelf.

17

Stop DIY on dual-chip GT failures where the cause is inconsistent across reboots. If the serial log shows 2/2 at room temperature but drops to 1/2 after 30+ minutes of runtime - or shows different behaviour on different power-on attempts - you are chasing an intermittent solder fault or an intermittent regulator fault. Both need controlled thermal bake-out testing plus scope-level probing at the chain-trace and regulator-PMBus level - not practical at home without dedicated test rigs and thermal chambers. D-Central has the rigs.

18

Stop DIY on suspected Vcore regulator damage. If chip 1's Vcore rail reads 0 V or wildly abnormal at Step 4 / Step 8, the TPS546D24x feeding chip 1 is suspect. Replacing an integrated buck converter on a GT requires hot-air desoldering of a small QFN package adjacent to chip 1 itself, careful pad cleanup, placement of a verified TI replacement (D24A or D24S matched to your firmware tolerance), and a precise reflow profile that does not disturb chip 1's BGA next door. This is a delicate two-package rework - bench territory, not basement territory.

19

Ship to D-Central with serial logs + PSU + context. Pack the GT in an anti-static bag, include the original PSU (we test your exact stack), attach a note with: board revision (from silkscreen), firmware version, the serial console boot log showing the 1/2 enumeration (screenshot or paste), Tier 1/2 steps already tried, observed behaviour pattern (consistent 1/2 always, or intermittent 2/2 <-> 1/2?), and any context (transport/drop, surge, recent heatsink remount, recent firmware upgrade, new-out-of-box, runtime hours). Canada-wide shipping, US/international welcomed. Turnaround 5-10 business days. We have been in the Bitaxe ecosystem since day one - built the original Mesh Stand, manufactured the first Bitaxe and Bitaxe Hex heatsinks - and we keep BM1370 graded inventory specifically for single-chip GT and Gamma swaps.

20

Consider repair economics vs full GT replacement. A Tier-4 single-BM1370 swap at D-Central runs CAD $95-185 depending on chip sourcing and labour time. Single-TPS546 regulator replacement (rarer): CAD $85-165. Combined chip + regulator damage: CAD $175-325. A new Bitaxe GT board runs roughly CAD $290-450 depending on revision and stock. If diagnosis reveals damage to both chips OR multi-component damage (chip + regulator + chain trace), replacement may be the better economic path, and we will say so up front - open hardware means an honest conversation, not lock-in. Single-side failures almost always favour fixing.

21

Log the repair history for preventative planning. Whatever the outcome, note in your mining log: date of failure, chip-1 vs chip-0, serial-log fingerprint at fault, ambient temperature when failure occurred, runtime hours on the board, last heatsink re-paste date, last firmware version flashed. If you run multiple GT units (solo-mining stack, heat-recovery setup), the pattern across the fleet tells you whether your failures are random (factory QA escapes) or systemic (PSU stack, ambient, heatsink mounting practice) - and whether it is time to upgrade PSUs, improve airflow, or set a tighter preventative-maintenance cycle. The dual-chip GT runs hotter per chip than a single-chip Gamma; treat it accordingly.

When to Seek Professional Repair

If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.

Related Error Codes

Still Having Issues?

Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.