Bitaxe Hex – One ASIC Dead / Only 5 of 6 Chips Hashing

Full cold-boot with 60-second discharge. Unplug EVERYTHING from the Hex - main PSU (XT30 or barrel), USB-C, fan cables, any accessory. Wait a full 60 seconds. The Hex's bulk input caps on the 12 V rail need time to fully discharge before the next boot runs a clean chain-init sequence. A soft reboot via AxeOS can leave the UART chain in a hung state where one chip will not re-enumerate. During the 60-second wait, note which PSU is in use - shared power strip, dedicated brick, the one that shipped with the Hex or a random replacement. That question alone resolves a non-trivial fraction of intermittent chip-count tickets.

Re-seat the XT30 / barrel power connector. A loose or partially-inserted XT30 connector can make solid contact most of the time but lose the last 0.5 mm of grip under thermal expansion, dropping the 12 V rail momentarily and forcing the chain to re-init mid-hashing. Pull the connector fully out, inspect both halves for bent pins or debris, reseat with firm pressure until it clicks home. If you have an XT30-to-XT30 replacement cable on hand, swap it in - XT30 cables are cheap and the failure rate on no-name imports is higher than people expect.

Open the serial console and confirm WHICH chip is silent. USB-C data cable PC-to-Hex, serial terminal (screen / minicom / PuTTY / VS Code Serial Monitor) at 115200 baud, 8N1. Power-cycle with the main PSU, watch the boot stream, screenshot the chain enumeration lines (Chip 0 response through Chip 5 response, plus Chip N no response). 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 - because it skips ten rounds of 'did you try X' with whoever is helping you.

Swap to a known-good dedicated 12.0 V / 5 A regulated brick. If you are running a Hex from a shared DC supply (two miners off one brick), from a cheap wall-wart, or from a brick you have had on the shelf for five years, this is a likely cause of intermittent chip drops. Use a name-brand Mean Well or CUI brick, or a D-Central Hex-validated PSU bundle. Plug in, power-cycle, re-check Chip count via serial or dashboard. 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 Hex chain-init transient.

Re-flash the correct multichip firmware image via Web Flasher. Open bitaxeorg.github.io/bitaxe-web-flasher/ in Chrome or Edge. CRITICAL: select the EXACT multichip image for Hex (NOT the single-chip AxeOS for Ultra/Supra/Gamma) AND match your board revision (v303 vs v304 differ). If uncertain of your Hex revision, read the silkscreen under good light. A wrong image can report Chip count: 1 or enumerate inconsistently and will be mistaken for hardware failure. Flash, wait for completion, full power-cycle (USB-C AND main PSU unplugged 30 seconds), reconnect, re-verify chain enumeration.

NVS factory-reset after the re-flash. A previous wrong-image flash can leave stale config in NVS that the correct multichip firmware then reads and gets confused by. After Step 5: AxeOS dashboard -> Settings -> Restore Defaults (where the button exists) or via serial console issue the nvs_erase / factory-reset sequence for your multichip firmware version. Then re-flash the correct Hex multichip image once more and power-cycle. This belt-and-braces sequence clears the last common software-state confusion before moving to hardware diagnostics.

DMM-verify the 12 V rail under a 4-5 A load. Open-circuit DMM is not enough; the Hex's chain-init is a real transient draw. Open-circuit: 12.0-12.6 V at the XT30. Under 4-5 A load (halogen bulb rated ~50 W / 12 V, electronic load, or USB-PD load tester): must hold >= 11.5 V sustained. Voltage sag beyond 0.5 V under load, oscillation, or any audible chirp from the brick means replace the PSU. This single measurement cuts a meaningful fraction of 'dead chip' diagnoses into 'bad PSU' cases - cheapest test in the shop.

DMM-verify per-chip Vcore while AxeOS is running at idle. Power the Hex, let AxeOS come up (you will see the five-of-six chain), DMM on DC volts, probe each chip's Vcore test point against GND. All six should read within ~30 mV of each other, in the ~1.20-1.30 V band. If the silent chip reads close to the others: fault is at UART/handshake level (continue to Step 10). If the silent chip reads 0 V: per-chip regulator or local filtering is damaged (Tier 3 repair). If the silent chip reads significantly different from the others but not zero: marginal regulator or partial damage (Tier 3 inspection).

Inspect the heatsink mount and PCB for flex. Power off, unplug everything, remove heatsink carefully. Check: thermal paste / pad distribution across all six chips - is it evenly squeezed, or is one position obviously under- or over-pressured vs the others? Lay the bare board flat on a table - any visible PCB bow or twist? Screws all at similar tightness, or one cranked tighter? Clean old paste with isopropyl 99%, re-apply fresh paste (Arctic MX-6 or Kryonaut) in a thin even layer, remount with finger-tight-plus-quarter-turn on each screw (NOT cranked - Hex PCB is longer and more flexible than a single-chip Bitaxe and over-torque is a real failure driver). Re-power, re-check Chip count.

Cross-reference serial log fault position with physical chip layout. On Hex v303/v304 the six BM1368 chips are labelled U1-U6 (or similar per revision - check silkscreen) and the chain enumerates in a specific physical order. The serial log's 'Chip 4 no response' corresponds to a specific physical chip on the board. Identify that chip now before Tier 3, because every subsequent step is about that one chip. Reference the bitaxeorg ultraHex / Hex schematic repo if you need the chain-order-to-silkscreen-label mapping for your revision.

Scope the UART chain signal between the prior working chip and the silent chip. If chip N+1 is silent and chip N is responding, put a 100 MHz handheld scope on the UART trace between them during a boot cycle. Healthy: clean 3.3 V logic levels with recognizable UART framing, transitions in the tens-of-nanoseconds range. Broken: no signal (trace damaged), ringing/glitching (damaged passives in the path), or signal arrives at chip N+1 but no reply leaves N+1 (chip N+1 itself is the fault). This measurement distinguishes 'chip alive but not responding' from 'chip never received the command' - critical before committing to chip replacement.

Single-chip BM1368 reflow with adjacent-chip shielding. Mask chips adjacent to the named silent position with aluminium foil cut to fit (leave a small gap for airflow) or Kapton tape; protect connectors and through-hole parts from hot air as well. Preheat board bottom-side to ~150 C on a proper preheater (not a hot plate - even heating matters). Apply hot air top-side at ~310-330 C, moving in small circles over the named chip 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. Recovers a large fraction of Hex one-chip-dead failures where the cause is factory cold joint or thermal-cycling-induced crack.

Single-chip BM1368 replacement. If reflow fails, the chip itself is dead and needs replacing. Desolder the named chip with hot air + low-melt solder / Chip Quik, lift cleanly, clean pads with braid + flux, place a replacement BM1368 (D-Central graded inventory or reliable supplier with verified date code - mismatched date codes across the six 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 correct torque, re-flash factory image, power up, verify Chip count: 6.

Diagnose intermittent chain-count drift with thermal-bake-out. If Chip count is inconsistent across reboots (6 cold, 5 after 30 minutes of runtime), suspect a marginal solder joint that opens at operating temperature. Controlled bench test: run the Hex at full workload for 2+ hours, log Chip count every 60 seconds from serial 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 position - OR accept that the fault is deeply intermittent and ship to D-Central for scope-level diagnosis and chip-level bench repair.

Re-flash firmware image after ANY Tier-3 rework. Hot-air work can briefly raise SPI flash temperature and corrupt data silently. After any chip-level rework, re-flash the correct multichip firmware via Web Flasher BEFORE full-load validation. Verify the dashboard reports all six chips before declaring the repair complete. Common failure mode: the hardware repair is good but leftover rework-induced flash corruption makes it look like the repair did not take. Always re-flash, always verify chain enumeration.

Stop DIY on BGA rework if you do not have a real preheater + controlled-temperature hot-air station + rework microscope. BM1368 is a BGA package - iron-only rework is not a path. Without a preheater, the thermal gradient across a long Hex board rips pads off. Without controlled temperature, you will char the FR-4 or blow adjacent passives. Without a microscope, alignment is guesswork and solder bridges are guaranteed. Ship the board. D-Central bench has the full BGA rework stack - Hakko preheaters, Quick / Hakko hot-air stations, stereo microscopes, reflow ovens for full profile cycles, and BM1368 inventory on the shelf.

Stop DIY on Hex chain breaks where the fault is inconsistent. If the serial log shows a different chip position missing on different reboots, or the symptom disappears at room temperature and returns only after 30+ minutes of runtime, you are chasing an intermittent solder fault. Intermittent solder faults need controlled thermal bake-out testing plus scope-level probing at the chain-trace level - not practical at home without dedicated test rigs. D-Central has the rigs. Ship it.

Stop DIY if multiple chips are silent and the cause is not obvious. Chip count: 3 or lower with a clean PSU and correct firmware means either a shared upstream fault (broken trace, dead local regulator feeding multiple domains, PCB flex across multiple chips) or multi-chip damage from a surge / liquid / heat event. Diagnosing multi-chip Hex damage requires methodical bench isolation that takes hours to days at home and minutes on a D-Central bench with proper fixtures. Ship it.

Ship to D-Central with serial logs + PSU + context. Pack the Hex in an anti-static bag, include the original PSU (we test your exact stack), attach a note with: board revision (silkscreen), firmware version, serial console boot log showing the chain enumeration (screenshot or paste), Tier 1/2 steps tried, observed behaviour (consistent or intermittent, cold vs warm), and any context (surge? dropped? new-out-of-box? recent heatsink remount?). Canada-wide shipping, US/international welcomed. Turnaround 5-10 business days. D-Central pioneered the Hex ecosystem - we manufactured the first Bitaxe Hex heatsinks and keep BM1368 inventory for single-chip repairs.

Consider repair economics vs full Hex replacement. A Tier-4 single-BM1368 swap at D-Central runs CAD $95-185 depending on chip sourcing and labour time. Two chips: CAD $175-330. A new Bitaxe Hex board runs CAD $220-320. If diagnosis reveals three or more dead chips (rare but possible after a major surge event), a replacement board is often the better economic path, and we will say so up front - open hardware means an honest conversation. One-chip and two-chip repairs almost always favour fixing; three-plus starts to lean toward replacement unless the other chips are verifiably pristine.

Log the repair history for preventative planning. Whatever the outcome, note in your mining log: date the chip died, which position, serial-log fingerprint, ambient temp at time of failure, runtime hours on the board, last heatsink re-paste date. If you run multiple Hexes (solo-mining stack, heat-recovery setup), the pattern across the fleet tells you whether your failures are random or systemic - and whether it is time to upgrade PSUs, improve airflow, or set a tighter preventative-maintenance cycle. Hex is a 6-chip thermal-cycling endurance test - treat it like one.