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

Code 300 (SM0 temp sensor detect fail; I2C NAK) Critical

Whatsminer Error 300 – Hashboard SM0 Temperature Sensor Failure

BTMiner fires `code=300` when the control-board I2C master cannot get an ACK back from the slot-0 (SM0) hashboard temperature sensor. The sensor is dead, not powered, unreachable across the board-adapter cable, or the I2C bus itself is wedged. Part of a family: `code=301`=SM1, `code=302`=SM2, `code=329`=control-board sensor. Blocks upfreq; escalates to `code=350` thermal-protect if left unresolved.

Critical β€” Immediate action required

Affected Models: Whatsminer M20S, M30S, M30S+, M30S++, M31S, M31S+, M32, M50, M50S, M50S+, M60 β€” every Whatsminer chassis that routes slot-0 hashboard temp sensor signals across a board-adapter cable to a control-board I2C master (air-cooled generations; hydro/immersion variants share the topology with different connector hardware)

Symptoms

  • WhatsminerTool status page reads `code=300` or log line `Alarm: code=300, msg="SM0 temp sensor detect fail"`
  • Dashboard shows slot-0 hashboard temperature as `--`, `0 Β°C`, `255 Β°C`, or `-40 Β°C` β€” stuck-value artifact, not a real reading
  • Slot-0 per-chip temps (`Tavg` in `HS_RCD0`) look flat β€” every chip reads the same value or the whole row is blank
  • Miner refuses to upfreq; `upfreq_test.log` aborts with a temperature-related reason code on slot 0
  • `code=300` pairs with `code=350` (SM0 temperature protecting) intermittently, no correlated ambient change
  • `code=300` co-fires with `code=530`/`531`/`540`-family chip-ID / EEPROM errors on slot 0 β€” points at shared 3.3 V rail failure
  • Hashrate drops ~33% β€” firmware pulled slot 0 from hashing rotation
  • Control-board LED slow red blink while the other two hashboards continue hashing
  • Error started after chassis move, re-rack, or shipment β€” mechanical shock to board-adapter ribbon
  • Error started after firmware flash β€” sensor init regression on some BTMiner builds, or cross-revision flash (M30V1 vs V2 vs V3)
  • Recent condensation event β€” cold-shipped miner plugged in warm, shoulder-season humidity crossing dew point on adapter-plate silicon
  • `code=300` fires on boot, clears after a cold power-cycle, returns within minutes or hours β€” marginal connector / stuck-bus signature

Step-by-Step Fix

1

Hard power-cycle at the PDU for 60 seconds, not a soft restart. The I2C bus pull-up network needs fully discharged caps to recover from a wedged state, and only a real cold boot does that. Power back up, wait 5 minutes for BTMiner to complete self-test, re-check the status page. Roughly 15% of `code=300` cases β€” particularly those that appeared after a firmware upgrade, brownout, power blip, or stratum reconnect storm β€” resolve right here. If your PDU has a breaker, flip the breaker instead of the miner rocker switch for a cleaner discharge.

2

If the miner was recently shipped cold, re-deployed from a climate-different space, or pulled out of a garage into a warm shop, let it sit 60 minutes unpowered in its new location before booting. Condensation on adapter-plate silicon wedges the I2C bus silently β€” the #1 avoidable root cause in Canadian shoulder-seasons (March, October, November) when dew-point math goes against you. Plugging in a cold miner is the most overlooked self-inflicted `code=300`.

3

Read the exact codes firing in WhatsminerTool. Only `code=300`, or `300` + `301` + `302` together, or `code=350` pairing in and out, or `code=530`/`540` chip-ID errors on slot 0 at the same time? Different patterns route to different fixes. Screenshot the status page and the alarm log before you touch anything, so you have the record if the issue returns. Export logs via Remote Ctrl β†’ ExportLog for deeper grep (`code=300`, `i2c`, `sensor`).

4

Verify firmware version (status page β†’ `20xxxxxx.xx` string) and hardware revision (M30V1 / M30V2 / M30V3, or analogous for M50/M60). If you recently flashed firmware β€” especially a cross-revision flash or a build from the known-buggy `20200801`-era M30V1 family β€” plan a roll in Tier 2. MicroBT does not publish meaningful changelogs, so treat BitcoinTalk, r/mining, and the Whatsminer Discord as your real release-note feed.

5

Check ambient temperature with an external thermometer at the intake grille (not the middle of the room). If real ambient is 22 Β°C and the miner reports 55 Β°C on slot 0, the sensor is lying and `code=300` is the real fault. If real ambient is 35 Β°C+ and the miner agrees, the sensor is honest and you're in airflow / thermal territory β€” different page. The external thermometer is your ground-truth check against the dashboard.

6

Power down at the PDU. Open the chassis. Re-seat the slot-0 board-adapter cable at BOTH ends β€” the hashboard end and the adapter-plate end. This is the single most-effective fix for `code=300` in the entire Whatsminer family. MicroBT's official fix leads with it, BiXBiT's published database leads with it, and D-Central's bench clocks it at 30-40% of tickets resolved by a pure cable re-seat. Press firmly, listen for the click. Wipe pins with 99% IPA on a lint-free swab if you see dust, blackening, or green corrosion. Re-seat slot-1 and slot-2 ribbons as well for cheap insurance.

7

Swap the slot-0 hashboard into slot 1, power up, observe logs for 10 minutes. Label the slots with tape first. If `code=300` migrates to `code=301` in slot 1, the sensor or its local bus passives on that hashboard are the fault β€” move to Tier 3 reflow / replace. If `code=300` stays in slot 0 with a different hashboard installed, the problem is the adapter plate, the slot-0 ribbon, or the control-board I2C channel β€” Tier 3, different branch. This is the single most diagnostic move in the entire `code=300` playbook and costs zero tools.

8

Measure the 3.3 V rail at the slot-0 adapter connector under load with a multimeter on DC. With miner powered and idle, expect `3.3 V` nominal (Β±5%, so `3.14-3.46 V` is fine). Zeus Mining's M30/M31/M32 repair guide confirms the 3.3 V rail is shared between the temperature sensor and the hashboard EEPROM β€” which is why `code=300` + chip-ID code on slot 0 is a rail problem, not two separate faults. Sagging rail = regulator on the adapter plate is dying, Tier 3 territory.

9

Flash the latest official MicroBT firmware for your exact hardware revision. Verify the hardware string in WhatsminerTool matches the firmware's supported-hardware list BEFORE clicking Start Upgrade β€” wrong-rev flash bricks the control board. If `code=300` started after a recent flash, roll one official build back. Never flash custom firmware on Whatsminer (Vnish / Asicdip / HiveOS) β€” anti-tamper codes 100001/100002/100003 will fire and layer a second fault on top. DCENT_OS is Antminer-only; it won't run on MicroBT silicon. Whatsminer support is on D-Central's public roadmap but not yet shipping.

10

Clean the slot-0 board-adapter connector with compressed air + IPA. Short bursts of compressed air from 30 cm away (not point-blank β€” the pressure can damage pins). Follow with 99% IPA on a cotton swab if grime, dust, or oxidation is visible. Packed dust is a surprisingly common cause of I2C contact failure on miners that have run 18+ months without a service β€” the contact resistance creeps up slowly and marginal comms start to fail under thermal stress.

11

Inspect the adapter plate itself for cracked traces, scorched components, bridging solder, or visible damage. The adapter plate takes mechanical stress every time a hashboard is installed or removed β€” cracks at the connector solder joints are a real failure mode. If you see visible damage, replace the adapter plate from D-Central's replacement parts catalog before reinstalling hashboards. Don't try to reflow a crack under a connector body β€” replace the plate.

12

Scope SDA and SCL on the slot-0 I2C segment. Clip probes to the adapter-plate test points or the ribbon itself. Healthy bus at idle: ~3.3 V high, clean falling edges during transactions, no chatter when idle. Stuck bus: SDA or SCL held low by a dead slave. A Saleae Logic 8 or a ~$15 sigrok-compatible FX2 clone decodes the I2C traffic and shows you exactly which slave address is NACK-ing. This is the diagnostic step that separates 'swap-and-pray' repair from real I2C-level bench work.

13

Reflow the sensor IC on the slot-0 hashboard. Preheat bottom of the board to ~150 Β°C if you have a preheater, then top-side hot air at 280-310 Β°C for 15-20 s over the SOT-23 sensor package. Cool naturally on a heat-safe surface β€” don't fan it. Re-test with a thermocouple reference against a known-good meter. Reflow restores intermittent joint failures; it won't fix a dead sensor, but it's the cheapest first move before ordering a replacement part.

14

Replace the sensor IC outright if reflow doesn't restore it. TMP75 / TMP112 parts are Mouser and Digi-Key stock items β€” $2-5 CAD single-unit, pennies at volume. Match the exact part number from the hashboard silkscreen or a donor board photo (the M30-series and M50-series do not always use identical parts). Hot-air rework station, fine tweezers, flux, patience. The real repair: pennies in parts, minutes in labour, restores the miner to nameplate.

15

Inspect and repair I2C bus passives on the adapter plate: cracked MLCCs in the pull-up or decoupling network, damaged pull-up resistors, bridging flux from a prior service, cracked ESD diodes. 0402 / 0603 passives β€” soldering iron, magnification (10Γ— loupe minimum, USB microscope better), replace like-for-like. This is what keeps the bus alive after the sensor itself is healthy β€” skip this step and your sensor replacement fails within weeks.

16

Repair or replace the adapter plate if bus-level diagnostics point there β€” cracked traces, failed 3.3 V regulator, or physical damage at connector solder joints. Adapter plates are field-replaceable parts in D-Central's catalog β€” cheaper and faster to swap than to rework if the cracked trace runs under a connector body. Match the part to your exact model and hardware revision; M30-series adapter plates are NOT compatible with M50 or M60.

17

Stop DIY and ship to D-Central when: every SMx sensor NAKs regardless of installed hashboards AND a known-good control-board swap clears it; a reflowed sensor returned the code within 30 days; capacitor bulging, discoloration, or burnt-component smell anywhere in the chassis; the miner refuses to POST or bootloops alongside `code=300`; you've worked Tier 1-3 and the error is intermittent in a way that points at vibration-coupled failure you can't isolate at home. Book a D-Central ASIC Repair slot.

18

Ship to D-Central: anti-static bag the hashboards, adapter plate, and/or control board. Double-box with β‰₯5 cm foam on every side. Include a note listing observed symptoms, exact codes from exported logs, firmware version, and your contact info. Bench process for Whatsminer `code=300`: I2C bus protocol-analyzer capture on each segment, adapter-plate test fixture with validated sensor reference, TMP-class sensor replacement on hashboards (graded parts in stock), 3.3 V rail diagnostic and regulator repair, control-board I2C peripheral repair where failure localizes there, 24-hour nameplate burn-in post-repair. Canada-wide shipping standard; US and international welcomed with return-freight quote.

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.