Whatsminer Error 263 / 264 – PSU Communication Error

Hard power-cycle at the wall, not the UI. Unplug AC for 60 full seconds to drain PSU hold-up capacitors and the auxiliary MCU rails fully, reconnect, and reboot. About 15-20% of Error 263 cases that aren't physical-connector related resolve here, especially after a brown-out or recent firmware update. Latched bus-state faults clear only with full mains removal. If 263 clears, log the event and watch for recurrence.

Stop physically disturbing the miner for 24 hours and observe. If Error 263 correlates with vibration — bumping the rack, fan-off shutdowns, ambient HVAC, a fan rebalancing event — that's a connector or cable fault that needs Tier 2 hands-on, not random reboots that just reseat the connector by accident. Vibration-tracking 263 is almost always physical.

Verify the chassis is fully closed and screwed down. The MicroBT PDF's 'check control board screws' advice addresses the chassis ground return for the comm bus — loose chassis screws break that ground. Tighten all four corner chassis screws and the control-board mounting screws to firm hand-tight; don't strip the threads. Reboot and watch for 263 to return.

Confirm the symptom in WhatsMinerTool. Look at the PSU columns: input voltage, output current, PSU temperature, PSU fan RPM. If they read '--', '0', or are frozen-stale while the miner is hashing, the 263 symptom is confirmed. If they read live updating values and you still see 263 in the log, you have a transient comm error; keep watching, escalate if it returns or pairs with Code 264.

Leave the miner fully powered off for 30 minutes, then retry. A subset of Error 263 events are temperature-latched faults inside the PSU's PMBus MCU local rail. Fully cooling the PSU sometimes clears a marginal sensor or MCU watchdog state. This is a free diagnostic data point before you escalate to tools — a recurring 263 after this won't clear on a thermal cycle.

Power off at the breaker and re-seat the 10-pin PSU-to-control-board signal harness. Pull the chassis cover. Locate the connector — it's the only multi-pin signal cable between PSU and control board, distinct from the heavy DC bus. Unplug both ends. Under bright light, inspect every pin for bent contacts, dark oxidation, green corrosion, or pushed-back pins. Re-seat firmly until the latch clicks. Wiggle-test the cable along its length for crush marks. Clears 30-50% of 263 in the field — do it before buying anything.

Substitute a known-good signal harness from a parts-bin Whatsminer of the same generation. Match generations strictly — M30-family pinout differs from M50/M60 in some build revisions. If 263 clears with the substitute cable, the original had an internal break (often near-connector strain-relief failure invisible from the outside) and needs permanent replacement. Don't reinstall the suspect cable.

Re-seat the PSU DC output connectors as well. While the chassis is open, check the threaded studs (M30 family) or blade connectors (M50/M60) carrying bulk DC to the hashboards. Loose output hardware doesn't directly cause 263, but a partially-seated stud can sag voltage enough to brown-out the PSU's auxiliary rail, which feeds the PMBus MCU, which then drops off the bus mid-conversation. Torque to spec or firm hand-tight.

Measure the PSU auxiliary / standby rail at the 10-pin signal connector. Multimeter on DC, probe the small auxiliary pins (pinout per PSU model; repair-focused forums document these better than MicroBT). Expect 5.0 V or 3.3 V solid; anything sagging, oscillating, or below spec means the PSU's standby converter is dying and the PMBus MCU is starving. PSU is on the hospice list — schedule replacement before 263 escalates to a Code 200 outage.

Check chassis ground continuity. Multimeter on continuity, probe between the PSU case and the control-board chassis ground. Should beep instantly with no measurable resistance. A floating control board or corroded chassis ground path injects noise into the comm bus and produces intermittent 263. Re-tighten chassis screws or run a temporary grounding jumper to confirm before sourcing parts.

Swap to a known-good PSU of the same family. P221 to P221, P221B to P221B, P12 to P12, P13 to P13. Do not cross generations — enable signalling and aux rails differ and you'll chase ghosts. Reboot, watch for 263 over 30 minutes. If 263 clears, the original PSU's PMBus MCU is the fault — bench-repairable on a P221-class unit (Tier 3) or replace and recycle. If 263 persists with the donor PSU, the fault is downstream — control board side.

Swap to a known-good control board of the same model variant. If both cable and PSU have been substituted with no change, the PMBus driver path on the control board is the suspect. Note all connectors before disconnecting the original; install a tested-good donor; reboot. Confirms a transceiver IC, MLCC, or MCU peripheral fault on the original. Bench-repairable for surface-mount-experienced operators; otherwise swap permanently and ship the original to D-Central for component-level diagnosis.

Force a BTMiner firmware recovery via microSD card. Burn the latest stable BTMiner image for your exact model variant using Raspberry Pi Imager or Etcher. Insert the SD into the control-board slot, hold the reset button per your model's recovery sequence (M30S family: 10 seconds through boot; M50/M60 differs — check the firmware changelog), let the recovery complete, pull the SD, reboot. Factory firmware isolates a config corruption from a real hardware fault.

Roll firmware to the last-known-good version. If 263 started after a recent BTMiner update, flash one version back via SD recovery. Some BTMiner builds have shipped with PMBus retry logic that's overly strict and raises 263 on transient noise that prior versions tolerated. MicroBT pulls regressions from the download portal once identified, but miners that updated during the window stay broken until you recover to a stable build.

Open the PSU (out of circuit, fully discharged 10+ minutes) and inspect the PMBus MCU local rail. Locate the small MCU on the PSU control-board side — typically a TSSOP or QFN package near the comm header. Inspect the local rail electrolytic and the MCU's own bypass MLCCs for bulging, residue, cracks, or visible damage. A dried local-rail cap is the most common cause of a dead PMBus MCU on aged Whatsminer PSUs. Replacement caps are a few dollars; rework is surface-mount but accessible to anyone with hot-air experience.

Reflow or replace the PSU's PMBus MCU. If the local rail is healthy but the MCU is unresponsive even with a fresh aux supply, reflow the MCU package (preheat bottom side to 150 C, top-side hot-air at 300-320 C for ~25 seconds). If reflow doesn't restore comm, replace the MCU with a salvaged unit from a donor PSU of the same model. This is unambiguously chip-level work; confirm your skills on a Bitaxe practice board before committing.

Stop DIY and book a D-Central Whatsminer repair slot when any of the following is true: Tier 2 PSU and cable swap both fail and you cannot swap the control board, PSU primary-side shows damage (bulged caps, burnt components, electrical smell), the comm bus shows ringing or flatlined signals on a scope but you can't localise, you're not comfortable with surface-mount rework on a PSU control board, or the miner is throwing 263 + 264 with falling hashrate but no obvious physical fault. Bench equipment required: variable-load PSU tester, scope with PMBus decode, donor MCU and transceiver inventory, ESD-safe rework station.

Ship safely. Power down, drain, remove all hashboards and bag each individually in ESD-safe anti-static. Box the PSU separately in its own padded container — a dropped PSU is often how the next 263 is born. Include a written note with: BTMiner firmware version, the 263 first-seen timestamp, every isolation step you've already tried (cable swap, PSU swap, control board swap), and any pattern (vibration, thermal, time-of-day, post-update). Saves bench hours and shaves dollars off your repair invoice.