Avalon 1346 – Control Board Firmware Corruption

Power off the entire miner at the PDU for a full 5 minutes. Not the chassis switch — the PDU. The eMMC controller and DDR RAM need time to fully discharge before retry. Resist the urge to rapid-cycle the power; every additional half-booted state risks deeper partition damage. After 5 minutes, power back on and observe the controller LED pattern for 90 seconds. If the boot completes cleanly (status LED steady, network appears, AUC green), you had a transient — verify the firmware flash was completed with a healthy power source, schedule a UPS purchase, and document the event.

Verify the AC supply to the miner is stable. Plug a kill-a-watt or voltage meter into the same outlet as the miner PDU. Look for `220-240 V AC` sustained, no transient sags below `200 V`, no surges. Brownouts during cold-boot are a documented cause of eMMC corruption on Beaglebone-class controllers. If your line is unstable, fix the electrical before any further recovery attempt — flashing eMMC on an unstable line is how recovery attempts brick the unit a second time.

Open the chassis and visually inspect the controller board. Look for: scorched components, blown surface-mount fuses, swollen capacitors near the SoM, any sign of physical damage. If you see physical damage, stop here and ship to bench — DIY recovery on a physically-damaged controller risks adjacent components. Otherwise, document the SoM and carrier revision stickers (you will need this for sourcing the right recovery image) and reassemble loosely.

Confirm the failure with two distinct external probes: (a) ping the documented controller IP from a laptop on the same LAN — no response after 90 s of power-on confirms network-stack failure; (b) hold an SD card up to the SoM's SD slot to confirm the slot is physically accessible from outside the chassis. If the SD slot is not externally accessible, you will need to remove the SoM from the carrier to insert the recovery card — this is still DIY but raises the difficulty by one tier.

Source the official Canaan A1346 recovery image. Navigate to `avalonminer.org/firmware-document/` and locate the A1346 firmware archive matching your hardware revision (read from the SoM sticker). Cross-reference against the BitcoinTalk Avalon A13 thread for community A/B validation. Download the archive and verify SHA-256 hash if Canaan publishes one. Do not use grey-market unlocked images; signature mismatch on a signed-bootloader batch turns DIY recovery into a bench event.

Burn the recovery image to a Class 10 SD card, 4 GB minimum, 16 GB recommended. On Linux: `dd if=<image>.img of=/dev/sdX bs=4M conv=fsync status=progress` then `sync`. On Windows: `Rufus` in DD mode, or `balenaEtcher`. Critical: verify the write succeeded with a read-back diff or a checksum. A bad SD card write fails recovery silently and you will spend hours diagnosing the wrong layer. Use a known-quality card brand (SanDisk, Samsung, Kingston) — counterfeit cards are a documented recovery failure mode.

Hook a USB-to-TTL serial adapter (FT232, CP2102, CH340) to the controller debug header at `115200 8N1`, no flow control. The header is unsilk-screened on most A1346 carriers but matches the Beaglebone-family pinout: `GND` adjacent to a corner, `RX` next, `TX` next. Cross your `RX` to controller `TX` and vice versa. Open a serial terminal (`minicom`, `screen`, `PuTTY`) and capture output from power-on. This is the single most valuable diagnostic upgrade you can make on an Avalon controller — it shows the U-Boot stage, kernel boot, and any panic message that tells you exactly why eMMC failed.

Configure the controller for SD-first boot. Mechanism varies by hardware revision: (a) early batches use a 2-pin shorting jumper labelled `BOOT_SEL` or unlabelled — consult the recovery image's release notes; (b) mid-batch units use a momentary push-button held during power-on (8-10 seconds); (c) late-batch units accept the AUC reset button held during power-on. With the SD card inserted, hold the appropriate override, apply PDU power, continue holding for 8-10 seconds, release. Watch the controller LED — within 5 seconds of power-on it should change pattern, indicating SD-first boot has been accepted.

If the SD-first boot succeeded, the controller will boot the recovery system within 30-60 seconds. Watch the serial console for: U-Boot finding `mmcblk1` (the SD card) instead of `mmcblk0` (eMMC), kernel boot from SD, and the recovery system's banner. The recovery system typically presents either an interactive menu over serial or boots into a network-accessible state with a static IP (commonly `192.168.1.169`). Log in via SSH (credentials inside the image archive's release notes — Canaan rotates these per release, do not assume `root/root`).

From inside the running recovery system, run the eMMC re-flash script. Filename varies by image: `flash-emmc.sh`, `restore-emmc.sh`, `eMMC-flasher.sh`. Some recovery images run the flash automatically on boot; check the release notes. The script writes `MLO`, U-Boot, kernel, and rootfs to eMMC, calls `sync`, and reports exit status. Expect 4-10 minutes total. Watch for `mmc write failed`, `bad block detected`, or other eMMC-side errors — those indicate silicon-level wear, not recovery-image issues.

Once the flash script completes successfully, run `sync` manually one more time, then `poweroff` from the recovery shell. Power off at the PDU. Remove the SD card. Wait 60 seconds. Power on without the SD card and without the boot override. The controller should boot from refreshed eMMC: clean U-Boot, kernel boot, login prompt, cgminer auto-starts, network appears, AUC LED green. If the boot is healthy, recovery is complete. Restore your pool configuration, custom IP, MAC ACLs, and any tuning parameters you had pre-corruption.

Verify post-recovery health with the CGMiner API. From any machine on the LAN: `echo -n '{"command":"stats"}' | nc <miner-ip> 4028`. Confirm `SYSTEMSTATU = 3` (all three MMs enumerated), `ECHU[0 0 0]` (no hashboard comm faults), `ECMM[0 0 0]` (no module-management faults), `PS[0] = 0` (PSU healthy), `GHSmm` and `GHSavg` within ±8% of nameplate. If any value is off, the controller is now healthy but you have a downstream issue — hashboard, AUC, or PSU — and should pivot to the relevant sibling article.

If the official Canaan recovery image is missing for your hardware revision, build a minimal recovery from a known-good A1346 controller's eMMC dump. Procedure: pull the eMMC contents from a working A1346 controller of the same SoM revision via `dd if=/dev/mmcblk0 of=working-emmc-dump.img bs=4M conv=fsync` over SSH on the working unit. That dump becomes a custom recovery image — burn it to SD via the same `dd` flow, boot the bricked controller from the SD, then `dd` the image back onto the bricked unit's eMMC (with the bricked unit booted from the SD). This is a known-good clone, not an official recovery, and it loses the bricked unit's MAC / serial-number provisioning data — but it gets the controller back online when no Canaan-published image fits.

If SD-first boot fails repeatedly despite confirmed-good image, confirmed-good SD card, and confirmed override sequence, suspect carrier-side fault: the boot-select circuitry, the SD slot itself (oxidation on the contacts is common in humid coastal environments), or the SoM-to-carrier connector. Inspect the SD slot under magnification, clean contacts with 99% IPA, reseat the SoM if it is socketed (early batches only — late-batch SoMs are soldered down). If the SoM is socketed and reseating fixes the boot, you had connector oxidation; document the unit for periodic inspection.

JTAG recovery is the last DIY-adjacent option before bench escalation. The `AM335x` SoC exposes a JTAG header on most Avalon controllers — though Canaan does not silk-screen it. If you have a Lauterbach, Segger J-Link, or a TI XDS adapter and you know the SoM family's boot-script ROM commands, you can JTAG-load U-Boot into RAM, then `mmc write` from JTAG-loaded U-Boot directly to eMMC. This bypasses the broken bootloader entirely. Procedure is non-trivial and outside the scope of a stock recovery; if you have the equipment and the experience, you do not need this paragraph; if you do not, this is bench territory.

Replace the eMMC silicon directly. The eMMC chip on the A1346 SoM is a `BGA-153` package, typically a Samsung or Micron part, `~4-8 GB` capacity. With a hot-air station, BGA reflow skill, and a known-good replacement chip preloaded with a working image (via a chip programmer like the easy-jtag or a generic `BGA-153` socket programmer), you can swap the eMMC and recover the controller. This is a `1-2 hour` bench job for an experienced tech, a `4-6 hour` bench job with a high failure rate for a learning tech. If you have not done a `BGA-153` reflow before, do not learn on a `CAD $300` Avalon controller — practice on a Bitaxe Hex first (D-Central pioneered the Hex heatsink and stocks all Bitaxe variants for exactly this reason), then graduate to controller eMMC swaps.

Document everything before you ship. If Tier 3 has not recovered the unit, take photos of the SoM and carrier (top and bottom), record the serial console output of the failed boot, note every recovery image you tried and the failure mode of each, and include this with the unit when it ships to bench. A clean recovery dossier is the difference between a `CAD $120` triage charge and a `CAD $400` repair quote.

Stop DIY and ship to bench when any of these are true: the recovery flash succeeded but the controller bricks again within 24-72 hours (eMMC silicon wear); SD-first boot never succeeds despite confirmed-good image and override sequence (carrier fault); the SoM is soldered to the carrier and the eMMC silicon needs replacement (BGA reflow on a soldered-down SoM requires bench tooling); the controller has visible physical damage; JTAG recovery has failed or you do not have JTAG equipment; the recovery image you need is not published and you do not have a same-revision donor unit to clone. [Book a D-Central ASIC Repair slot →](https://d-central.tech/services/asic-repair/). D-Central bench process on an A1346 controller: serial console log capture and root-cause confirmation, SoM swap from graded inventory or chip-level eMMC replacement with BGA reflow, JTAG-load and verify of a clean controller image keyed to the unit's hardware revision, full re-provisioning of MAC and serial data, 24-hour soak test on a programmable load with all three hashboards live and API logging to confirm the fix. Canadian turnaround: 5-10 business days.