Whatsminer M60S – Chip Bin Mismatch

Cold-boot at the PDU for five minutes, then power back up. Clears wedged `btminer` state from an interrupted firmware upgrade and catches the small subset of bin-mismatch events that are transient EEPROM read glitches on a single boot. If the error returns identically on the next two boots, it is persistent and the rest of this tier applies. Do not loop this step more than twice before moving on — repeated reboots on a broken-firmware state waste time.

Pull the full log bundle via MinerTool → ExportLog. Record which slot the error is bound to (`SM0`/`SM1`/`SM2`), the exact MicroBT decimal being thrown (`430`/`431`/`432`, `520`/`521`/`522`, or `510`/`511`/`512`), the firmware build string from the UI, the chassis sub-model label, and the serial number. Six facts. They drive every decision below. Operators who skip this step flash the wrong file or unbolt the wrong board within the next two hours — seen it on the bench repeatedly.

Verify sub-model + firmware match. The chassis label reads `M60S`, `M60S+`, or `M60S++`. The firmware build in the UI should be the current release signed for that exact sub-model. Cross-check against `support.whatsminer.com`. If they do not match, you have a firmware problem, not a hardware problem — flash the correct image via WhatsminerTool V9.0.1, reboot, retest. Do NOT proceed to any hardware work until sub-model firmware is confirmed correct.

Power off at the PDU and drain five minutes. Open the chassis. The M60S top cover is held by Torx `T20` screws — count them, keep them in a tray, don't lose one under the rack. Clip an anti-static wrist strap to the chassis ground before you touch a hashboard. EEPROMs are static-sensitive and you are not wearing rubber-soled diagnostic shoes.

Label the three hashboard slots `0`/`1`/`2` with tape. Move the suspect board to a known-good slot. Reassemble, reboot, observe 10 minutes. If the error follows the board = bad board (continue to Tier 3). If the error stays with the slot = control-board signal path problem (skip to Step 11). This is the single cheapest diagnostic step on this miner and eliminates half the possible causes in 15 minutes of work.

Compare EEPROM/QC stickers across all three boards. Pull them all. Lay them on the bench. Inspect under good light. Same factory font? Same date range? Same serial-format family? Same bin-code stamp pattern? Re-applied stickers leave residue; rework leaves solder flux on the chips. If one board doesn't match the other two visually, you've almost certainly found a mismatched-bin or reworked board. Tier 3 confirms — but this visual inspection often answers it in under a minute.

Re-seat the hashboard ribbon and power connectors on the control board. Oxidation on the pins is common after 18+ months of humid operation — intermittent EEPROM reads that masquerade as bin errors. Unplug, inspect for bent pins or blackening, light pass of DeoxIT D5 if you have it, firm reseat. Listen for the click. Power on, observe 15 minutes. A surprising number of 'bin mismatch' tickets close here without a single board swap.

Verify the `3.3 V` and `12 V` rails at the suspect slot's connector under load. Multimeter on DC, probes at the connector while the miner attempts to start that board. `3.3 V` rail should sit within ±5%; `12 V` rail should sit within ±3% under load. If either sags outside spec, the PSU or the control-board power path is the real issue — the bin error is a downstream symptom. Do not replace the hashboard if the rails are bad.

Roll firmware one revision back to the previous known-good build for your sub-model. Download from `support.whatsminer.com`, verify `SHA-256`, flash via WhatsminerTool V9.0.1 recovery-mode with the miner cold-booted. Single miner, no batch, do not interrupt. Observe 20 minutes. If the error clears, you hit a firmware bin-table regression — log the bad build, avoid it on this miner, stop here. If it persists, continue to EEPROM work. Note M60S rollback-fuse risk — see the Firmware Rollback Failed page before flashing.

Read the hashboard EEPROM out-of-chassis. With the suspect board on a bench stand or test fixture, dump the EEPROM via `whatsminertool` service-mode if supported, or externally with a Bus Pirate / CH341A clipped to the board's `I²C` test points. Compare the declared bin field against the two healthy boards and against the bin listed in the `miner.log` error line. A mismatch between declared and expected = EEPROM problem. An unreadable / `0xFF`-returning EEPROM = corrupt memory.

Decide: reflash EEPROM vs replace the board. If the EEPROM is readable but declares a non-whitelisted bin, AND the chips on the board are genuinely from the declared bin (verify by comparing chip date codes and package markings against the other two boards), reflashing the EEPROM with the correct bin value can recover the board. Requires the MicroBT-internal EEPROM template for your board revision — not publicly distributed. If the chips themselves are mismatched (out-of-bin rework), reflashing produces a miner that hashes at reduced rate or fails `upfreq_test` downstream. Replace the board instead.

Cross-check chip date codes on the board under magnification. Every ASIC on a factory-original hashboard shares the same lot marking, same date code range, and same package revision. If three chips say `2324` and one says `2341`, that chip was replaced at some point — and if the replacement is out-of-bin, you're chasing the out-of-bin-rework pattern and no EEPROM fix will save this board. Mark it for harvest or replacement, move on. USB microscope or good loupe required; this is not a naked-eye audit.

Source a replacement hashboard from a trusted channel. D-Central stocks graded M6x-series hashboards when inventory permits; MicroBT authorised distributors stock new boards at MSRP. Grey-market boards are the primary source of `WM_BIN_ERR` events in the first place — do not solve a bin problem with another bin problem. Confirm the replacement board's declared bin is whitelisted for your exact sub-model (M60S vs M60S+ vs M60S++) BEFORE installing. Get the bin code in writing from the seller.

Know when to stop DIY. Two different boards throw bin-mismatch after firmware is verified; EEPROM reads as corrupt / unreadable on clean bench setup; board shows visible rework (mismatched chip date codes, solder flux on chips, lifted pads near a chip); a prior repair shop worked on the board and the error started immediately after. Bench-fixture territory — MicroBT-internal EEPROM templates, chip-level grading equipment, programmable test loads. Book a D-Central ASIC Repair slot. Continuing DIY in this zone actively makes things worse.

D-Central bench process. Full log capture from the submitted unit, EEPROM dump and comparison against our graded-inventory reference templates, chip date-code audit under magnification, decision between EEPROM reflash (where legitimate) and chip-level repair or board replacement. For out-of-bin reworks requiring chip-grading equipment we source a matched-bin replacement from M6x graded inventory or coordinate factory replacement via our MicroBT distributor channel. Post-repair 24-hour burn-in at nameplate before the miner ships back.

Ship safely. Anti-static bag minimum; double-box with ≥5 cm foam on all sides. If shipping the whole chassis, remove the PSU and pack separately to reduce impact load on control-board standoffs — impact-damaged standoffs turn a one-board repair into a control-board repair. Include a note listing sub-model, serial, firmware build, the exact MinerTool error decimal, which slot is affected, what you flashed, and what you already tried. That note saves 30-45 minutes of diagnostic time — saves you roughly `CAD $50 – $75` on the invoice.