Bitaxe – Frequency Change Not Applied / Stuck at Stock

Save the new frequency in AxeOS Settings -> ASIC Frequency, wait for the toast, then power-cycle the Bitaxe by pulling the barrel jack (Supra/Ultra/Gamma) or XT30 (GT/Hex) for 30 seconds. Wait 5 minutes after boot for the hashrate average to settle. Some chip-tune writes only take effect on BM_init at boot — the single most-effective Tier 1 fix when the symptom is 'save took in UI but didn't apply to chip'. Confirm by comparing Average Hashrate over 1h to the linear-scaling expected value (requested_freq / stock_freq * stock_hashrate, ±3%).

Update AxeOS to the latest stable. Settings -> Firmware Update -> upload the chip-correct .bin from the ESP-Miner GitHub releases (BM1366 for Ultra, BM1368 for Supra/Hex, BM1370 for Gamma/GT). Some v2.4.x-era builds shipped with a confirmed regression where the frequency form field wrote to the display cache but not the NVS persistence layer — the dashboard would show the new value forever while the chip stayed at factory default. The fix shipped in v2.5.x. If your version string is older than current stable, this is your fix before anything else.

Factory-reset after the firmware update. AxeOS Settings -> Restore Factory Defaults clears the NVS configuration partition, drops back to factory defaults, and prompts you to re-enter Wi-Fi credentials and tune. Re-enter your target frequency and voltage, reboot, then verify hashrate scales linearly with frequency. The safe sequence is update -> factory-reset -> reapply tune -> reboot -> verify, in that order.

Verify in the dashboard that the saved frequency persists across reboot. Save the new frequency, reboot, then check the ASIC Frequency field after boot. If the field still shows the saved value but hashrate doesn't track it, you have an NVS-vs-application-cache desync — go to Tier 2 NVS erase. If the field has reverted to stock after reboot, NVS isn't persisting the write at all — also Tier 2 NVS erase, with higher confidence in the diagnosis.

Try a different known-stable frequency value. Older firmware builds had narrower chip-tune tables; if your requested value is outside the table's range, AxeOS clamps silently. Try a 'round' value on every table: 500 MHz, 550 MHz, 600 MHz, 650 MHz. If a known-table value scales but a custom value doesn't, you've found the table-clamp bug — update firmware. If no value scales, you're past the table-clamp issue and into NVS or hardware territory.

Capture the serial log at 115200 baud. USB-C cable from your laptop, open `screen /dev/ttyACM0 115200` on Linux/macOS, PuTTY on Windows COM port. Reboot the Bitaxe with the terminal attached and capture the full boot log. Then change the frequency in AxeOS, hit Save, capture the post-save log. The log tells you which failure mode you are in: nvs_set_blob failure = NVS corrupt; PMBus / TPS546 / set_voltage timeout = I2C bus issue; BM_set_freq retries with no ACK = BM chip-side issue; clean log + still stuck = control-board-side.

Erase NVS via esptool.py. Install with `pip install esptool`. With Bitaxe plugged into USB-C and AxeOS not actively writing, run `esptool.py --port /dev/ttyACM0 erase_flash`. This nukes the entire flash (NVS, AxeOS image, www partition, OTA slots) — the Bitaxe will not boot until you reflash. Then use the Web Flasher at bitaxeorg.github.io/bitaxe-web-flasher/ to flash a full image (factory + OTA0 + OTA1 + www) for your chip family. After boot, re-enter Wi-Fi credentials and tune. The highest-yield fix on units that aren't physically damaged.

Verify rail voltage with a multimeter while AxeOS is set to a non-stock voltage. Set AxeOS voltage to 1.25 V (or any non-stock value), save, reboot. Multimeter on DC, probe the BM chip's VCORE pin (Bitaxe schematics on bitaxeorg/bitaxe GitHub identify the exact pad). Expected: rail tracks the requested voltage within ±20 mV. Below the request = PMBus not writing successfully or TPS546 damaged. The dashboard will tell you the rail is at 1.25 V whether or not it actually is, so this is the only honest test.

Visually inspect the TPS546 regulator and surrounding components. Power off, magnifier or microscope. Look for: solder bridges or insufficient wetting at TPS546 pads (especially the small SDA/SCL signal pins), flux residue between adjacent pads, lifted MLCCs near the rail, blackening, or visible thermal damage. Flux residue on the PMBus lines is the most common DIY-introduced cause when the symptom appeared right after a hot-air rework session. Clean with isopropyl 99% on a soft brush, then retest.

If you have a scope, probe SDA and SCL during a save event. Trigger on a falling edge of SCL. Healthy PMBus: clean square waves, 400 kHz clock, ~3.3 V levels. Sick PMBus: ringing, glitches, missed clocks, levels under 2.8 V. Confirms whether the I2C bus is the failure path before you commit to reflowing or replacing the regulator.

Reflow the TPS546 regulator if Tier 2 confirmed PMBus writes failing and the IC has visual solder issues. Hot-air station: preheat surrounding area to ~150 °C, top-side hot air at 300-320 °C for ~20 seconds, let cool naturally without disturbing. Re-test rail voltage tracking via Step 8. If reflow restores PMBus, you've recovered without a parts swap. If reflow doesn't help, the TPS546B24A IC likely needs replacement — small QFN-class package, requires hot-air rework gear and steady hands. Source from Mouser/DigiKey, not unverified Aliexpress channels.

Reflow the BM chip's UART pads if Tier 2 confirmed BM_set_freq retrying with no ACK and visual inspection shows solder issues at the BM chip's serial pins. Hot-air at ~310 °C aimed at the UART pin row only, 15-second pass, watch for paste flow, let cool. Then capture the serial log again — if BM_set_freq now ACKs, the fix took. Also the right move for 'Hex with one chip not responding' — reflow that one chip's UART pins specifically rather than the whole board.

Build ESP-Miner from source with verbose logging enabled. Clone bitaxeorg/ESP-Miner. In main/CMakeLists.txt and sdkconfig.defaults, increase log level to ESP_LOG_VERBOSE for the nvs_flash, tps546, and bm13xx components. Rebuild, flash via USB-C. The serial log now dumps every NVS read/write, every PMBus transaction, and every BM-protocol byte. Resolves edge cases the default INFO-level log doesn't surface — like a PMBus write returning ESP_OK but where the regulator's status register reports the command was rejected.

Test on a known-good controller swap (Hex/GT only). On Hex and GT the BM chips are on a daughterboard separable from the ESP32-S3 controller. Swap the controller to a known-good unit, reboot, retest scaling. Symptom follows controller = ESP32-S3 / NVS / firmware side. Symptom follows hashboard = BM-side. The single fastest bench isolation when both sides could plausibly be at fault. Single-chip variants (Supra, Ultra, Gamma) don't have this option — controller and BM chip are on the same PCB.

Inspect ESP32-S3 module solder joints. Magnifier or microscope. The ESP32-S3 module is reflowed onto the PCB; a marginal joint plus enough thermal cycles makes intermittent comm to the BM chip or TPS546 plausible. Cracked solder at the ESP32 module corners is the visual flag. Reflow the module's perimeter pins with hot-air at 300 °C, 30-second pass, let cool. Retest. Worth doing before declaring the board dead.

Stop DIY when: the serial log shows PMBus failures AND BM_set_freq failures simultaneously, a TPS546 reflow didn't restore rail tracking, you've damaged a pad lifting components, or you're on the second reflow attempt without progress. Book a Bitaxe diagnostic with D-Central. We've been in the Bitaxe ecosystem since unit #1: manufactured the original Mesh Stand, built the first Bitaxe and Bitaxe Hex heatsinks, and we maintain the full ESP32-S3 / BM1366 / BM1368 / BM1370 diagnostic chain in-house. We have the gear (J-LINK debugger, scope, hot-air station, parts inventory) DIY operators usually don't.

D-Central bench process: J-LINK over JTAG to dump and inspect the NVS partition byte-for-byte (catches corruption invisible to firmware), scope PMBus SDA/SCL during commanded voltage changes (catches I2C bus failures the default log doesn't surface), probe BM chip UART with a logic analyzer during BM_set_freq (catches NACK patterns the firmware retry loop hides). Reflow TPS546 or replace from new-old-stock if the regulator is dead. Reflow or replace BM chip pads on Hex/GT where one chip won't respond. Full 24-hour burn-in at requested tune before return shipping.

Ship safely. Anti-static bag, double-boxed, foam ≥5 cm every side. Include a one-page note: variant, AxeOS version, target tune, symptom (dial-doesn't-work), Tier 1-3 steps already tried, contact info. Canada / US / international shipping accepted. Diagnostic turnaround 5-8 business days. We quote before opening — single-chip swap on Hex runs ~$120-180 CAD, two chips dead pushes the math toward a rebuild on a ~$700 CAD Hex; a Gamma at ~$200 CAD with a dead TPS546 is cost-effective to repair.