Avalon 1246 – Firmware Flash Failure

Stop. Don't re-flash yet. After a failed firmware update, every additional flash attempt is a chance to brick a partially-recoverable module. Resist the reflex to reach for the update button. Log everything — AUC3 LED state, web UI behaviour, cgminer error strings — before you do anything else. Half the A1246s shipped to our bench for 'failed flash' were bricked by the second or third panic-reflash, not by the original event. Document, then act.

Hard power-cycle for 60 seconds at the PDU. Not a soft reboot, not a controller-only reboot. A full breaker-level power-down, sixty seconds by the clock, then power up. This clears both the cgminer USB session and any latched bus state on the AUC3. Roughly half of 'failed flash' tickets resolve at this step alone — the firmware wrote fine, cgminer just got wedged. Watch the AUC3 LED boot blue → green and tail the log; if hashrate returns, you're done.

Verify your controller's Ethernet is wired, not Wi-Fi. Community reports on support.canaan.io confirm mid-update Wi-Fi drops as a root cause of corrupted flashes. If you originally flashed over Wi-Fi, your next attempt — once you've worked through this playbook — must be wired. Plug an Ethernet cable from the controller to your router or switch. Confirm the controller has a solid IP via DHCP before any re-flash.

Pull the last-known-good firmware build from avalonminer.org/firmware-document/. Download the exact build that was running on the rig before the failed flash. Verify the hardware revision match — A1246 firmware does not run on A1346 hardware. Save to a USB stick as a rollback reference. If you don't know your previous build, err on the side of the oldest portal build your hardware supports; usually the most stable.

Check the AUC3 LED sequence during boot. Blue = initialising or idle; green = working normally; red sustained = comm issue or pool-reject (per the 2018 Canaan PDF's overloaded red state). If you see red after a failed flash, the odds favour IIC-bus corruption — the MM firmware is either gone or rejected, and the bus is trying (and failing) to hand off. Note the colour and timing for Tier 2.

Override default DNS. Stock Avalon firmware ships with DNS set to `114.114.114.114` (a Chinese public server). North American and European networks often can't reach it reliably, which breaks any subsequent over-the-network recovery attempt. From the web UI or SSH, set DNS to `8.8.8.8` or `1.1.1.1`. This doesn't fix the failed flash directly, but removes a common cause of 'the rescue flash also fails'.

Rule out PSU sag as the flash root cause. Multimeter on DC at the PSU-to-control-board connector while the rig is powered and attempting to enumerate. Expect ~12 V sustained; anything below ~11.8 V under minimal flash-phase load suggests a tired PSU. Swap PSU with a known-good unit before any re-flash. An A1246 chewing on a half-dead APW during a firmware write is a common way to 'fail a flash that looked fine.' PSU sag during the bootloader handoff is silent and invisible on the web UI.

Swap the USB-A-to-USB-B cable to a shielded 1 m cable with ferrite bead. Fan-vibration-loosened USB-B jacks on the AUC3 are the single most-diagnosed AUC-flash-corruption cause on D-Central's Canaan bench. Replace the cable before the re-flash, route it away from the fan path, and zip-tie the AUC3-side connector to the chassis so it can't vibrate loose. Use the shortest cable that reaches. Never flash across a 3 m unshielded cable or through a USB hub.

Reset AUC tuning to cgminer defaults. If your cgminer launch config contains `--avalon7-aucspeed` or `--avalon7-aucxdelay`, set them back to `400000` and `19200` respectively (or the documented default for your Avalon generation — `avalon8`/`avalon10` on newer SKUs). Flashing over a speed-tuned bus is one of the fastest ways to produce `CODE_MMCRCFAILED` mid-write. Re-apply tuning only after the flash succeeds.

Attempt the recovery flash — wired, stock-tuned, verified build. From a wired Ethernet controller, known-good shielded cable, default AUC speed, exact firmware build matching your hardware revision, initiate the flash. Do not touch anything while it runs. No SSH, no second web session, no one unplugging anything in the room. Monitor from a second machine if you need progress visibility.

Flash one MM at a time if the UI supports it. Canaan's web UI sometimes flashes all MMs in parallel, doubling or tripling the IIC bus traffic during the critical window and multiplying failure risk. Flash MM 0, verify it hashes, then MM 1, then MM 2. This limits blast radius — one failed MM flash is recoverable; three simultaneous failures is a shipping crate to D-Central.

Confirm `SYSTEMSTATU` reports correct MM count post-flash. SSH into the controller and query the cgminer API: `echo '{"command":"stats"}' | nc 127.0.0.1 4028`. `SYSTEMSTATU` should show the full count of installed MMs (3 for a stock A1246). If fewer, one or more MMs didn't come back — re-run Steps 5-11 targeted at the missing MM only. Do not flash a working MM again 'just in case.'

Image a fresh controller SD card. Pull the SD/microSD from the controller. Write a clean stock image from avalonminer.org/firmware-document/ using Etcher or dd on Linux. Verify the write with md5sum against the source. Boot the rig from the fresh card with the same MMs in place. If the rig comes up and MMs enumerate, your original SD was worn and the flash wrote to bad sectors. Keep the old SD as a forensic artefact.

Split the rig for isolation. Move the suspect AUC3 + MMs to a second known-good controller (or a Linux PC running cgminer standalone). If MMs enumerate on the second controller and hash, your original controller board or SD is the issue. If they fail identically, the MM firmware or hardware is the issue. This is the difference between a $40 SD replacement and a $150+ controller repair — don't skip it.

Use `ascset` to probe individual MMs. From cgminer's interactive console: `ascset|0,softreset,0` then wait 30 s; then `ascset|0,version,0`; then `ascset|0,led,0-3,1`. A responsive MM answers the version query even in bootloader state. A dead MM is silent on all of the above. This narrows the brick to a specific module for shipping or bench-repair.

Scope the MM signal lines. With heatsink off and a scope on the MM's signal test points (per the A11/A12 repair signal map on Zeus Mining): `CK` should read ~`4 MHz`, `C` should read `6.097 MHz`, `D` should show clean digital edges, `R` should pulse high on power-up and stay high. Any absent or malformed signal points at a broken solder joint or dead chip on that line. Last diagnostic before Tier 4.

Flash from a Linux PC with cgminer built from source. If the stock Canaan controller image is giving you grief, compile cgminer from github.com/ckolivas/cgminer on a clean Linux box, connect the AUC3 via USB, run the flash from there. This bypasses any SD-card / controller-firmware layer and gives cleaner log output than Canaan's bundled tools. Requires terminal comfort; documented in the cgminer ASIC-README.

Don't trust non-official firmware builds unless you can read the source. Third-party 'overclocked' Avalon firmware exists in corners of the internet. On an already-sick miner, flashing a non-stock build is how you turn recoverable into dead — signatures fail, bootloaders refuse, and you're in Tier 4. The Bitaxe/Nerd world is different (open-source firmware is the whole point); on Canaan, stick to avalonminer.org builds or confirmed-good community images with source you can read.

Stop DIY when: a known-good AUC3 + known-good cable + wired Ethernet + stock tuning + matched build still fails at the same progress point; OR scope traces show abnormal `CK`/`C`/`D`/`R`; OR the controller eMMC/SD refuses a fresh image; OR you see visible flash damage (burnt component, blown cap, scorch) on the control board or an MM. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/ .

D-Central bench process. Canaan hardware gets isolated on a test fixture with a programmable load and scope-monitored AUC3 harness. We flash with known-good Canaan builds under bench-controlled voltage/temperature. If the MM stays dead, we scope signal paths (`CK`/`C`/`D`/`R` per Zeus Mining) and identify the failed chip or broken trace. Chip-level replacement on A3206 silicon is possible with reflow and donor silicon from our salvage inventory. Controller-level repairs happen here too.

Ship safely. Place the controller board, each suspect MM, the AUC3, and the USB cable each in its own anti-static bag. Double-box with ≥5 cm of foam on every side. Include a printed note with: observed symptoms, exact firmware build attempted, any cgminer launch flags, `dmesg`/`cgminer.log` excerpts from before and after the failed flash, and your phone/email. This intake detail saves 1-3 days of diagnostic time — and cuts your repair bill accordingly. Flag if shipping a PSU too, and whether it was the suspected PSU during flash.