Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

510 Warning

Whatsminer Error 510-512 – Hashboard Type Mismatch

Code 510 (and siblings 511/512) — miner type error. The control board read the hashboard EEPROM, found a `miner_type` string that does not match the chassis model, and refused to enable the chain. Officially: 'use the correct hashboard.' In practice: a wrong-model board (cross-generation, cross-hashrate-variant, or refurb with wiped EEPROM) was installed in the chassis. The board itself is usually healthy — it's the firmware string-compare that gates the slot.

Warning — Should be addressed soon

Affected Models: Whatsminer M30S, M30S+, M30S++, M31S, M32, M50, M50S, M50S+, M50S++, M60, M60S (same EEPROM `miner_type` check across MicroBT M-series; hydro variants M53/M56/M63/M66 may overlap with Code 810 wrong-firmware-water-vs-air)

Symptoms

  • MinerTool dashboard shows `Error Code 510` (or `511` / `512`) on the slot column; the affected board reports 0 GH/s on that chain even though it is physically present, powered, and temp sensors read normal
  • `system.log` / `miner.log` contains `miner type error`, `hashboard type mismatch`, `SM0 type check fail`, or `eeprom miner_type != chassis` at boot — exact wording varies by firmware build
  • Effective hashrate drops by exactly one third (single mismatched board) or two thirds (two mismatched boards in a 3-slot chassis); other chains hash at nameplate
  • Chassis label on the back of the unit reads one model (e.g. M50) but the rejected hashboard's silkscreen, service sticker, or EEPROM `miner_type` string declares a different model (e.g. M30S+)
  • WhatsminerTool API `get_error_code` returns `510` / `511` / `512` in the error array; `get_miner_info` reports the chassis model; the affected slot's hashboard info reports a different `miner_type`
  • Problem arrived after: a hashboard purchase from eBay / Discord / a parts broker, a bench swap during repair, a hashboard return from a third-party shop, or a 'free spare' pulled from a different model donor unit
  • All three chassis slots show `510-512` simultaneously after a firmware flash → firmware is built for the wrong chassis revision and is reading every board's EEPROM as 'wrong' (firmware mismatch, not hashboard mismatch)
  • The board powers up normally — voltage rails come up, chips draw idle current, temp sensors report — and only the chain enable is being blocked by the firmware's type check
  • Boot LED pattern: solid green during the 60-second scan, then a slow alternating green-red on the affected slot — consistent with MicroBT's 'board present, board rejected' state
  • Re-seating the ribbon, swapping slots, and full power cycles all leave the code unchanged — because the failure is purely a firmware string-compare, not a hardware fault
  • On hydro / immersion variants (M53 / M56 / M63 / M66), `Code 510` may appear alongside `Code 810` (wrong-firmware-water-vs-air) when EEPROM declares an air-cooled variant in a hydro chassis or vice versa

Step-by-Step Fix

1

Pull the chassis sticker and write down the exact model and hashrate variant — not 'M50' but the full string, e.g. `M50 88T-V20`. This is your chassis-side `miner_type`. Every troubleshooting decision below depends on this string. Photograph the sticker for your records and any future warranty / resale conversation. The full string includes the hashrate variant and hardware revision tag, both of which matter for sourcing a matched replacement board.

2

In WhatsminerTool V9.0.1, open the affected miner and capture every available data point on the rejected slot: status page, error-code column, hashboard info (if firmware exposes it), and a fresh log export. Save it all to a folder named for the miner serial number. Forty-five seconds of evidence collection saves an hour of remember-what-you-saw later, and it is the exact evidence package needed if you end up filing a return on a mis-labelled second-hand board.

3

Confirm via the V2.0.4 API. From a workstation on the same LAN, send `get_error_code` and `get_miner_info` to the miner's IP on TCP 4028. The returned JSON should show `510` (or `511`/`512`) in the error array and the chassis's declared `miner_type` in the info block. Cross-check against MinerTool. If they disagree, MinerTool is showing cached data — restart MinerTool, re-poll, re-confirm before drawing any conclusion.

4

Check if you bought this board second-hand. If yes, dig up the listing or the Discord/Telegram message. What model did the seller claim? What model does the chassis actually need? If those two strings differ, the seller mis-labelled — open a return request before you do any more bench work. The error-code log line + the chassis sticker + the seller's listing screenshot is usually enough evidence to prevail on most marketplace return policies.

5

Identify the rejected board's true model from the silkscreen / service sticker before opening the chassis fully. Most M-series hashboards print the model and hardware revision directly on the PCB in the corner near the control connector. A flashlight through the front grille is sometimes enough on M30S-class chassis. If you can read it without a screwdriver, you've already saved the open-chassis work for the diagnostic.

6

Power off at the PDU, open the chassis, and pull the rejected board. Phillips #2 on M30S-class; Torx T10 on M50S and later. Disconnect the UART/data ribbon and the PSU-to-board power cable. Slide the board out. Rest it on an anti-static mat. Inspect the PCB silkscreen, the service sticker, and the EEPROM area for any model designation. Photograph everything. The board's true `miner_type` is now in your hand — compare to the chassis sticker.

7

Confirm electrical compatibility before any further consideration of board re-use. If the rejected board is M30S-class and the chassis is M50-class, the voltage domain rails, PSU calibration, and chip-count expectations are different — even if the connectors fit, running the M30S board at M50 rails is exactly what the EEPROM check is preventing. Do NOT disable the check, do NOT rewrite the EEPROM. Different generation = different board, full stop.

8

Look up the correct hashboard for your chassis. D-Central stocks salvaged-grade MicroBT hashboards for most M-series — confirm against your specific model. Cross-reference manufacturer hashrate variant (M50 88T vs M50 100T vs M50S 126T) — these can take different boards even within the same nominal family. The full chassis string from Step 1 is what you match against.

9

Re-seat the chassis-side cabling on the empty slot before installing the replacement. While the slot is empty is the only easy time to clean the ribbon connector, isopropyl-99-wipe the contacts, and verify the locking tab clicks home. Cheap insurance against a future ribbon contamination problem that could drop the same chain back into a different error code.

10

Run with the dead slot empty if you cannot source a replacement immediately. A 3-slot Whatsminer hashes happily on 2-of-3 boards at exactly two-thirds nameplate. Tape off the empty slot's ribbon connectors with kapton, close the chassis, run. Monitor intake temperatures — with one chain down the PSU is loafing and the chassis runs cooler than usual, so thermals are rarely a concern in this state.

11

Pull the rejected hashboard to a bench test stand. Bench PSU at the board's spec rails (verify against your model — M30S-class is roughly 12 V main + ~13-15 V domain depending on hardware revision; M50-class differs). Power up at idle. The chips should enumerate over UART even without the chassis control board — a USB-to-TTL adapter on the chain data line will let you read chip count and confirm the silicon family. If the silicon family does not match what the chassis expects, the board cannot safely run in this chassis under any circumstance.

12

Read the hashboard EEPROM with a CH341A or similar I²C programmer. Locate the EEPROM (24-series SOIC-8, near the control connector — refer to your specific hardware revision's service photos). Hot-clip an I²C programmer to the device, dump the contents to a binary file, open in a hex editor. The `miner_type` string is ASCII, typically near the start of the calibration block. The chip-count, voltage trim values, and frequency targets follow.

13

Understand what NOT to rewrite. The EEPROM holds (a) the `miner_type` string, (b) per-chip voltage trim, (c) frequency targets, (d) hardware revision metadata, (e) chassis-pairing constraints. The only field whose change might safely run a board in a same-generation chassis is the `miner_type` string itself. Rewriting voltage trim, frequency targets, or chip count is how you cook the silicon — those values are calibrated per-board at the factory and are not interchangeable across boards even within the same model.

14

Same-generation EEPROM `miner_type` rewrite (if and only if all electrical specs match). Same silicon, same rails, same chip count, same hardware revision — only the `miner_type` string differs. With the EEPROM dump open in a hex editor, identify the `miner_type` ASCII bytes, edit them to match the target chassis's expected string, recalculate any trailing checksum if present, write back via the I²C programmer, re-install. No guarantee — recent firmware revisions have added cross-checks against chassis EEPROM that defeat string-only rewrites, and a partial write that misses a checksum byte bricks the calibration table. Practice on a scrap board first.

15

Stop here if any of: cross-generation mismatch (M30S board in M50 chassis or similar), corrupted/partial EEPROM dump, or no verified factory calibration table for the target chassis. The fields, byte offsets, and checksum algorithms vary per hardware revision and per firmware era — a recipe that works on a 2021 M30S board can brick a 2023 M30S++ board because MicroBT silently changed the format. The right path is a board with verified factory calibration for your chassis: matched-model new, or salvaged-grade from a vendor that bench-verifies before shipping.

16

Stop DIY and book a D-Central slot when: you bought a second-hand board you cannot return and need it identified and bench-tested before deciding keep/sell/scrap; the EEPROM dump is corrupted or partially erased; you are considering a same-generation `miner_type` rewrite and want it done by a bench with verified calibration tables; or you simply need a properly-matched salvaged-grade replacement for your chassis. Link: https://d-central.tech/services/asic-repair/ — Whatsminer hashboard EEPROM and parts work, Canada-wide and international.

17

What D-Central does at the bench: EEPROM read on a verified I²C programmer; cross-check against our internal hashboard model database; bench-test on a programmable rails fixture matching the board's declared `miner_type`; and either return as-tested for resale at the right model, or — for same-generation rewrites with verified-good calibration tables only — perform the rewrite and burn-in for 24 hours at the new target's nameplate before returning. We do not rewrite across silicon generations because the rails and chip protections aren't compatible.

18

Sourcing a matched-model replacement board. D-Central stocks salvaged-grade MicroBT hashboards across the M-series. Tell us your chassis model and hashrate variant (the full string from Step 1); we'll match against current inventory or quote a sourcing window. Salvaged-grade boards are bench-verified at our shop before shipping, so EEPROM, calibration, and silicon health are all confirmed before the board reaches you. Canada-wide; US/international welcomed.

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.