Avalon Series – BOOTBY Code Reference Guide

Power-cycle the miner at the breaker for 30 seconds. Kill the mains — not a soft reboot. Let MM cold-start cleanly. Clears any wedged driver state left over from firmware upgrades or controller scripts. On a single-event reboot this alone often resolves the symptom; on a cadence it establishes a clean baseline for the diagnostic that follows.

Pull the exact `BOOTBY[0xNN.xxxxxxxx]` line from the background log. Web UI path: `System` → `Miner Log`, search for `BOOTBY`. CLI path: `telnet <miner-ip> 4028` + `{"command":"estats"}` — the reply includes the most recent `BOOTBY` field. Screenshot the full log line. The hex prefix (`0x01`, `0x02`, `0x10`, `0x11`, etc.) is the entire diagnostic; write it down before doing anything else.

Record the cadence over 10-20 reboot events. One `BOOTBY` per 24 hours is noise. Repeating every N hours or minutes is signal. `BOOTBY[0x05]` every 30 seconds is almost always a runaway monitoring script (Hive OS, Foreman, Awesome Miner) — kill the upstream reboot command before you blame the hardware. Cadence plus code pair is the actual diagnostic, not the code alone.

Shop-vac the intake filter. Wipe the grille. Verify nothing is blocking the front 15 cm of the miner — no curtains, no dust berm, no stacked gear. Intake dust is the single most common root cause of `BOOTBY[0x02]` across every Avalon generation. Budget five minutes for this and you'll resolve a meaningful percentage of thermal cadences before reaching for tools.

Verify intake ambient with an IR thermometer at the grille — not the middle of the room, not the hallway. Target ≤ 30 C for A11 / A12 generations; ≤ 32 C for A13+ with tighter thermal envelopes. Above 35 C ambient, `BOOTBY[0x02]` cadences are inevitable regardless of what you do to the hashboards. Fix the room before you open the chassis.

Query `{"command":"version"}` on port 4028 to read the exact MM firmware build string. Note it. Visit `avalonminer.org/firmware-document/` or `shop.canaan.io` to confirm whether your build is the last-known-good for your specific model (A1166 Pro: 20220926 family; A1246: 20230424 family; A13+: most recent stable release). Download the target build and verify SHA256 against the portal's published hash before flashing.

Flash the last-known-good MM firmware through the web UI. Do NOT interrupt the flash — a bricked MM on an A13+ model requires bench-level recovery and will burn a day of repair time. Soak-test for 24 hours after the flash, re-pull `{"command":"estats"}` periodically, and compare `BOOTBY` cadence against the pre-flash baseline. Pin the build and refuse the next update until an authoritative source confirms no regression.

Measure mains voltage under load at the PSU input with a multimeter. Standard Avalon PSUs expect 200-240 V and tolerate down to 195 V briefly. Sag below 195 V sustained during hash bursts produces `BOOTBY[0x01]` / `0x10` clusters on any MM generation. Dedicated 240 V circuit strongly preferred over 120 V for Avalon-class power draw — 120 V circuits sag at load peaks and cascade into reboot loops.

Reseat the AUC3 controller USB cable (A11 / A12 generations) or the internal control-to-hashboard ribbons (A13+ integrated MM designs). Power off at the breaker first. Inspect pins for corrosion or blackening before reconnecting. On USB AUC3 specifically, a dab of dielectric grease on oxidised pins has resolved repeat `BOOTBY[0x04]` / `0x10` loops on multiple three-year-old A1246s in D-Central's repair queue.

Set DNS to `1.1.1.1` + `8.8.8.8` in the network config. Drop Canaan's default `114.114.114.114` Chinese resolver — it hits intermittent latency from North American ISPs and produces `BOOTBY[0x03]` cadences that look like pool faults. Swap your primary stratum pool for 30 minutes to a known-good mirror. If `0x03` disappears after pool swap, the original pool had a stratum-side fault; if it persists, the fault is MM-internal.

Refresh thermal pads on the hashboard reporting the highest baseline `PVT_T`. Arctic TP-3 or equivalent, 1.5 mm pad thickness matched to original. IPA 99% to clean old residue. An 8-12 C drop in `PVT_T` is typical on a three-year-old A11 / A12 and directly resolves thermal-adjacent `BOOTBY[0x02]` / `0x10` clusters. Newer A13+ hashboards use tighter pad specs — match exactly, do not over-compress.

Swap hashboards between slots to isolate the fault source. Label slots 0/1/2 with tape. Move the suspect board to a known-good slot and observe `BOOTBY[0x11]` / `0x12` behaviour. Fault follows the board = bad board, reflow or chip-level repair territory. Fault stays in the slot = AUC3 / ribbon / MM-side control path fault. This 30-minute test saves days of wrong-direction troubleshooting.

Inspect the MM control board and AUC3 controller under a loupe for physical damage — scorched traces, bulging electrolytic capacitors near the hashboard LDOs, corroded USB pins (A11 / A12), cracked MLCCs near the PMIC. Avalons that ran 24/7 through two Canadian winters see aggressive thermal cycling; solder fatigues, electrolytics dry, and `unexplained` 0x10 reboots result. Visible damage = skip straight to Tier 4.

Test with a spare AUC3 controller on A11 / A12 rigs. `shop.canaan.io` stocks replacements; D-Central carries refurbished units for the A10 / A11 / A12 families. An AUC3 handshake glitch reliably produces `0x03` or `0x10` reboots that look exactly like firmware bugs until you prove it's hardware by swapping the controller and watching the cadence clear.

Advanced: flash a stable MM firmware from a different branch if the last-known-good is still rebooting. On A11 Pro rigs, some operators have resolved persistent `BOOTBY[0x10]` by cross-flashing an A1246-family MM build modified for A1166 Pro compatibility (community work documented on bitcointalk topic 5436344). Treat as advanced, back up your current build first, and note Canaan's signed-firmware checks on A13+ hardware make cross-flashing impossible there.

Stop DIY when: firmware refresh + hashboard reseat + PSU test all fail, `PVT_T > 85 C` persists after a full thermal-pad refresh, MM or AUC3 shows visible damage, or the reboot cadence makes the miner economically unoperatable. You're in test-fixture territory. Book a D-Central Avalon repair slot at https://d-central.tech/services/asic-repair/ — 5-10 business day turnaround, Canadian workshop, ships Canada / US / international.

D-Central bench process for persistent `BOOTBY` faults: programmable-load test fixture, Canaan diagnostic binaries, per-board isolation, MM / AUC3 module replacement from stocked inventory (A11 / A12 / A13 families in stock), full MM firmware re-flash end-to-end, and post-repair 24-hour burn-in at nameplate load. We log the repaired miner's `BOOTBY` output for the burn-in window and don't ship until it's clean.

Ship safely: anti-static bags, double-box with ≥5 cm foam on every side, include a note listing every observed `BOOTBY` code, the reboot cadence, your firmware version, and your contact info. Diagnostic data in the box saves our bench team time, which saves you repair dollars. Pack for drop: the courier will drop your box at least once; assume it.