Avalon 1446 – Controller SD Card Corruption

Power off the entire miner at the PDU for a full 5 minutes. Not the chassis switch — the PDU. The SD card 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 filesystem damage as the kernel tries to journal recovery onto already-corrupted blocks. 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 SD corruption on Beaglebone-class controllers because the SD card has no internal capacitor backup to ride through them. If your line is unstable, fix the electrical before any further recovery attempt — re-imaging an SD card on an unstable line is how recovery attempts brick the unit a second time within the week.

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 these for sourcing the right recovery image), photograph the SD slot area, and reassemble loosely.

Power off, eject the SD card from the controller carrier, and inspect physically. Look for visible oxidation on the contacts (greenish tinge, dullness), brand markings, scorching adjacent to the slot. Photograph top and bottom. Clean the contacts with `99%` IPA on a foam swab if you see oxidation, dry fully, reseat. Reseating with cleaned contacts fixes a non-trivial percentage of "filesystem corruption" tickets that are actually contact-oxidation tickets — try this before assuming silicon damage. Record the SD brand and class — Canaan stock cards are typically consumer MLC class-10, not industrial.

Insert the SD card into a USB SD reader on a Linux laptop (or a Windows / macOS machine running a Linux VM with USB passthrough — native Windows cannot `fsck.ext4`). Do not auto-mount. Run `dmesg | tail` to identify the device node, then `lsblk -f /dev/sdb` to identify the rootfs partition (typically the second `ext4` partition). Run `fsck.ext4 -fy /dev/sdbN` against the rootfs. The `-f` forces a full check; `-y` auto-answers yes to repair prompts. Capture the output to a file — useful for the bench shipment dossier if recovery escalates. If `fsck` completes with repairs, reseat in the miner and retry; if `fsck` errors out under read or reports unrecoverable damage, the card is dead — proceed to Tier 2.

Source the official Canaan A1446 recovery image. Navigate to `avalonminer.org/firmware-document/` and locate the A1446 firmware archive matching your hardware revision (read from the SoM sticker). Cross-reference against the BitcoinTalk Avalon A14 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.

Acquire an industrial-grade pSLC SD card as the replacement. Do not put another consumer Class-10 card back into the chassis. Recommended brands: SanDisk Industrial, Innodisk iSLC, ATP Industrial, Swissbit S-300u, or equivalent. Spec: `8-16 GB` capacity, `pSLC` mode (sometimes labelled `iSLC`), operating temp `-40–85 °C`. A `CAD $30-60` card from a real distributor (Mouser, Digi-Key, Newark) outlasts the consumer alternative by a factor of 5-10 in this duty cycle. This is the single most important call you will make in this recovery.

Burn the recovery image to the new industrial-grade SD card. On Linux: `dd if=avalon-1446-recovery-<rev>.img of=/dev/sdX bs=4M conv=fsync status=progress`, then `sync`. On Windows: Rufus in DD mode, or balenaEtcher (cross-platform with built-in verify pass — recommended). Critical: verify the write succeeded with a read-back diff or a published checksum. A bad SD card write fails recovery silently and you will spend hours diagnosing the wrong layer. Counterfeit cards are a documented recovery failure mode — buy from a real distributor, not Amazon-marketplace third-party listings, not eBay.

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 A1446 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 the SD failed.

Insert the freshly-imaged industrial-grade SD card into the controller carrier. Reassemble the chassis loosely. Apply PDU power. Watch the serial console for: U-Boot finding `mmcblk0`, kernel boot, ext4 mount succeeding (no `EXT4-fs error`), init starting, login prompt. The recovery system on most A1446 builds boots straight into the production firmware — no separate "recovery mode" the way some platforms do; the SD card *is* the firmware on this hardware family. Total time from power-on to LAN-visible: `60-120 s`.

Once the miner is back on LAN, log in via SSH (default credentials documented inside the image archive's release notes — Canaan rotates these per release; do not assume `root/root` or carry over from older A12-class images). Restore your pool configuration, custom IP, MAC ACLs, and any tuning parameters you had pre-corruption. If you maintained a config-export backup before the corruption, push it back now; if not, reconfigure from your fleet runbook.

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. Document the recovered state for your fleet inventory: SD brand, SD part number, SD purchase date, recovery image revision, controller serial, post-recovery API snapshot.

If the official Canaan recovery image is missing for your hardware revision (rare but documented on early/late edge batches), build a minimal recovery from a known-good A1446 controller's SD dump. Procedure: pull the SD contents from a working A1446 controller of the same SoM revision via `dd if=/dev/sdb of=working-sd-dump.img bs=4M conv=fsync` on a Linux laptop. That dump becomes a custom recovery image — burn it to a fresh industrial-grade SD card via the same `dd` flow, insert into the bricked controller, boot. This is a known-good clone, not an official recovery, and it inherits the donor unit's MAC / serial-number provisioning data — but it gets the controller back online when no Canaan-published image fits. Reset the MAC and serial after first boot.

If the controller boots from SD partway, panics, and reboots repeatedly even with a confirmed-good image on a confirmed-good industrial card, suspect SoM eMMC corruption (the boot SPL or kernel image may be on eMMC even though the rootfs is on SD on some hybrid batches). Pivot the recovery: follow [Avalon 1346 — Control Board Firmware Corruption](https://d-central.tech/asic-troubleshooting/avalon-1346-control-board-firmware-corruption/) for the eMMC-resident recovery flow, which uses the SD card as a bootable recovery system rather than as the primary firmware host. Same hardware family, different boot layout, same end goal.

If SD-first boot fails repeatedly despite confirmed-good image, confirmed-good industrial card, and confirmed override sequence, suspect carrier-side fault: the SD slot itself (oxidation on the contacts is common in humid coastal environments), the level-shifters between the SoM and the SD interface, 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.

Replace the SD slot directly. The SD slot on the A1446 carrier is a through-hole or surface-mount push-push slot (varies by batch). With a hot-air station, fine soldering skill, and a replacement slot from Mouser or Digi-Key (Hirose DM3 or Amphenol 114-00841 family — confirm against your specific carrier's footprint), you can replace the slot and recover the controller. This is a `1-2 hour` bench job for an experienced tech, a `4-6 hour` bench job with high failure risk for a learning tech. If you have not done a fine-pitch hot-air rework 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).

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, capture the `fsck` output from the failing SD, photograph the SD card top and bottom with the brand visible, 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 onto a fresh industrial-grade card but the controller bricks again within `24-72` hours (eMMC corruption underneath, SoM swap territory); SD-first boot never succeeds despite confirmed-good image on a confirmed-good industrial card (carrier fault); the SD slot is mechanically loose, intermittent, or visually damaged; the SoM is soldered to the carrier and the corruption is suspected on internal eMMC rather than the SD; the controller has visible physical damage; 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 A1446 controller: serial console log capture and root-cause confirmation, SD slot replacement or SoM swap from graded inventory, fresh industrial-grade SD card with current Canaan firmware 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.